Ryzen vs UEFI/GPT, OpenRC issue maybe? (hanging on boot)

Message

Dr Croubie · Post by **Dr Croubie** » Fri Nov 20, 2020 6:05 am

OK, so up until last night I had a perfectly working system that I installed a year or two ago, on a Ryzen 2600, AMD X470, SataSSD. But somewhere in between 'I haven't emerged for 109 days', 'python2 is EOL', 'profile 17.0 is deprecated', and a thousand blocking packages, I managed to completely bork everything, unistalled the wrong package and deleted portage or something equally stupid.
Anyway, that's not the problem. I've been around gentoo for 15 years or so, so I just took the excuse to reinstall from scratch (nothing else to do in lockdown I suppose).

The last install (that I just overwrote) I did 2 years ago I just did as I always do, fdisk and MBR and all that. And that worked fine.
But, totally unrelatedly, I also installed Windows10 LTSC a while ago. And dual-booting with that was really annoying, I had to get into the bios twice, once to change between UEFI/BIOS-boot modes, then again to select the boot drive (because my bios is stupid and literally didn't give me both win and lin in the same boot menu at once).

So, I took the excuse to do it differently this time and try GPT and EFI (seeing as the handbook says I should have been using it since 2010, I thought it's about time).

Followed the handbook, all good, compiled kernel, all good, installed grub, all good, etc, etc, fine, rebooted.

Now, it boots fine. It gets to 'INIT: version 2.97 booting' and 'Press I to enter interactive boot mode'.
Does a dozen lines after that.
The first time I booted, it hung on 'Setting HW Clock to current time' (or vice-versa).

So I went back to the live-usb, chrooted again etc. (all that still works, emerge while chrooted works fine). Compiled a new kernel with max log levels 15/15/7 to see if I could get any other info. While I was there, I deleted 'hwclock' from rc just in case that was the problem.
Rebooted, back to the new install, same thing. Just hangs. Last one it hangs on is:
'Checking local filesystems ...
/sbin/fsck.xfs: XFS file system.
fsck.fat 4.1 (2017-01-24)
_'

Now, I don't think it's the fsck (nor the hwclock) that's the problem, I think it's whatever is coming after that. And I'm not fast enough to hit the I for Interactive either (tried a few times already).
In the first instance, how can I add more debug into the OpenRC system?

Now, the reason I think this is a Ryzen EFI issue is twofold: One is that this system was working fine last night, the only thing I changed is going to UEFI/GPT instead of the previously-working BIOS/MBR.

The other reason is that I've seen this before. I bought a new mini-itx system for work (Ryzen 3400G / M.2 Sata / B550 IIRC) a while ago, and thought I'd play around putting Gentoo on it (before the guy who it was meant to be for got back from holidays and put on the Fedora that he wanted).
Anyway, when I did that, I initially did the bog-standard fdisk/MBR-route as has been tattooed in my brain for 20 years. But the bios on the mobo had no 'legacy mode' and so didn't even recognise it as a boot device. So I reinstalled it as UEFI/GPT. And the exact same thing happened. OpenRC started, got a few lines in, then just hangs. Never got around to figuring out or fixing the problem because at that point my colleague came back from holidays and blew it all away to put Fedora on.

So I'm thinking that it's also possible, but I couldn't find anything searching around here (15 years later and the forum search still sucks: it either finds zero or thousands of hits), that there's some sort of issue with Ryzens and/or UEFI and/or GPT that just doesn't work? I'm sure there are more than a few Ryzen users around here, did anyone else have this issue and/or do something specal to get it working?

Jaglover · Post by **Jaglover** » Fri Nov 20, 2020 8:11 am

It stops output to the screen. Do you have any proof it actually stops booting?

DaggyStyle · Post by **DaggyStyle** » Fri Nov 20, 2020 8:25 am

I have a ryzen 2700X on a b450 board in uefi, my root is raid1, gpt and my other mounts (/usr, /var, ...) are raid5 gpt running openrc and it boots well.
I'd recommend taking the livecd's kernel and trying it as your main kernel.
to be sure this isn't a kernel issue.

Dr Croubie · Post by **Dr Croubie** » Sat Nov 21, 2020 1:27 am

OK, well I'm fairly sure it's just proper crashing, not just screen freezing. At least, the network isn't working and I can't ssh into it either from anywhere.
And I'm also fairly certain that it's not a kernel-version either.
So far this morning I've tried 5.9.9 (latest~) and 5.4.72 (latest stable) and no change.
I've also tried these removing all the amdgpu stuff, in case it's crashing when looking for a module that hasn't been built yet (it's the config copied over from my last working install. No idea what kernel version that was but at least 5.x and I had amdgpu and kde working fine on it)
I tried just copying over the kernel images (all of /boot/* really) from the livecd iso, but then grub2-mkconfig on my new install simply doesn't find it and I don't know how to write grub things (haven't done that since I stopped using lilo 10 years ago)

Instead, I tried copying the gentoo-config to /usr/src/linux-5.4.4 and -5.4.72, make oldconfig and compile. Whatever's in that config, it just panics on boot with either version. Possibly an initramfs thing?

Anyway, I don't want to get bogged down on kernel configs and versions, because I really highly doubt it's a kernel thing. Seeing as it's getting to at least starting OpenRC and hanging in there somewhere, I really want to know how to get more debug out of that in the first instance, but I can't find anything remotely useful other than the 'press I for interactive' that doesn't work.

Any more ideas of things to try?

saellaven · Post by **saellaven** » Sat Nov 21, 2020 5:43 am

Do you have CONFIG_FRAMEBUFFER_CONSOLE=y in your kernel .config? I seem to remember getting stuck there once upon a time when I switched over to UEFI.

As a point for future reference, never change too many core things in your system all in one boot... do each one piecemeal so you can know what's causing the failure. So, in this case, update your kernel and reboot to make sure it works, update openrc and reboot, update sysvinit and reboot, and once the all of that is working, then move to UEFI. You'll save yourself a lot of headaches. I learned this back from my days when I thought it was fun to keep my server up for years without rebooting. Truth is, you don't know how broken your system may be, nor even when you broke it, if you never actually check it for failure (by rebooting, restarting demons, etc).

DaggyStyle · Post by **DaggyStyle** » Sat Nov 21, 2020 8:25 am

try building with defconfig, also be sure you have linux-firnware installed and the right fw files included