On Fri, 21 Oct 2022 21:16:48 +0000 (UTC) George R Goffe via test <test@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > Hi, > > I just installed a current kernel > (6.1.0-0.rc1.20221018gitbb1a1146467a.16). This kernel will not boot. > It appears to hang near the execution of dracut-pre-mount processing. > This process seems to be looking for a disk by uuid but it NEVER > completes. I let it go for over an hour but the system was still > effectively hung. > > My fallback kernel is the release 5.18.0-0.rc7.54.fc37.x86_64. This > situation happened during early releases of this kernel series but > thien it just started working. > > I have no ability (that I know of) to get a log of the boot attempt. > > Is this a known problem? Is there a workaround? > > Please help. I don't know if it is related, but I had, and continue to have, a problem on F37 with the 6.0 kernels when I build them locally. The problem is that dracut doesn't put all the libraries needed by/for systemd into the initramfs when I install the kernel. This also happens with Fedora stock kernels. I had to write a parse program that scans the missing libraries and finds their latest installed version and then creates a dracut.conf that forces them to be included when I run dracut manually. I have not built a 6.1 kernel yet, as I usually wait for a few iterations (rc3 or so) to let things settle from all the changes, and create a rescue kernel from the newly released kernel. You can immediately tell if this is your issue by going into /boot and doing an ls -n The initramfs for the failing kernel will be about half the size of that for the successful kernel, because of all the missing libraries. I could find no reason for this to happen. Everything was fully up to date, and the default dracut instructions to build the initramfs seemed to be the same as when it worked. They directed that the libraries be installed, it just wasn't happening. So, since it wasn't a general problem (no one else was hitting it), I assumed it was some kind of corner case hitting my system, and created the workaround I describe above. _______________________________________________ test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
