Hi, I had changed from Fedora to openSUSE due to an error on LUKS during boot (it would not see the correct devices, dracut would timeout). I could boot using an older kernel but couldn't figure out what the issue was/hadn't had the patience. Yesterday it happened on openSUSE and, in that case, no kernel would boot. So, again, I returned to Fedora. Do note the same thing had happened on another computer. This was approximately 1 month ago.
No-one else seems to have had this issue.
I've since reinstalled Fedora 40 so now my system is stable and working fine.
Still, it puzzles me, so, does anyone have any hint of what may have gone wrong? Spurious internet searches suggested: buggy `blkid` update resulting in buggy `blkid` output which induced `grub-mkconfig` to output boot options missing the necessary UUID necessary for unlocking the correct partitions. But those results were from about a few months ago.
Just FYI, my current, working, install was like this: I installed Fedora 39, upgraded to latest packages excluding=blkid, dracut, kernel, kernel-core-modules, kernel-core-extras, upgraded to all latest on 39, upgraded to Fedora 40 and the bug didn't happen again.
Thanks, User of Fedoras
I don't know specifically on this bug. But the 2 common mistakes fall into some piece failing and causing dracut to not properly detect what modules the boot device needs to use. And when that happens dracut times out looking for root. I have also seen bugs where the necessary module needed to boot is broken.
Best fix for the first one is to change dracut to use host-only = no (include all possible modules that may be needed to boot and don't rely on detection). There may be some other options in dracut to force tne needed pieces that you know your setup needs. This should eliminate the need to rely on the detection code to figure out what modules are needed. The disadvantage is that the initramfs will be 2-4x larger and that may impact the number of kernels you can have on boot.
On Sun, Aug 18, 2024 at 7:33 AM User of Fedoras via users users@lists.fedoraproject.org wrote:
Hi, I had changed from Fedora to openSUSE due to an error on LUKS during boot (it would not see the correct devices, dracut would timeout). I could boot using an older kernel but couldn't figure out what the issue was/hadn't had the patience. Yesterday it happened on openSUSE and, in that case, no kernel would boot. So, again, I returned to Fedora. Do note the same thing had happened on another computer. This was approximately 1 month ago.
No-one else seems to have had this issue.
I've since reinstalled Fedora 40 so now my system is stable and working fine.
Still, it puzzles me, so, does anyone have any hint of what may have gone wrong? Spurious internet searches suggested: buggy `blkid` update resulting in buggy `blkid` output which induced `grub-mkconfig` to output boot options missing the necessary UUID necessary for unlocking the correct partitions. But those results were from about a few months ago.
Just FYI, my current, working, install was like this: I installed Fedora 39, upgraded to latest packages excluding=blkid, dracut, kernel, kernel-core-modules, kernel-core-extras, upgraded to all latest on 39, upgraded to Fedora 40 and the bug didn't happen again.
Thanks, User of Fedoras -- _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org 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/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
bottom-posting, somewhat manually.
On Sun, Aug 18, 2024 at 1:43 PM Roger Heflin rogerheflin@gmail.com wrote:
I don't know specifically on this bug. But the 2 common mistakes fall into some piece failing and causing dracut to not properly detect what modules the boot device needs to use. And when that happens dracut times out looking for root. I have also seen bugs where the necessary module needed to boot is broken.
Best fix for the first one is to change dracut to use host-only = no (include all possible modules that may be needed to boot and don't rely on detection). There may be some other options in dracut to force tne needed pieces that you know your setup needs. This should eliminate the need to rely on the detection code to figure out what modules are needed. The disadvantage is that the initramfs will be 2-4x larger and that may impact the number of kernels you can have on boot.
Thanks, applied. I did think, though, that was the default?
Default in /lib/dracut.conf.d/01-dist.conf is: 01-dist.conf:hostonly="yes"
When you rebuild the initramfs it should get 2-3x bigger.
On Tue, Aug 20, 2024 at 5:19 AM User of Fedoras f9ue98sudw@ol1y.com wrote:
bottom-posting, somewhat manually.
On Sun, Aug 18, 2024 at 1:43 PM Roger Heflin rogerheflin@gmail.com wrote:
I don't know specifically on this bug. But the 2 common mistakes fall into some piece failing and causing dracut to not properly detect what modules the boot device needs to use. And when that happens dracut times out looking for root. I have also seen bugs where the necessary module needed to boot is broken.
Best fix for the first one is to change dracut to use host-only = no (include all possible modules that may be needed to boot and don't rely on detection). There may be some other options in dracut to force tne needed pieces that you know your setup needs. This should eliminate the need to rely on the detection code to figure out what modules are needed. The disadvantage is that the initramfs will be 2-4x larger and that may impact the number of kernels you can have on boot.
Thanks, applied. I did think, though, that was the default?
On Sun, Aug 18, 2024 at 9:43 AM Roger Heflin rogerheflin@gmail.com wrote:
I don't know specifically on this bug. But the 2 common mistakes fall into some piece failing and causing dracut to not properly detect what modules the boot device needs to use. And when that happens dracut times out looking for root. I have also seen bugs where the necessary module needed to boot is broken.
Best fix for the first one is to change dracut to use host-only = no (include all possible modules that may be needed to boot and don't rely on detection).
Or generate a newer rescue kernel. The 6.10 update had a bunch of issues that are not mostly resolved, so this may be a good time to update the rescue kernel.
There may be some other options in dracut to force tne needed pieces that you know your setup needs. This should eliminate the need to rely on the detection code to figure out what modules are needed. The disadvantage is that the initramfs will be 2-4x larger and that may impact the number of kernels you can have on boot.
One purpose of the rescue kernel is to allow swapping out a broken piece of hardware (typically video card, network card, or mass storage device), so 3 smaller kernels and a relatively current rescue kernel is a reasonable use of resources.
On Sun, Aug 18, 2024 at 9:33 AM User of Fedoras via users < users@lists.fedoraproject.org> wrote:
Hi, I had changed from Fedora to openSUSE due to an error on LUKS during boot (it would not see the correct devices, dracut would timeout). I could boot using an older kernel but couldn't figure out what the issue was/hadn't had the patience.
Which Fedora version?
Yesterday it happened on openSUSE and, in that case, no kernel would boot. So, again, I returned to Fedora. Do note the same thing had happened on another computer. This was approximately 1 month ago.
No-one else seems to have had this issue.
Fedora often leads other distros, so it is not unusual to encounter an issue in Fedora that is not present in other distros, then the same issue appears when the other distro catches up to the (now old) Fedora version that had the problem.
I've since reinstalled Fedora 40 so now my system is stable and working
fine.
There were issues with 6.10 kernels that have now been solved, so you chose a moment when Fedora was relatively stable.
Still, it puzzles me, so, does anyone have any hint of what may have gone wrong? Spurious internet searches suggested: buggy `blkid` update resulting in buggy `blkid` output which induced `grub-mkconfig` to output boot options missing the necessary UUID necessary for unlocking the correct partitions. But those results were from about a few months ago.
You need to find actual kernel versions and links to the change details. There were (and continue to be) instances of users following incorrect guidance found on the internet to run "grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg.".
If you have backups from the old Fedora version with the journalctl data there might be some hope of understanding the problem. A problem with distro shopping to solve problems is that you lose the opportunity to investigate and possibly contribute to a solution (often by testing a pre-release package).
Just FYI, my current, working, install was like this: I installed Fedora 39, upgraded to latest packages excluding=blkid, dracut, kernel, kernel-core-modules, kernel-core-extras, upgraded to all latest on 39, upgraded to Fedora 40 and the bug didn't happen again.
I assume that means the initial Fedora 39 installation worked and continued to work when upgraded. Fedora 39 gets most fixes until 41 has been released.
-
George N. White III -
Roger Heflin -
User of Fedoras