Hi,
I just did a kernel update and after reboot I ended up in a grub prompt.
I booted from USB F40 and followed instructions at
https://docs.fedoraproject.org/en-US/quick-docs/grub2-bootloader/#_restoring...
However, whatever I did I was not able to successfully boot. I spent hours trying to figure it out before trying to boot to the old 6.9.4-200 kernel from the dreaded grub prompt and voila, the system happily came on.
My question now is: How to restore my grub2 reliably so that I would not have to go through all these hoops again after next reboot.
Any pointer would be gratefully appreciated :-)
Cheers Frank
On 2024-06-22 20:59, Frank Bures wrote:
Hi,
I just did a kernel update and after reboot I ended up in a grub prompt.
I booted from USB F40 and followed instructions at
https://docs.fedoraproject.org/en-US/quick-docs/grub2-bootloader/#_restoring...
However, whatever I did I was not able to successfully boot. I spent hours trying to figure it out before trying to boot to the old 6.9.4-200 kernel from the dreaded grub prompt and voila, the system happily came on.
My question now is: How to restore my grub2 reliably so that I would not have to go through all these hoops again after next reboot.
This is what my efibootmgr returns:
root@ryzen:/# efibootmgr BootCurrent: 0002 Timeout: 1 seconds BootOrder: 0002,0000,0001 Boot0000 Fedora HD(1,GPT,e8838c34-c364-4347-afb7-1c516782b114,0x800,0x12c000)/\EFI\FEDORA\SHIMX64.EFI Boot0001 Fedora HD(1,GPT,e8838c34-c364-4347-afb7-1c516782b114,0x800,0x12c000)/\EFI\FEDORA\SHIM.EFI0000424f Boot0002* Fedora HD(1,GPT,e8838c34-c364-4347-afb7-1c516782b114,0x800,0x1f4000)/\EFI\FEDORA\SHIM.EFI0000424f
I have no idea where the *424f files came from or why one of them has the highest priority.
Frank
On Sat, 2024-06-22 at 23:54 -0400, Frank Bures wrote:
This is what my efibootmgr returns:
root@ryzen:/# efibootmgr BootCurrent: 0002 Timeout: 1 seconds BootOrder: 0002,0000,0001 Boot0000 Fedora HD(1,GPT,e8838c34-c364-4347-afb7-1c516782b114,0x800,0x12c000)/\EFI\FEDORA\SHIMX64.EFI Boot0001 Fedora HD(1,GPT,e8838c34-c364-4347-afb7-1c516782b114,0x800,0x12c000)/\EFI\FEDORA\SHIM.EFI0000424f Boot0002* Fedora HD(1,GPT,e8838c34-c364-4347-afb7-1c516782b114,0x800,0x1f4000)/\EFI\FEDORA\SHIM.EFI0000424f
I have no idea where the *424f files came from or why one of them has the highest priority.
The "BootOrder: 0002,0000,0001" line tells you the priority. First it'll try the last one. Then it'll try the first one. Lastly it'll try the middle one.
Of course, if one of the entries tries to boot, that going to be a success as far as the motherboard's handover is concerned. Even if Linux then fails to *continue* booting.
It's more a case of "any response?" rather than "successful."
On 2024-06-23 04:29, Tim wrote:
On Sat, 2024-06-22 at 23:54 -0400, Frank Bures wrote:
This is what my efibootmgr returns:
root@ryzen:/# efibootmgr BootCurrent: 0002 Timeout: 1 seconds BootOrder: 0002,0000,0001 Boot0000 Fedora HD(1,GPT,e8838c34-c364-4347-afb7-1c516782b114,0x800,0x12c000)/\EFI\FEDORA\SHIMX64.EFI Boot0001 Fedora HD(1,GPT,e8838c34-c364-4347-afb7-1c516782b114,0x800,0x12c000)/\EFI\FEDORA\SHIM.EFI0000424f Boot0002* Fedora HD(1,GPT,e8838c34-c364-4347-afb7-1c516782b114,0x800,0x1f4000)/\EFI\FEDORA\SHIM.EFI0000424f
I have no idea where the *424f files came from or why one of them has the highest priority.
The "BootOrder: 0002,0000,0001" line tells you the priority. First it'll try the last one. Then it'll try the first one. Lastly it'll try the middle one.
Of course, if one of the entries tries to boot, that going to be a success as far as the motherboard's handover is concerned. Even if Linux then fails to *continue* booting.
It's more a case of "any response?" rather than "successful."
Thanks.
I think I found the problem.
I followed
https://fedoraproject.org/wiki/GRUB_2?rd=Grub2#Updating_GRUB_2_configuration...
and then I tried to run grub2-emu
I get the list of installed kernels OK, but any choice for boot returns
error: ../../grub-core/loader/emu/linux.c:319:cannot find kernel file /vmlinuz-6.9.4-200.fc40.x86_64.
and the same error for initramfs. Please note the dot at the end of the line, is it normal?
No matter which kernel I choose, I get the error that kernel file was not found. All kernel files are in /boot and have correct permissions.
I checked UUIDs of /boot, /boot/efi and / and they are all correct.
I think this is the original problem that causes boot ending in grub prompt.
Any advice would be greatly appreciated.
Thanks Frank
On 2024-06-23 11:43, Frank Bures wrote:
On 2024-06-23 04:29, Tim wrote:
I followed
https://fedoraproject.org/wiki/GRUB_2?rd=Grub2#Updating_GRUB_2_configuration...
and then I tried to run grub2-emu
I get the list of installed kernels OK, but any choice for boot returns
error: ../../grub-core/loader/emu/linux.c:319:cannot find kernel file /vmlinuz-6.9.4-200.fc40.x86_64.
and the same error for initramfs. Please note the dot at the end of the line, is it normal?
No matter which kernel I choose, I get the error that kernel file was not found. All kernel files are in /boot and have correct permissions.
As a general warning only:
Never, I mean NEVER try to dd the boot disk to another permanently connected disk in a machine. The existence of two identical UUIDs in the same machine created all kinds of problems, one of those exhibited itself as described in this thread. But that was just the beginning.
Actually I ended up trying changing the UUID on /dev/sga that somehow changed the UUID on /dev/sda by itself. Even after wiping the sdg, blkid still reported an alive msdos partition, no matter how invisible in gparted. It behaved like quantum entanglement :-).
I had to wipe the disk completely and then remove all mentions of sdg* in /dev to free myself of this mess.
After repairing /boot and /boot/efi, subsequent reboot worked normally.
Very painful experience, suffice to say. Never again!
Cheers Frank
On Fri, Jun 28, 2024 at 2:10 PM Frank Bures buresf@gmail.com wrote:
On 2024-06-23 11:43, Frank Bures wrote:
On 2024-06-23 04:29, Tim wrote:
I followed
https://fedoraproject.org/wiki/GRUB_2?rd=Grub2#Updating_GRUB_2_configuration...
and then I tried to run grub2-emu
I get the list of installed kernels OK, but any choice for boot returns
error: ../../grub-core/loader/emu/linux.c:319:cannot find kernel file /vmlinuz-6.9.4-200.fc40.x86_64.
and the same error for initramfs. Please note the dot at the end of the line, is it normal?
No matter which kernel I choose, I get the error that kernel file was not found. All kernel files are in /boot and have correct permissions.
As a general warning only:
Never, I mean NEVER try to dd the boot disk to another permanently connected disk in a machine. The existence of two identical UUIDs in the same machine created all kinds of problems, one of those exhibited itself as described in this thread. But that was just the beginning.
Actually I ended up trying changing the UUID on /dev/sga that somehow changed the UUID on /dev/sda by itself. Even after wiping the sdg, blkid still reported an alive msdos partition, no matter how invisible in gparted. It behaved like quantum entanglement :-).
I had to wipe the disk completely and then remove all mentions of sdg* in /dev to free myself of this mess.
After repairing /boot and /boot/efi, subsequent reboot worked normally.
Very painful experience, suffice to say. Never again!
Lol... quantum entanglement.
Another one to avoid: cheap SSDs with duplicate serial numbers. Some manufacturers repeat (clone?) serial numbers, and when you try to use them in a RAID configuration, things go badly. A fellow on a Ubuntu list struggled for months because of it.
Jeff
On 2024-06-28 14:25, Jeffrey Walton wrote:
Another one to avoid: cheap SSDs with duplicate serial numbers. Some manufacturers repeat (clone?) serial numbers, and when you try to use them in a RAID configuration, things go badly. A fellow on a Ubuntu list struggled for months because of it.
At least if was not of his own doing. I inflicted the mess on myself freely and intentionally. That's what makes it so painful :-)
Cheers Frank
On 6/28/24 11:25 AM, Jeffrey Walton wrote:
Another one to avoid: cheap SSDs with duplicate serial numbers. Some manufacturers repeat (clone?) serial numbers, and when you try to use them in a RAID configuration, things go badly. A fellow on a Ubuntu list struggled for months because of it.
That shouldn't matter. The kernel isn't going to get confused. It will still create separate devices for them. And the RAID config uses the partition UUID.
-
Frank Bures -
Jeffrey Walton -
Samuel Sieb -
Tim