I did an “upgrade” from a DVD ISO which ran through the file list and then stated it would reboot.
On reboot I have the messages:
cannot find command “linuxefi” and
cannot find command “initrdefi” from grub
I tried going into rescue mode with the install disk but it won’t start the kernel.
I can boot the machine into a previous BTRFS snapshot of 42.2
Currently my bios boot options don’t mention UEFI at all.
My next step will be to repeat the upgrade but this time allow the install to format the system partition again.
Unless someone can suggest a workaround from where I am.
I’m not sure what you did wrong there.
“linuxefi” and “initrdefi” are grub commands for grub2-efi, but they are not recognized by the non-efi version of grub.
You probably switched from UEFI booting to MBR booting.
Things to try:
Boot to rescue mode, or boot to live media, mount your system as appropriate. Then find “grub.cfg”. It should be in “/boot/grub2”, but for your rescue mount it will be elsewhere.
Edit “grub.cfg”. Change every occurence of “linuxefi” to “linux” and change every occurence of “initrdefi” to “initrd”.
That should allow you to boot.
Once you have booted your system, edit the file “/etc/default/grub”. Look for a line:
GRUB_USE_LINUXEFI="true"
and change that “true” to “false”. (Alternatively, just comment out that line, or even delete it). After that, you should be set. If you don’t make that change to “/etc/default/grub”, then you will probably get the same problem back again in the future (when “grub.cfg” is updated).
Thanks for the response.
FWIW I am now up and running after the following actions:
Boot machine via non-uefi dvd option in BIOS
New installation with attention to type of boot option, non-uefi, formatting the system partition
reboot ensuring non-uefi hard disk option.
For anyone experiencing similar, I think this arose for me previously on 42.1->42.2 but somehow I wandered through it and left the problem in place.
Issue is that in BIOS the boot options are UEFI DVD, then NON-UEFI Hard Drive
So the installation picks up a default secure boot from the #1 even though the long-term HD state is non-UEFI.
Making the system partition directly bootable solved the problem.