But that would fail if you tried it on your system. The “–removable” and “–no-nvram” allow it to succeed, by not attempting to setup the needed NVRAM values.
I was told that after I create the fat32 partition and mount it as /boot/efi I need to go to YAST2 - System - Boot Loader and switch from “GRUB2” to “GRUB2 for EFI” there.
Yes. But that will give an error in a non-UEFI environment.
The normal thing to do would be to boot to rescue mode (after the motherboard change), make the needed mounts and chroot into your system. Then run yast from the command line (the “ncurses” version and make the boot change there.
I currently have an external drive with Tumbleweed. I installed for legacy booting. Then I ran the suggested command to add support for UEFI booting. So now it boots either way (legacy or UEFI) depending on the BIOS of the system to which I have connected it.
Aha: So data will also need to be written to the motherboard itself. I asked about this on IRC and someone mentioned something regarding that, it confused me at first.
At this point it seems easier to just create and mount the new partition for now. Once the new mobo is ready I should just boot from the openSUSE DVD, chroot into the system from a rescue console, then completely reinstall the whole bootloader from there. That’s something I’ve done before when upgrades broke GRUB2 and I had to restore it. If something goes wrong during this stage then I’ll do a fresh install of openSUSE Leap, switch back to Tumbleweed, and import my installed packages from the xml file in YaST2.
What are the exact commands I must run to get the job done? Just grub-install followed by shim-install, or the other way around? I could use a full list of commands to execute, since I don’t remember everything I’ll need to mount or at which stage to chroot.
Added note: I’m thinking how to best optimize the partitioning to make sense. At this point I’d rather make the whole /boot directory its own partition as that’s a more standard approach, obviously as FAT32 so it also includes all the UEFI stuff. I can temporarily mount it to another path then use rsync or something to copy the existing boot folder from my root partition… perhaps I’ll rename the old one and keep it as a backup, so I can do all the messing around in this separate partition once the new mobo arrives.
What size would you recommend for it, considering it would also store the Kernel VM’s? Would 1GB be right? Currently my /boot is only 100MB large so I probably won’t ever need more.
How come? Most people keep the boot partition separate, and I don’t believe there’s any issue with making it a FAT32 partition. Maybe a few milliseconds of boot performance in case FAT is any slower when reading the Kernel VM, but I wouldn’t even notice that.
Do you know the list of commands I’d need to run in order to create a fresh boot loader setup after the new hardware is in place, including the mount and chroot operations? I’m planning to make notes with each step so once it arrives I can go through the whole thing in one go. With the new partitioning, “/” should be sda1 whereas “/boot” should be sda2.
The software expects the EFI partition to be mounted at “/boot/efi”.
You would, instead, be mounting at “/boot”.
To install booting, you would need to use
shim-install --efi-directory=/boot
to override the defaults. And you would have to repeat this whenever there is a reinstall (often, with Tumbleweed).
You won’t be able to work around that with a symlink – partly because FAT32 doesn’t do symlinks and partly because there will already be a directory “/boot/EFI” (and FAT32 is case-insensitive).
Interesting, didn’t think of that. But why would this matter? It can mount /boot then just see the /efi subdirectory. Does the loader treat mount points and directories differently from each other, instead of reconstructing the path regardless of what’s a folder or a mount point?
Hi
UEFI boot expects a partition type of ef00, your /boot is of type 8300 so it won’t work. You can create it anywhere on a disk (default is sda) as long as > 256MB and < 512M (else it complains) in size and type ef00.
Using UEFI booting shouldn’t stop you from having a separate /boot/ partition, but it had better not be FAT. In openSUSE, as well as with some other distros, the kernel and initrd are religiously symlinked at kernel installation time to /boot/vmlinuz and /boot/initrd, which doesn’t work on a non-native /boot/ filesystem. This is independent of need for a unique VFAT ESP partition.
You can have both /boot/ and /boot/efi/ separate partitions if you want, but the filesystem types need to be what they need to be.
That path is compiled into the grub2-efi software and into the shim-install script.
Yes, there are command line options to override that. But it means that you have to use the command line every time that grub is reinstalled or shim is reinstalled.
There was a discussion on the factory mailing list – maybe 8 or 9 years ago – about mounting the EFI partition as “/boot”. And note that KaOS linux does that. The systemd people probably recommend it, particularly if you use systemd-boot instead of grub2. So the idea is not all that far fetched. However, openSUSE has settled on mounting the EFI partition at “/boot/efi”, and you are making work for yourself if you try to do something different.
That is what --no-nvram is for. --removable also installs bootloader in \EFI\Boot instead of \EFI\opensuse (or whatever GRUB_DISTRIBUTOR is set to). That’s not what normal installation does.
–removable may allow booting if firmware supports \EFI\Boot for non-removable media. That is what “boot from UEFI hard disk” menu entry usually implies.
I might not make a separate boot partition then, just the FAT one for the ESP. I’m surprised at how strict this setup is really, especially with everyone praising UEFI as being designed to be more standardized and less complicated than the BIOS (it only feels more limited instead). I’ll actually check if this motherboard supports legacy boot when it arrives, which I hear it should… if so I’ll consider if the whole hustle is even worth it any more, though for now I’ll pursue this idea for the sake of keeping up with the times.
So this is what I got so far: I use a bootable version of gparted to create a 256MB FAT32 partition on my root drive, tell fstab to mount that as /boot/efi, then run “shim-install --no-nvram --removable” which should prepare the boot loader without currently making the system unbootable to the old motherboard. Once I’m ready to install it, what are the last steps to switch GRUB2 to it, ideally while cleaning up any junk left behind by the then obsolete boot loader?
Note: From what I’ve read, the ASUS firmware lets you disable Secure Boot without disabling UEFI booting entirely. This means I should be able to temporarily boot without the nvram key updates, run a normal “shim-install”, then re-enable SB. Would this save me from having to start up in rescue mode and mount / chroot stuff in the console?
Maybe – or maybe not. Since you are not experienced with UEFI, but you are experienced with rescue mode, then it is probably going to be simpler to just use rescue mode.
Create the EFI partition before you switch hardware. And set it up to mount at “/boot/efi”. Then reboot to test that the EFI partition mounts. You will have to first format the EFI partitition for FAT. And be sure to give that partition the type code for an EFI partition.
For reference, here is my “/etc/fstab” entry for the EFI partition:
Before you do, I suggest considering 260 or more, and to read How large should you make the UEFI System Partition? | Ctrl blog for reasons why. To avoid any possible confusion between 260MiB and 260MB, I go arbitrarily with 320MiB, 2^8 * 1.25, or 0xA0000 512 byte sectors.
Regarding partitions, I’m thinking of switching my root drive to 4 partitions in total if I’m going through the trouble anyway:
sda1 would remain my root partition and is EXT4.
sda2 would be “/boot” and contain GRUB2 with the Kernel VM’s, probably BTRFS as for this task I find that better, might go with 512 MB or more.
sda3 would be “/boot/efi” and of course FAT32, since people are saying to make it big I’d use 256 to 512 MB here as well.
sda4 would be swap… I’ll likely be downgrading from 24 GB of RAM to 16 GB, so having 4GB of SWAP again might be handy just in case.
Note that I don’t plan to install a multi-boot system, openSUSE Tumbleweed will remain my only OS. So I might not truly need more than 256 MB for the ESP.
I decided to embark on this painful journey today. Lost several hours and had to use the recovery console to repair the boot loader, but in the end I got the first phase in order.
The issue was that I stubbornly wanted to make /boot its own partition too as this seemed more consistent. First I did so using BTRFS: It worked when I ran “grub2-install /dev/sda” but if I installed the boot loader from YaST it would refuse to load it with the message:
error: file '/boot/grub2/i386-pc/normal.mod' not found.
Entering rescue mode...
grub rescue>
From what I later noticed the file was always there, so there must have been some other reason why GRUB2 couldn’t see it. I figured it’s some partition mismatch so I decided to convert it to ext4 like root, then ran grub2-install once more with no errors. Yet when I rebooted GRUB2 simply froze where it was supposed to say “GRUB Loading” (it could only display the “GRUB” part).
At that stage I figured I’ve had enough and put /boot back on the root drive, then settled for creating just the ESP and bringing back my SWAP partition in the process. /boot/efi is being mounted accordingly with no further issues.
At least “shim-install --no-nvram --removable” spared me of further grief: I ran that then rebooted perfectly fine. I now have /boot/grub2/x86_64-efi with numerous files in it, as well as a /boot/efi/EFI/boot and /boot/efi/EFI/opensuse with several .efi files and an extra grub.cfg. All that’s left is the second part once the new motherboard is operational, something I’ll be getting to a month from now at best.
The motherboard just arrived today, but will be useless until next month when I’m hoping to have both the CPU and RAM for it, as well as the BIOS update needed to support this processor. I prepared my command list for booting into rescue mode and installing shim, based on what I used this week mixed with suggestions in this thread. Please confirm that everything I mentioned here looks correct and should do the trick:
mount /dev/sda1 /mnt
mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
chroot /mnt
mount -a
# manually mount directories in case any of the above mounts failed
# mount /dev/sda2 /boot/efi
# mount -t dev dev /dev
# mount -t proc proc /proc
# mount -t sysfs sysfs /sys
# only if GRUB2 also needs to be reinstalled
# grub2-mkconfig -o /boot/grub2/grub.cfg
# grub2-install /dev/sda
shim-install
Additionally I had another important question: Will the existing openSUSE installation automatically adapt to all architecture changes on boot? Remember I’ll be switching from an Intel Core i7 / Xeon to an AMD Ryzen 7, as well as DDR3 to DDR4. As far as I’m aware such aspects are detected when the system starts up and not stored in the installation, but it’s good to be extra safe and ask for confirmation.
The “shim-install” runs the appropriate “grub2-install” behind the scenes.
As to whether it will adapt to all hardware changes – you won’t really know until you try. In my experience, it adapts to most. But it might want to install a new package for some of the hardware changes. And maybe the graphics will need some tweaking.