I’m planning to do a hardware upgrade and require help with one aspect. Until today I’ve been using a motherboard from 2010, very good but now ancient in terms of features. I’m about to get a modern mobo, but this implies an important change: The old one has the classic type of BIOS, while the new one uses UEFI and potentially SecureBoot. I have openSUSE Tumbleweed installed on my existing mobo and don’t wish to reinstall from scratch: I’ll be plugging the same hard drives into the new board and trying to boot that as usual.
I need to know if there’s anything I must do once changing the motherboard, such as reinstalling the boot loader from a rescue console in order for it to handle the new architecture. Will GRUB2 automatically recognize the switch from an old BIOS to a UEFI motherboard, or do I have to run dracut again and reinstall the boot loader once the new mobo is plugged in? If so then what are the exact commands I will need to use?
I’m assuming openSUSE can handle other hardware differences on my existing install. For instance my current motherboard uses an Intel Xeon CPU, the new one will be an AMD Ryzen… also DDR3 versus DDR4. Is it correct to assume my existing install will automatically adapt to all those architecture changes once booting with the new devices? I believe they’re read by the Kernel on boot, not configured permanently in the OS installation… so I’m hoping this won’t be an issue.
Good to know, I might do that if it does. But I’d rather not be stuck using legacy settings if I can help it. In case I’m not given this option, how do I tell GRUB2 to work with the new architecture? Can I perhaps configure it in advance to support both legacy and UEFI?
This page offers a limited explanation, but doesn’t dive into how to upgrade an existing installation without having to reinstall the whole OS from scratch.
I also understand that UEFI might be tied to changes in partitioning: The old method uses MBR, the new one apparently has an alternative called GPT. Is is possible to redo the partitioning on the root drive and convert mbr to gpt? Do I actually need to do this at all, or does UEFI work well with existing mbr based setups?
I never would try to change a MBR partitioned disk into an GPT one in situ with expecting the partitions (and all the data on them) being untouched.
To begin with the GPT partition table is larger then the MBR one, thus everything must be moved towards the end (impossible when the disk is full with partitions). And so on.
Seems I panicked over nothing regarding the partitioning: “parted -l” tells me I’m already using gpt and not mbr. Phew!
mircea@linux-qz0r:~> sudo parted -l
[sudo] password for root:
Model: ATA ADATA SU900 (scsi)
Disk /dev/sda: 256GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 1049kB 256GB 256GB ext4 legacy_boot
Model: ATA ST32000641AS (scsi)
Disk /dev/sdb: 2000GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:
Number Start End Size Type File system Flags
1 1049kB 2000GB 2000GB primary ext4 type=83
I’m assuming the latest openSUSE version I did a fresh install with managed to use gpt with my old motherboard. Or perhaps it’s EFI enabled: My current mobo is a GIGABYTE GA-X58A-UD7 Rev. 1.0, I understand it should be new enough to have EFI but not UEFI.
It is not the point. To boot in UEFI mode you need extra partition (ESP - EFI System Partition). Size depends, openSUSE installer will complain if it is less than 256MB but technically as long as you will use only one openSUSE, ESP will only contain small bootloader binary.
ESP can be located on any disk accessible to firmware. Once you managed to create this partition (or at least free space for it), come back and we can discuss next steps.
As you’re keeping your existing drives and software installation I’d definitely go down the route of setting the new MB to legacy booting.
I’ve been there myself, swapping a Gigabyte GA-MA770 (non UEFI) for a Gigabyte GA-970A (UEFI), and that was the option I chose, use legacy booting.
There was no obvious benefit I could see in using UEFI, which together with the attendant need to mess around with an existing software setup, seemed not only the easiest, but the safest way to go.
If in the future you do a new install, then you can use that opportunity to switch to UEFI booting.
Each to their own, others may offer differing views…
So there will be a bit of extra trouble involved with partitioning. My root drive is 256 GB so a 256 MB partition is no issue. The root partition will likely need to be resized however, meaning I must boot into Rescue Mode from the openSUSE USB installation stick.
Is there a command to automatically do this and redo the partitioning, without endangering the existing data on my root partition? Can I prepare this ESP partition in advance with my existing (non-UEFI) motherboard?
As far as SecureBoot is concerned I should have no issues: Their BIOS should allow me to not just disable it, but also clear and import keys as needed:
Seriously, there are tools to resize and re-partition. Any such action means risk to existing data. You are always advised to have backup before attempting it. I did not use any of these tools, may be someone may share experience.
Can I prepare this ESP partition in advance with my existing (non-UEFI) motherboard?
Yes. Disk partitioning does not depend on boot mode.
If grub2 is already booting with legacy, then you need:
(1) an EFI partition, mounted at “/boot/efi”. If you have at least one drive with GPT partitioning, create the EFI partition there. Failing that, create in your disk with DOS/Legacy partitioning, and give the partition a type code of “ef” (you can do that with “fdisk”). Whether that will work depends on your UEFI firmware. It works for me when booting an external drive, but I don’t know if it would work with an internal drive.
(2) With that EFI partition mounted at “/boot/efi”, run the command:
shim-install --no-nvram --removable
That won’t install the NVRAM entry for booting openSUSE (because it cannot be installed unless you are already booted with UEFI). But it will provide most of what you need. You might already be able to boot after the upgrade, by using the boot entry for the hard drive (the drive with the EFI partition). But that depends on the UEFI firmware, and the support varies between manufacturers. You will, at least, have a good start and it will be relatively easy to fix later.
I have a Clonezilla USB stick and will backup an image of my root partition before messing with it. Usually there’s no risk during re-partitioning, except a power outage while it’s working though I use an SSD so it should take less than an hour to move 100 GB of data.
The main issue is what tool and command I need to use, considering I must boot from a rescue console to do this. I assume there’s no way to tell YaST2 how to resize the root partition then have it do that on the next reboot before mounting it?
I know. I asked if I can do it now since I was thinking of reconfiguring GRUB2 to use this new partition in advance. But I assume the new UEFI mobo must first be in place for that to work and the system isn’t compatible with non-UEFI ones.
Very helpful, thank you very much! I’ll get to this once I know I have the mobo… it will take a few more weeks or months to also buy the CPU and RAM so I’ll have time for this preparation.
My only specific question till then is the one I dropped above: Can I tell YaSY2 Partitioner how I want the root partition to be resized, then have it apply those changes on the next reboot? Obviously I can’t resize it while it’s mounted, and even more obviously I can’t unmount the root partition while the OS is running. I’m trying to avoid using just console commands and would prefer the GUI to see what I’m doing.
I’m trying to avoid using just console commands and would prefer the GUI to see what I’m doing.
There are dozens of live images with GUI tools like gparted. I’m sure openSUSE images include one, otherwise there is knoppix, sysrescuecd, gparted etc etc etc.
Part of bootloader configuration in UEFI is storing boot options in motherboard NVRAM which is impossible unless you are already booted in UEFI mode. You can prepare ESP content, that’s true. But unless your BIOS allows direct booting from file, you will need to boot from live image to complete configuration anyway at which point you can just as well spare previous step. At the end it is up to you.
So the normal openSUSE installation image includes gparted? I remember it contains a few tools as I once used it to run memtest on new RAM modules. I’ll check this out later.
Fair enough. So is it safe to run “shim-install --no-nvram --removable” while still on the old motherboard, or does that tell GRUB2 to already use it?
Also: Is it okay to put this 256 MB partition at the end of my root drive instead of the beginning? I remember the partitioner doesn’t need to move data on a partition when you change its ending point, only if you move the starting point further ahead… also I’d like the main root partition to still be called sda1 instead of becoming sda2.
One more thing: Can anyone else using an UEFI board please paste the contents of their etc/fstab file? I’d like to see exactly what the parameters are, so I can recreate the setup a fresh install would as accurately as possible.
That is safe. It won’t change how your system is currently booted. But it adds the directory “/boot/grub2/x86_64-efi” with what is needed for UEFI booting.
Installation image probably not (it cannot even be booted into GUI mode), but Live images - yes. You have XFCE, GNOME, KDE to chose from.
Also: Is it okay to put this 256 MB partition at the end of my root drive instead of the beginning?
As I said - partition should be accessible by firmware. Putting it in the beginning is more robust, but one hopes that modern EFI firmware should be able to cope with large disks. You will never know until you try. Anyway, reducing filesystem size is relatively safe, and if it won’t work you always can use e.g. gparted to move partitions around.
Just to be clear: Is this what the openSUSE DVD would normally set on install? I’m trying to recreate exactly what a fresh install would to, but without needing to preform one due to having to redo many system changes again.
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. I selected that entry out of curiosity… it’s a little intimidating as everything changes and it removes all previous kernels and parameters from the list. But if that’s it I can use the old motherboard to give this final command before shutting down the system to change mobos, which I assume means the new one would go ahead and boot without any issues?
It’s not clear to me why there is discussion of “converting” to UEFI just because of a new motherboard. I’d reserve “converting” for such time as a replacement boot device is to be installed, or it becomes time for a different OS to be installed.
When I got my newest Gigabyte motherboard 22 months ago, I installed everything from scratch using an SATA SSD and UEFI mode. After some months I cloned its SSD to an M.2 device and retired out the original SSD. Later still I added a pair of SATA disks, retired from my main system, that always and only ever used MBR and Grub (Legacy), and with a bunch of partitions, and 7 MD devices. When I want to boot from the old disks, I hit F12 during POST, select the P0 device (/dev/sda), and up comes the Grub Gfxmenu just like it did in the old PC. When I want to boot the M.2, I just wait a few seconds for POST to complete and show me Tumbleweed’s grub-efi menu (automatically from UEFI BIOS P5) so I can make a selection. The only things I remember needing to adjust when adding the SATA disks to the Gigabyte were network configuration and hostname.
…