Results 1 to 3 of 3

Thread: temporary disk swap mangled UEFI multibooting

  1. #1
    Join Date
    Dec 2008
    Location
    FL, USA
    Posts
    1,638

    Default temporary disk swap mangled UEFI multibooting

    Based upon https://en.opensuse.org/openSUSE:UEFI I was able to
    Code:
    # efibootmgr -c -L "opensusetw" -l '\EFI\opensusetw\grubx64.efi'
    # efibootmgr
    BootCurrent: 0004
    Timeout: 1 seconds
    BootOrder: 0000,0004,0005,0003
    Boot0000* opensusetw
    Boot0003* CD/DVD Drive
    Boot0004* UEFI OS
    Boot0005* Hard Drive
    Prior to the swap, TW's Grub menu began approximately as follows:
    Code:
    memtest86 7.4 EFI
    openSUSE TW
    openSUSE 15.0
    openSUSE 15.1
    Debian 10 Buster
    Tubuntu 18.04
    Linuxmint 19
    etc.
    This was restored by the above efibootmgr -c command.

    The proximate cause of need was something I didn't save, but the following template would be close enough:
    Code:
    # efibootmgr
    BootCurrent: 0000
    Timeout: 1 seconds
    BootOrder: 0000,0001,0002,0004,0005,0003
    Boot0000* ubuntu
    Boot0001* ubuntu
    Boot0002* ubuntu
    Boot0003* CD/DVD Drive
    Boot0004* UEFI OS
    Boot0005* Hard Drive
    How it got that way was a consequence of my UEFI installation media => Boot Linux System thread setup, removing the SSD, attaching an empty HD in its place, installing 15.2, then testing "Boot Linux System" from installation media.

    How those three ubuntu entries got there I can't say. I suppose they were in the back reaches of NVRAM, put there when Kubuntu and Mint got installed, after TW and 15.0 and 15.1 and Debian, and subsequently upgraded, even though I removed all its and Debian's entries using efibootmgr, and even though I purged bootloader packages from all installations except TW. At least, I thought I purged it from all other. And, even though I adjusted most fstabs, including Kubuntu's and Mint's, except TW's by commenting each ESP partition entry, so that /boot/efi/ when running would not provide access to the ESP except when TW is running.

    On first boot after reconnecting the SSD, I expected to get the same UEFI presentation as I had been for more than a year before the storage switch. Instead, I got a grub> prompt. On restart I hit F8 to get the Asus boot menu, whereupon I found no sign of any openSUSE selection, only devices (ordinary and UEFI USB sticks; ordinary and UEFI SATA (SATA6G_3), and multiple ubuntu entries). I chose the UEFI OS entry (0004), and got another grub> prompt. From there I typed in the text of the default selection from a backup copy of grub.cfg, which got me TW booted, apparently normally. Once I found the wiki page, I found its example and used it to add the needed entry that begins this post.

    Already I've forgotten exactly what happened next, but eventually I rebooted into BIOS again. In UEFI Hard Drive Priorities, only one was listed, UEFI OS (SATA6G_3 <model#>). I selected that entry and was presented both it and opensusetw to select from. I selected opensusetw, with result that there were now two boot options, with opensusetw first, and booting is back to normal via TW's grub configuration.

    Asus Aptio/AMI BIOS date is 20181116, Version 1402 x64, ME Firmware version 11.8.55.3510, PCH Stepping AO.

    Anyone know if mangling of UEFI entries as happened to me today is typical of disk swaps in UEFI PCs?
    Reg. Linux User #211409 *** multibooting since 1992
    Primary: 42.3,TW,15.0 & 13.1 on Haswell w/ RAID
    Secondary: eComStation (OS/2)&42.3 on 965P/Radeon
    Tertiary: TW,15.0,42.3,Fedora,Debian,more on Kaby Lake,Q45,Q43,G41,G3X,965G,Cedar,Caicos,Oland,GT218&&&

  2. #2
    Join Date
    Jun 2008
    Location
    Podunk
    Posts
    26,662
    Blog Entries
    15

    Default Re: temporary disk swap mangled UEFI multibooting

    Quote Originally Posted by mrmazda View Post
    Based upon https://en.opensuse.org/openSUSE:UEFI I was able to
    Code:
    # efibootmgr -c -L "opensusetw" -l '\EFI\opensusetw\grubx64.efi'
    # efibootmgr
    BootCurrent: 0004
    Timeout: 1 seconds
    BootOrder: 0000,0004,0005,0003
    Boot0000* opensusetw
    Boot0003* CD/DVD Drive
    Boot0004* UEFI OS
    Boot0005* Hard Drive
    Prior to the swap, TW's Grub menu began approximately as follows:
    Code:
    memtest86 7.4 EFI
    openSUSE TW
    openSUSE 15.0
    openSUSE 15.1
    Debian 10 Buster
    Tubuntu 18.04
    Linuxmint 19
    etc.
    This was restored by the above efibootmgr -c command.

    The proximate cause of need was something I didn't save, but the following template would be close enough:
    Code:
    # efibootmgr
    BootCurrent: 0000
    Timeout: 1 seconds
    BootOrder: 0000,0001,0002,0004,0005,0003
    Boot0000* ubuntu
    Boot0001* ubuntu
    Boot0002* ubuntu
    Boot0003* CD/DVD Drive
    Boot0004* UEFI OS
    Boot0005* Hard Drive
    How it got that way was a consequence of my UEFI installation media => Boot Linux System thread setup, removing the SSD, attaching an empty HD in its place, installing 15.2, then testing "Boot Linux System" from installation media.

    How those three ubuntu entries got there I can't say. I suppose they were in the back reaches of NVRAM, put there when Kubuntu and Mint got installed, after TW and 15.0 and 15.1 and Debian, and subsequently upgraded, even though I removed all its and Debian's entries using efibootmgr, and even though I purged bootloader packages from all installations except TW. At least, I thought I purged it from all other. And, even though I adjusted most fstabs, including Kubuntu's and Mint's, except TW's by commenting each ESP partition entry, so that /boot/efi/ when running would not provide access to the ESP except when TW is running.

    On first boot after reconnecting the SSD, I expected to get the same UEFI presentation as I had been for more than a year before the storage switch. Instead, I got a grub> prompt. On restart I hit F8 to get the Asus boot menu, whereupon I found no sign of any openSUSE selection, only devices (ordinary and UEFI USB sticks; ordinary and UEFI SATA (SATA6G_3), and multiple ubuntu entries). I chose the UEFI OS entry (0004), and got another grub> prompt. From there I typed in the text of the default selection from a backup copy of grub.cfg, which got me TW booted, apparently normally. Once I found the wiki page, I found its example and used it to add the needed entry that begins this post.

    Already I've forgotten exactly what happened next, but eventually I rebooted into BIOS again. In UEFI Hard Drive Priorities, only one was listed, UEFI OS (SATA6G_3 <model#>). I selected that entry and was presented both it and opensusetw to select from. I selected opensusetw, with result that there were now two boot options, with opensusetw first, and booting is back to normal via TW's grub configuration.

    Asus Aptio/AMI BIOS date is 20181116, Version 1402 x64, ME Firmware version 11.8.55.3510, PCH Stepping AO.

    Anyone know if mangling of UEFI entries as happened to me today is typical of disk swaps in UEFI PCs?
    Hi
    I think from memory I saw that occur with an ASUS K55A I have here (it's a parts only machine now), never worried about it since it's easy to create new entries on the fly...
    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!

  3. #3
    Join Date
    Aug 2010
    Location
    Chicago suburbs
    Posts
    12,490
    Blog Entries
    3

    Default Re: temporary disk swap mangled UEFI multibooting

    Quote Originally Posted by mrmazda View Post
    Anyone know if mangling of UEFI entries as happened to me today is typical of disk swaps in UEFI PCs?
    I'm not sure that anything is typical. Different implementations behave differently.

    On my Dell system, the BIOS always want to clean up. It allows me to have only two named boot entries. And it only allows two because I have two hard drives with an EFI partition on each drive. If I create a third entry, then on next boot one entry will disappear. If I always use grub for booting Windows, then after a month or two the Windows boot entry will disappear. So I hit F12 during boot to get the BIOS boot menu and boot Windows that way.

    On my Lenovo system, there are many entries. If I delete a named entry, then it will come back on the next boot unless I also delete the ".efi" boot file associated with that entry. And if, some time later (even a year later), that boot file gets back there, then the BIOS will restore the corresponding named boot entry. Also, if I change the boot order with "efibootmgr -o", then the BIOS will put it back to prior boot order. If I don't want that, I have to change the boot order in the BIOS settings. If I temporarily switch to CSM booting (legacy booting), then when I restore UEFI booting the BIOS will make up its own mind on the boot order, and I have to set it up all over again.

    Using a KVM virtual machine, with the OVMF implementation of UEFI, the behavior is more like that of my Dell system.
    openSUSE Leap 15.1; KDE Plasma 5;
    testing Leap 15.2Alpha

Posting Permissions

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