View previous topic :: View next topic |
Author |
Message |
christoph_peter_s Tux's lil' helper

Joined: 30 Nov 2015 Posts: 112
|
Posted: Tue Mar 04, 2025 1:46 pm Post subject: [solved] Boot problem after upgrade of mainboard |
|
|
Dear fellow Gentooers,
I recently tried to upgrade a small box with an i5-4590 on a Asus H81I-Plus to a i5-7500 on a MSI H110i Pro.
Just swapping the mainboard didn't work - and I still wonder why - so I reformated the EFI partition and worked through the handbook. It took me a considerable amount of time - and I noticed and fixed quite a few bugs of mine. Nevertheless I am now completely stuck, as the system still refuses to boot normally (the live system works flawlessly).
The MSI Bios does however allow to boot into the efi shell. Once there, I can run
Code: | fs0:
cd EFI
cd gentoo
grubx64.efi |
and the system then boots flawlessly.
So this is the first big mystery: Why does the bios not recognize the bootable system? Here is the hard disk info:
Code: | tiresias /boot # fdisk -l /dev/sda
Festplatte /dev/sda: 465,76 GiB, 500107862016 Bytes, 976773168 Sektoren
Festplattenmodell: CT500MX500SSD1
Einheiten: Sektoren von 1 * 512 = 512 Bytes
Sektorgröße (logisch/physikalisch): 512 Bytes / 4096 Bytes
E/A-Größe (minimal/optimal): 4096 Bytes / 4096 Bytes
Festplattenbezeichnungstyp: gpt
Festplattenbezeichner: 213F3679-5D3C-4175-8428-83CAFD4AD8B9
Gerät Anfang Ende Sektoren Größe Typ
/dev/sda1 2048 2099199 2097152 1G EFI-System
/dev/sda2 2099200 968384511 966285312 460,8G Linux-Dateisystem
/dev/sda3 968384512 976773119 8388608 4G Linux Swap
tiresias /boot # blkid
/dev/sda2: UUID="27ac0979-1ed8-436c-8093-aa99b125105c" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="80cde2a4-856c-4aa3-8990-ac19ae225202"
/dev/sda3: UUID="9f26aca8-fc16-44c0-97e5-1c54b5649c5e" TYPE="swap" PARTUUID="7c5c302d-3910-43f0-885f-451c64401d44"
/dev/sda1: UUID="B446-C6E2" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="c12a7328-f81f-11d2-ba4b-00a0c93ec93b" |
I started examining the issue with efibootmgr (after booting via the efi shell) - and my questions grew even larger.
Code: | tiresias ~ # efibootmgr
Timeout: 1 seconds
BootOrder: 0001
Boot0001 Hard Drive BBS(HD,,0x0)/VenHw(5ce8128b-2cec-40f0-8372-80640e3dc858,0200)0000474f00004e4fb500000008000000850043005400350030003000
4d00580035003000300053005300440031000000050109000200000000010416008b12e85cec2cf040837280640e3dc85802007fff040002010c00d041030a000000000
1010600001703120a000000ffff00007fff040001043e00ef47642dc93ba041ac194d51d01b4ce6390031003500300031004500360045004300430032004400200020002
0002000200020002000200000007fff04000000424f |
This boot entry looks weirdly garbled to me. There is something looking like a blkid (5ce8128b-2cec-40f0-8372-80640e3dc858), but it has no relation to the partitions on my disk.
I want to switch to a NVME SSD - but not until I have fixed this nasty boot issue.
I tried first with Code: | efibootmgr -c -d /dev/sda -p 1 -L "UEFI OS" -l "\EFI\BOOT\BOOTX64.EFI" |
But that was apparently another mistake of mine, as it should have said grubx64.eif (I guess it is case insensitive, as it is on a FAT partition).
The same garbled efi entry was there after the reboot (after setting efibootmgr to BOOTX64.EFI).
I will try my luck with an improved efi entry via efibootmgr in the evening, when I am back home.
The question is however, why the standard approach by Code: | grub-install --target=x86_64-efi --efi-directory=/boot
grub-mkconfig -o /boot/grub/grub.cfg |
did not write the correct boot entry. Or did I accidentally buy an incompatible mainboard? This is hard to believe, as the live system works without a hitch.
Best regards
Peter
PS: The efibootmgr-command should have been: efibootmgr -c -d /dev/sda -p 1 -L "gentoo" -l '\EFI\gentoo\grubx64.efi'
There is no directory /boot...
Last edited by christoph_peter_s on Tue Mar 04, 2025 6:44 pm; edited 1 time in total |
|
Back to top |
|
 |
xineg Tux's lil' helper


Joined: 14 Mar 2006 Posts: 118 Location: Australia.
|
Posted: Tue Mar 04, 2025 2:20 pm Post subject: |
|
|
Did you try this literally with BOOTX64.EFI. maybe you need to replace that
with grubx64.efi?
Code: | efibootmgr -c -d /dev/sda -p 1 -L "UEFI OS" -l "\EFI\BOOT\BOOTX64.EFI" |
As far as the garble goes you need to put -u into efibootmgr command line to print all the 'garble' into readable Unicode. Run efibootmgr -u to see human readable text while listing boot entires.
Last edited by xineg on Tue Mar 04, 2025 2:31 pm; edited 5 times in total |
|
Back to top |
|
 |
pietinger Moderator

Joined: 17 Oct 2006 Posts: 5470 Location: Bavaria
|
Posted: Tue Mar 04, 2025 2:21 pm Post subject: |
|
|
christoph_peter_s,
Your BIOS setting must allow an UEFI boot instead an old CSM boot. So "CSM mode" is disabled in your BIOS. Some BIOS call this option "Legacy mode"; then this must be disabled. If this is not the case then there is a chance that your UEFI does not follow the UEFI specification (we had some of them in the past). I suggest to manually add an UEFI entry for grub:
Code: | # efibootmgr -c -d /dev/sda -p 1 -L "gentoo" -l '\EFI\gentoo\grubx64.efi' |
If this entry is gone after a reboot you have a broken UEFI. Try then to install der grub with parameter "--removable". See more here:
https://forums.gentoo.org/viewtopic-p-8854831.html#8854831 _________________ https://wiki.gentoo.org/wiki/User:Pietinger |
|
Back to top |
|
 |
christoph_peter_s Tux's lil' helper

Joined: 30 Nov 2015 Posts: 112
|
Posted: Tue Mar 04, 2025 2:24 pm Post subject: |
|
|
xineg wrote: | Did you try this literally withBOOTX64.EFI. maybe you need to replace that
with grubx64.efi? |
I think, I did try this:
Code: | efibootmgr -c -d /dev/sda -p 1 -L "gentoo" -l '\boot\EFI\gentoo\grubx64.efi' |
which is obviously wrong. It should have been:
Code: | efibootmgr -c -d /dev/sda -p 1 -L "gentoo" -l '\EFI\gentoo\grubx64.efi' |
I will try this when I come home later. |
|
Back to top |
|
 |
christoph_peter_s Tux's lil' helper

Joined: 30 Nov 2015 Posts: 112
|
Posted: Tue Mar 04, 2025 2:45 pm Post subject: |
|
|
Thank You for Your assistance pietinger!
I can confirm, that the CSM mode is disabled and the bios is set to UEFI boot only.
One question regarding the --removable flag. Does this mean, that every kernel upgrade requires to issue both of these commands:
Code: | grub-install --target=x86_64-efi --efi-directory=/boot --removable
grub-mkconfig -o /boot/grub/grub.cfg |
Or to put it different: Do grubx64.efi and/or bootx64.efi point to the actual kernel, so that they need to be updated at a kernel upgrade (which is about once a month or so...).
TIA
Peter |
|
Back to top |
|
 |
pietinger Moderator

Joined: 17 Oct 2006 Posts: 5470 Location: Bavaria
|
Posted: Tue Mar 04, 2025 3:31 pm Post subject: |
|
|
christoph_peter_s wrote: | [...] One question regarding the --removable flag. Does this mean, that every kernel upgrade requires to issue both of these commands:
Code: | grub-install --target=x86_64-efi --efi-directory=/boot --removable
grub-mkconfig -o /boot/grub/grub.cfg |
Or to put it different: Do grubx64.efi and/or bootx64.efi point to the actual kernel, so that they need to be updated at a kernel upgrade (which is about once a month or so...). |
No. If you update the kernel you will need ONLY a grub-mkconfig but NO (new) installation of grub. grub-mkconfig searches for your kernel(s) in /boot and updates its grub.cfg. So you have your new and your old kernel in the grub.cfg and can select what you want to boot (default is always the latest kernel). You WOULD need an installation of grub (again) only if there is a new version of grub.
christoph_peter_s wrote: | Thank You for Your assistance pietinger! |
You are very Welcome!  _________________ https://wiki.gentoo.org/wiki/User:Pietinger |
|
Back to top |
|
 |
christoph_peter_s Tux's lil' helper

Joined: 30 Nov 2015 Posts: 112
|
Posted: Tue Mar 04, 2025 6:50 pm Post subject: |
|
|
Dear xineg, dear pietinger,
in fact the reason for my problems seems to be a dysfunctional UEFI-Bios of that MSI board. Luckily enough they implemented the Efi shell, which make me to stop search in apparently unrelated corners of the system.
The re-installation of grub with the --removable flag solved the problem and the system comes up now as expected.
I'll go on to search for an equalizer, that I can apply to the standard sound output. But that's another problem.
Thank You and best regards
Peter
PS:
I ended up in Bavaria, too... Very nice place to be. |
|
Back to top |
|
 |
eccerr0r Watchman

Joined: 01 Jul 2004 Posts: 9919 Location: almost Mile High in the USA
|
Posted: Tue Mar 04, 2025 7:21 pm Post subject: |
|
|
I think your EFIs are doing what it should. If you used efibootmgr to set grub as an EFI boot option, you need to rerun efibootmgr on the new machine when moving a disk to a new computer, this is normal and expected. _________________ Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
Back to top |
|
 |
|