Page 3 of 7 FirstFirst 12345 ... LastLast
Results 21 to 30 of 66

Thread: Upgrading an existing openSUSE installation from a standard BIOS motherboard to UEFI

  1. #21
    Join Date
    Aug 2010
    Location
    Chicago suburbs
    Posts
    13,633
    Blog Entries
    3

    Default Re: Upgrading an existing openSUSE installation from a standard BIOS motherboard to UEFI

    Quote Originally Posted by MirceaKitsune View Post
    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.
    A clean install in a UEFI environment will run
    Code:
    shim-install
    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.
    openSUSE Leap 15.2 RC; KDE Plasma 5.18.5;

  2. #22
    Join Date
    Jan 2009
    Location
    Romania, Bucharest
    Posts
    862

    Default Re: Upgrading an existing openSUSE installation from a standard BIOS motherboard to UEFI

    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.
    openSUSE Tumbleweed x64, KDE Framework 5

  3. #23
    Join Date
    Jan 2009
    Location
    Romania, Bucharest
    Posts
    862

    Default Re: Upgrading an existing openSUSE installation from a standard BIOS motherboard to UEFI

    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.
    openSUSE Tumbleweed x64, KDE Framework 5

  4. #24
    Join Date
    Aug 2010
    Location
    Chicago suburbs
    Posts
    13,633
    Blog Entries
    3

    Default Re: Upgrading an existing openSUSE installation from a standard BIOS motherboard to UEFI

    Quote Originally Posted by MirceaKitsune View Post
    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.
    Yes, that is the more standard approach.
    openSUSE Leap 15.2 RC; KDE Plasma 5.18.5;

  5. #25
    Join Date
    Aug 2010
    Location
    Chicago suburbs
    Posts
    13,633
    Blog Entries
    3

    Default Re: Upgrading an existing openSUSE installation from a standard BIOS motherboard to UEFI

    Quote Originally Posted by MirceaKitsune View Post
    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.
    I don't recommend that.

    Yes, it can work. But it is not what the software normally expects. So you will be fighting the system with every update to grub or shim.
    openSUSE Leap 15.2 RC; KDE Plasma 5.18.5;

  6. #26
    Join Date
    Jan 2009
    Location
    Romania, Bucharest
    Posts
    862

    Default Re: Upgrading an existing openSUSE installation from a standard BIOS motherboard to UEFI

    Quote Originally Posted by nrickert View Post
    I don't recommend that.

    Yes, it can work. But it is not what the software normally expects. So you will be fighting the system with every update to grub or shim.
    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.
    openSUSE Tumbleweed x64, KDE Framework 5

  7. #27
    Join Date
    Aug 2010
    Location
    Chicago suburbs
    Posts
    13,633
    Blog Entries
    3

    Default Re: Upgrading an existing openSUSE installation from a standard BIOS motherboard to UEFI

    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
    Code:
    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).
    openSUSE Leap 15.2 RC; KDE Plasma 5.18.5;

  8. #28
    Join Date
    Jan 2009
    Location
    Romania, Bucharest
    Posts
    862

    Default Re: Upgrading an existing openSUSE installation from a standard BIOS motherboard to UEFI

    Quote Originally Posted by nrickert View Post
    The software expects the EFI partition to be mounted at "/boot/efi".
    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?
    openSUSE Tumbleweed x64, KDE Framework 5

  9. #29
    Join Date
    Jun 2008
    Location
    Podunk
    Posts
    28,588
    Blog Entries
    15

    Default Re: Upgrading an existing openSUSE installation from a standard BIOS motherboard to UEFI

    Quote Originally Posted by MirceaKitsune View Post
    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.
    Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
    SUSE SLE, openSUSE Leap/Tumbleweed (x86_64) | GNOME DE
    If you find this post helpful and are logged into the web interface,
    please show your appreciation and click on the star below... Thanks!

  10. #30
    Join Date
    Dec 2008
    Location
    FL, USA
    Posts
    2,155

    Default Re: Upgrading an existing openSUSE installation from a standard BIOS motherboard to UEFI

    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.
    Reg. Linux User #211409 *** multibooting since 1992
    Primary: 15.1,TW,15.2 & 13.1 on Haswell w/ RAID
    Secondary: eComStation (OS/2)&15.1 on 965P/Radeon
    Tertiary: TW,15.2,15.1,Fedora,Debian,more on Kaby Lake,Q45,Q43,G41,G3X,965G,Cedar,Caicos,Oland,GT218&&&

Page 3 of 7 FirstFirst 12345 ... LastLast

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •