After three days of effort I have failed to find a way of shifting a server from legacy boot to UEFI boot.
I have made my way through the 400+ pages of RH installation manual for EL7, plus their similarly large system administrators manual. Dozens of pages searched via google and yet none of the layouts for the /boot and /boot/efi have worked in my case.
System is a Lenovo 3650 M5 with UEFI bios.
Due to RH / CentOS design my initial install onto the two 600GB HDD partitioned these using MBR and legacy boot.
I have just obtained two SAS SSD drives of 3.8TB and thus MBR is no longer an option.
I have successfully migrated all the system and data from the HDD to the SSD, complete with GPT and RAID1 and all works as expected - except the HDD was still needed to boot the system.
That's when the fun / agony started. Each system reboot is almost five minutes just to get to the <F1> for system setup option. Thus testing is a very slow process.
I am now at the point where I have a "bios boot" partition (1024K type ef02) as the first partition on each GPT partitioned SSD and have grub2-install onto the drives the bios boot junk needed for legacy boot.
Thus I can at least legacy boot from one of the SSD and all comes up as expected. (no idea yet why it only works from one of the SSD and not the other).
Unfortunately the server is remote and the CentOS7 USB device I left plugged into the machine refuses to boot from UEFI mode. Thus a rescue mode boot has not been possible.
I have two 300MB partitions, one on each SSD suitably formatted (type ef00 and vfat) and set up with the files as follows:
-rwx------. 1 root root 134 Aug 1 2020 BOOT.CSV -rwx------. 1 root root 134 Aug 1 2020 BOOTX64.CSV drwx------. 2 root root 4096 Aug 27 16:22 fonts -rwx------. 1 root root 6597 Aug 27 21:33 grub.cfg -rwx------. 1 root root 1024 Aug 26 23:22 grubenv -rwx------. 1 root root 1122120 Mar 17 07:24 grubx64.efi -rwx------. 1 root root 19378672 Aug 26 20:29 initramfs-3.10.0-1160.36.2.el7.x86_64.img -rwx------. 1 root root 1154640 Aug 1 2020 mmx64.efi -rwx------. 1 root root 1154640 Aug 1 2020 MokManager.efi -rwx------. 1 root root 1243864 Aug 1 2020 shim.efi -rwx------. 1 root root 1237824 Aug 1 2020 shimx64-centos.efi -rwx------. 1 root root 1243864 Aug 1 2020 shimx64.efi -rwx------. 1 root root 6777448 Aug 26 20:27 vmlinuz-3.10.0-1160.36.2.el7.x86_64.efi
unfortunately grub2-mkconfig sets up the grub.cfg as for legacy boot because the /sys/firmware/efi does not exist, thanks to running from a legacy boot.
I tried a few manual edits to the grub.cfg to deal with linux16 -> linuxefi and initrd16 -> initrdefi but to little avail.
Can someone point me to what needs to happen for UEFI boot to work successfully.
I am unsure what file I need to point the UEFI bios disk manager setup at, I have tried shim.efi and shimx84-centos.efi
The message I get is that linux16 and initrd16 cannot find their files. The change to linuxefi and initrdefi also fail but the system reboot happens before I can see what flashes on screen.
Is a USB based UEFI booted rescue mode the only way I can fix this?
TIA for your pointers / suggestions.
On 27/08/21 10:51 pm, Rob Kampen wrote:
Unfortunately the server is remote and the CentOS7 USB device I left plugged into the machine refuses to boot from UEFI mode. Thus a rescue mode boot has not been possible.
So i made a trip and replaced the USB stick with another one - CentOS7
I am unsure what file I need to point the UEFI bios disk manager setup at, I have tried shim.efi and shimx84-centos.efi
The message I get is that linux16 and initrd16 cannot find their files. The change to linuxefi and initrdefi also fail but the system reboot happens before I can see what flashes on screen.
Is a USB based UEFI booted rescue mode the only way I can fix this?
So I then rebooted - selected UEFI native boot and got into rescue mode - only problem is that the rescue system did not find a Linux system. Really weird as each of the four drives effectively have a complete centos7 system. No idea why it didn't start md raid and find the 6 raid1 volumes.
About to give this a miss and just live with legacy boot - this UEFI thing is just far too complicated. Looking on line at all the various blogs and questions it seems I am not alone in finding it far too complicated.
I run a Ubuntu workstation that is UEFI based and their grub.cfg is so much simpler than the centos one.
TIA for your pointers / suggestions.
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On 27/08/21 10:51 pm, Rob Kampen wrote:
Unfortunately the server is remote and the CentOS7 USB device I left plugged into the machine refuses to boot from UEFI mode. Thus a rescue mode boot has not been possible.
So i made a trip and replaced the USB stick with another one - CentOS7
I am unsure what file I need to point the UEFI bios disk manager setup at, I have tried shim.efi and shimx84-centos.efi
The message I get is that linux16 and initrd16 cannot find their files. The change to linuxefi and initrdefi also fail but the system reboot happens before I can see what flashes on screen.
Is a USB based UEFI booted rescue mode the only way I can fix this?
So I then rebooted - selected UEFI native boot and got into rescue mode
- only problem is that the rescue system did not find a Linux system.
Really weird as each of the four drives effectively have a complete centos7 system. No idea why it didn't start md raid and find the 6 raid1 volumes.
About to give this a miss and just live with legacy boot - this UEFI thing is just far too complicated. Looking on line at all the various blogs and questions it seems I am not alone in finding it far too complicated.
Don't worry, you're not alone. IMHO UEFI and GRUB2 and the whole Linux startup procedure can be a real problem to handle and I guess most people just give up earlier or later and simply use the installer to do the job.
Simon
On 28/08/21 8:24 pm, Simon Matter wrote:
On 27/08/21 10:51 pm, Rob Kampen wrote:
Unfortunately the server is remote and the CentOS7 USB device I left plugged into the machine refuses to boot from UEFI mode. Thus a rescue mode boot has not been possible.
So i made a trip and replaced the USB stick with another one - CentOS7
I am unsure what file I need to point the UEFI bios disk manager setup at, I have tried shim.efi and shimx84-centos.efi
The message I get is that linux16 and initrd16 cannot find their files. The change to linuxefi and initrdefi also fail but the system reboot happens before I can see what flashes on screen.
Is a USB based UEFI booted rescue mode the only way I can fix this?
So I then rebooted - selected UEFI native boot and got into rescue mode
- only problem is that the rescue system did not find a Linux system.
Really weird as each of the four drives effectively have a complete centos7 system. No idea why it didn't start md raid and find the 6 raid1 volumes.
About to give this a miss and just live with legacy boot - this UEFI thing is just far too complicated. Looking on line at all the various blogs and questions it seems I am not alone in finding it far too complicated.
Don't worry, you're not alone. IMHO UEFI and GRUB2 and the whole Linux startup procedure can be a real problem to handle and I guess most people just give up earlier or later and simply use the installer to do the job.
Yeah, it is astounding to me that RH does not define their implementation of the grub2 grub.cfg file with particular focus on the things that are different between legacy boot and UEFI. Also what (if any) differences there may be in the initramfs and vmlinuz files between the two boot options. then we have the various .efi files with little or no documentation. So we are left with anaconda ....
Makes my situation really tough ... too small for the learning curve of automated OS installation and management systems but I have a week or so of configuration and testing invested that I will need to redo, if I do a re-install just to get the boot system shifted from BIOS/legacy to UEFI.
As to the RH decision to default to a legacy boot / MBR oriented install based upon size of disk ... words fail me.
At least I have learnt that one needs to do research into MB firmware w.r.t BIOS/UEFI as part of procurement. Never been a thing I cared about previously, but now another area which can bite you in the butt.
Simon
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On Aug 28, 2021, at 05:58, Rob Kampen rkampen@kampensonline.com wrote:
Yeah, it is astounding to me that RH does not define their implementation of the grub2 grub.cfg file with particular focus on the things that are different between legacy boot and UEFI. Also what (if any) differences there may be in the initramfs and vmlinuz files between the two boot options. then we have the various .efi files with little or no documentation. So we are left with anaconda ....
I don’t think migrating from a legacy bootloader to UEFI (on the same hardware) is a common enough process to document.
I do notice you have a kernel listed with a .efi extension, and I’ve never seen that before.
Typically on a UEFI C7 system, all the kernels and initrds are in /boot. Only the EFI executables and supplementary grub files are in the /boot/efi volume (normally /boot/efi/EFI/CentOS). I don’t know where you got that kernel efi file.
— Jonathan Billings
On Aug 28, 2021, at 05:58, Rob Kampen rkampen@kampensonline.com wrote:
As to the RH decision to default to a legacy boot / MBR oriented install based upon size of disk ... words fail me.
I don’t think that it chooses legacy boot based on the size of disk, but based on how you booted the installer. If you booted from the installer as a legacy boot item, it installs as a legacy bootloader, but if you disable the BIOS option to use a legacy bootloader, it will boot the installer as a UEFI boot and choose to install a UEFI grub2 setup.
— Jonathan Billings
On August 28, 2021 8:07:30 AM CDT, Jonathan Billings billings@negate.org wrote:
On Aug 28, 2021, at 05:58, Rob Kampen rkampen@kampensonline.com wrote:
As to the RH decision to default to a legacy boot / MBR oriented install based upon size of disk ... words fail me.
I don’t think that it chooses legacy boot based on the size of disk, but based on how you booted the installer. If you booted from the installer as a legacy boot item, it installs as a legacy bootloader, but if you disable the BIOS option to use a legacy bootloader, it will boot the installer as a UEFI boot and choose to install a UEFI grub2 setup.
+1
And the same seems to be true about other UNIX like systems, at least Debian and clones, FreeBSD and clones.
Valeri
— Jonathan Billings _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
On 29/08/21 1:03 am, Jonathan Billings wrote:
On Aug 28, 2021, at 05:58, Rob Kampen rkampen@kampensonline.com wrote:
Yeah, it is astounding to me that RH does not define their implementation of the grub2 grub.cfg file with particular focus on the things that are different between legacy boot and UEFI. Also what (if any) differences there may be in the initramfs and vmlinuz files between the two boot options. then we have the various .efi files with little or no documentation. So we are left with anaconda ....
I don’t think migrating from a legacy bootloader to UEFI (on the same hardware) is a common enough process to document.
I do notice you have a kernel listed with a .efi extension, and I’ve never seen that before.
Typically on a UEFI C7 system, all the kernels and initrds are in /boot. Only the EFI executables and supplementary grub files are in the /boot/efi volume (normally /boot/efi/EFI/CentOS). I don’t know where you got that kernel efi file.
— Jonathan Billings
Thanks all, for your comments.
Jonathan, you are correct about the kernel placement and extension - I placed it there early in the process based upon someone's recipe - it didn't work but I hadn't got around to cleaning it up.
I have now got it working!
I was close with all the bits I had done, but the final piece is that I hand edited the grub.cfg in the ESP in my case /boot/efi/EFI/centos/ and /boot/efi2/EFI/centos/ and changed the linux16 to linuxefi and the initrd16 to initrdefi.
Then I used the server's UEFI boot manager app (part of this machine's setup arsenal) to manually add a UEFI boot on a specific drive with arguments pointing at shimx64.efi
Then a reboot and some online grub edits of the linuxefi line and CTRL-X and it finally booted up in UEFI mode.
At this point /sys/firmware/efi exists and efibootmgr -v finally gave some appropriate output
Then I was able to login, run grub2-mkcfg and get a proper grub.cfg file, and finally use efibootmgr to create the desired default boot and backup boot entries in the UEFI.
ALL DONE. Lost some more hair and some sleep, but also much more knowledgeable and comfortable with UEFI.
Possibly not a common scenario, but it feels good having finally beaten it into submission.
Shalom
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On Sat, Aug 28, 2021 at 8:47 AM Valeri Galtsev galtsev@kicp.uchicago.edu wrote:
On August 28, 2021 8:07:30 AM CDT, Jonathan Billings billings@negate.org wrote:
On Aug 28, 2021, at 05:58, Rob Kampen rkampen@kampensonline.com wrote:
As to the RH decision to default to a legacy boot / MBR oriented
install based upon size of disk ... words fail me.
I don’t think that it chooses legacy boot based on the size of disk, but
based on how you booted the installer. If you booted from the installer as a legacy boot item, it installs as a legacy bootloader, but if you disable the BIOS option to use a legacy bootloader, it will boot the installer as a UEFI boot and choose to install a UEFI grub2 setup.
+1
And the same seems to be true about other UNIX like systems, at least Debian and clones, FreeBSD and clones.
This has been my experience as well. If the installer is booted in legacy mode then it will install as it needs to for a BIOS system. If it is booted in UEFI mode then it will install as needed for a UEFI boot. Trying to boot in legacy mode and install for UEFI boot is fraught with a lot of manual complications. IMO it's not any more complicated than understanding the limits of legacy BIOS booting and all the workarounds that have been stacked up over the decades to keep it working.