Upgrade LEAP 42.1 ->42.2 ->42.3 -- Can no longer dual boot into Windows

I finally got around to upgrading the OS on my HP Elitebook 8470P from LEAP 42.1 to 42.2 using a DVD which I verified on that machine. When I got done, there was no longer a menu item in grub2 to boot Windows 10. Rather than wasting a lot of time trying to figure out why, I just went ahead and upgraded that OS to LEAP 42.3. Same problem.

I confirmed that os-prober was enabled in /etc/default/grub and issued the command

# grub2-mkconfig

from a root prompt. When I looked at /boot/grub2/grub.cfg, there was no entry between BEGIN and END for 30_os-prober. I couldn’t find any usage docs for os-prober, so I tried

# os-prober 2&1> somefile

and saw that somefile had a size of zero.

So I grabbed the entry for 30_os-prober from the grub.cfg file from my 42.1 backup and inserted that entry into /boot/grub2/grub.cfg. When I tried booting from the menu entry for Windows, I got

error: invalid signature

press any key ...

So I tried editing the chainload command to add the --force option. The screen went blank for a few seconds and then rebooted.

Here is the os-prober entry I added to /boot/grubs/grub.cfg

### BEGIN /etc/grub.d/30_os-prober ###
menuentry 'Windows Boot Manager (on /dev/sda1)' --class windows --class os $menuentry_id_option 'osprober-efi-7EB1-87B3' {
        savedefault
        insmod part_gpt 
        insmod fat
        set root='hd0,gpt1'
        if  x$feature_platform_search_hint = xy ]; then
          search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1  7EB1-87B3
        else
          search --no-floppy --fs-uuid --set=root 7EB1-87B3
        fi
        chainloader /EFI/Microsoft/Boot/bootmgfw.efi
}
### END /etc/grub.d/30_os-prober ###

I have confirmed that all of the files in the EFI System partition (partition #1) are exactly the same as the files in my 42.1 backup. IIRC, I had to copy some files from EFI/Boot/opensuse in the EFI System partition to EFI/Boot and rename one of them (I think it was grubx64.efi) to bootx64.efi after the 42.1 install in order to get grub2 to load instead of Windows.

But how do I fix this now? I feel like I’m running out of options.

This machine has Secure Boot disabled and is set to boot in UEFI with CSM mode. Even though it’s only a 500GB drive, it is configured as GPT and the partitioning looks like

# fdisk -l /dev/sda
Disk /dev/sda: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: F760F8C6-BCB8-11E5-8121-806E6F6E6963

Device         Start       End   Sectors   Size Type
/dev/sda1       2048    206847    204800   100M EFI System
/dev/sda2     206848    468991    262144   128M Microsoft reserved
/dev/sda3     468992   2566143   2097152     1G Linux filesystem
/dev/sda4    2566144 556687359 554121216 264.2G Linux LVM
/dev/sda5  556687360 567173119  10485760     5G Microsoft basic data
/dev/sda6  567173120 973232428 406059309 193.6G Microsoft basic data
/dev/sda7  973234176 976773119   3538944   1.7G Windows recovery environment

Partition #3 is mounted at /boot, and the rest of the openSuSE filesystems are in the LVM partition at #4. Windows is located in Partition #6

I have noticed that there are some size differences between the files in EFI/Boot and EFI/opensuse

# ls -l /boot/efi/EFI/Boot/
total 2152
-rwxrwxr-x 1 root root 1155520 May 15 11:51 bootx64.efi
-rwxrwxr-x 1 root root   71672 May 15 11:51 fallback.efi
-rwxrwxr-x 1 root root     150 Jan 23  2016 grub.cfg
-rwxrwxr-x 1 root root  973944 Jan 23  2016 grub.efi

# ls -l /boot/efi/EFI/opensuse/
total 3338
-rwxrwxr-x 1 root root      58 May 15 11:51 boot.csv
-rwxrwxr-x 1 root root     141 May 15 11:51 grub.cfg
-rwxrwxr-x 1 root root  977784 May 15 11:51 grub.efi
-rwxrwxr-x 1 root root  121344 May 15 11:51 grubx64.efi
-rwxrwxr-x 1 root root 1159776 May 15 11:51 MokManager.efi
-rwxrwxr-x 1 root root 1155520 May 15 11:51 shim.efi

Could that be my problem? do I have to manually copy the grub2 files to EFI/Boot again? If that’s the case, why did booting continue to work correctly in 42.1 when all of the files pre- and post- install compare correctly?

I would very much appreciated any guidance you folks can provide.

ron

Hi
Something is funky…

I see;


ls -l /boot/efi/EFI/Boot/
total 1160
-rwxrwxr-x 1 root root 1183584 Jul 15  2016 bootx64.efi

ls -l /boot/efi/EFI/opensuse/
total 3480
-rwxrwxr-x 1 root root 1166552 Sep 24 13:27 MokManager.efi
-rwxrwxr-x 1 root root      58 Sep 24 13:27 boot.csv
-rwxrwxr-x 1 root root     155 Sep 24 13:27 grub.cfg
-rwxrwxr-x 1 root root 1009528 Sep 24 13:27 grub.efi
-rwxrwxr-x 1 root root  184320 Sep 24 13:27 grubx64.efi
-rwxrwxr-x 1 root root 1164376 Sep 24 13:27 shim.efi

os-prober
/dev/sda1@/EFI/Microsoft/Boot/bootmgfw.efi:Windows Boot Manager:Windows:efi

efibootmgr -v

BootCurrent: 0002
Timeout: 0 seconds
BootOrder: 0002,3002,0000,0001,2001,2002,2004
Boot0000* openSUSE    HD(1,GPT,4940529e-67c8-4438-a9b1-8c270332f3e3,0x800,0x82000)/File(\EFI\opensuse\grubx64.efi)RC
Boot0001* Windows Boot Manager    HD(1,GPT,4940529e-67c8-4438-a9b1-8c270332f3e3,0x800,0x82000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...e................
Boot0002* opensuse-secureboot    HD(1,GPT,4940529e-67c8-4438-a9b1-8c270332f3e3,0x800,0x82000)/File(\EFI\opensuse\shim.efi)
Boot2001* EFI USB Device    RC
Boot3001* Internal Hard Disk or Solid State Disk    RC
Boot3002* Internal Hard Disk or Solid State Disk    RC

Maybe look at forcing the re-install of the shim package?

Indeed!

I see

# efibootmgr -v
EFI variables are not supported on this system.

As I indicated above, I had to manually copy (and rename) some of the files from EFI/opensuse to EFI/Boot in order to get the original 42.1 install to boot into grub2->openSuSE. Before doing that, it would only boot directly into Windows (no grub).

Maybe look at forcing the re-install of the shim package?

I’m not sure how that would help, since Secure Boot is disabled in this system. Could you clarify?

Thanks,
ron

Hi
So it’s booting in Legacy mode, not UEFI… since you have a separate /boot

So if you press F9 at boot, can you select an efi image to boot? Your in CSM mode, if you switch back to UEFI mode does it boot?

When I had a ProBook 4440s with windows it was a little funky in CSM mode from memory…

Actually, I have a separate /boot so savedefault will work in grub. I have /boot formatted as ext4, since savedefault won’t work in a btrfs filesystem. Within the LVM I also have separate filesystems mounted at /tmp, /opt, /srv, /var & /home (I don’t need /usr/local). That comes from the old days of administering version 7 and SVR2 systems, where you absolutely want to minimize the writes (and the possibility of corruption) to the root filesystem. Old habits die hard :).

No, if I turn off CSM, it won’t boot. I also see that there’s actually boot code in the legacy mbr. Seems to me that it would boot with CSM off after the 42.1 installation, but I turned CSM back on so I could boot UBCD, clonezilla, etc.

So- if I turn CSM off, then boot from the 42.3 DVD to do an upgrade, will it convert this system back into a UEFI system? Or do I have to restore 42.1 from the backup and start the upgrade over?

Is there an easier way to change this to boot from UEFI?

Thanks,
ron

On Mon 16 Oct 2017 05:56:01 PM CDT, r widell wrote:

malcolmlewis;2841930 Wrote:
> Hi
> So it’s booting in Legacy mode, not UEFI… since you have a separate
> /boot
>
> So if you press F9 at boot, can you select an efi image to boot? Your
> in CSM mode, if you switch back to UEFI mode does it boot?
>
> When I had a ProBook 4440s with windows it was a little funky in CSM
> mode from memory…

Actually, I have a separate /boot so savedefault will work in grub. I
have /boot formatted as ext4, since savedefault won’t work in a btrfs
filesystem. Within the LVM I also have separate filesystems mounted at
/tmp, /opt, /srv, /var & /home (I don’t need /usr/local). That comes
from the old days of administering version 7 and SVR2 systems, where you
absolutely want to minimize the writes (and the possibility of
corruption) to the root filesystem. Old habits die hard :).

No, if I turn off CSM, it won’t boot. I also see that there’s actually
boot code in the legacy mbr. Seems to me that it would boot with CSM off
after the 42.1 installation, but I turned CSM back on so I could boot
UBCD, clonezilla, etc.

So- if I turn CSM off, then boot from the 42.3 DVD to do an upgrade,
will it convert this system back into a UEFI system? Or do I have to
restore 42.1 from the backup and start the upgrade over?

Is there an easier way to change this to boot from UEFI?

Thanks,
ron

Hi
Well if you switch to UEFI, then there should be a final summary page
of what is going to happen (I don’t do upgrades on my openSUSE
machines)? But if it does boot and as you have the required ESP it
should work.

If you switch before and select the efi file does it boot (it may fail
as it’s the old efi files) or attempt to boot?


Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
openSUSE Leap 42.2|GNOME 3.20.2|4.4.87-18.29-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!

Unfortunately. F9 doesn’t permit me to select an efi file from the ESP. The only option for booting from efi file is an alternate device (USB-HD, DVD, etc.) When I try to boot from efi file, it asks me to choose the file system, but the ESP on the internal drive is not shown as an option. Also, when selecting the boot order under UEFI, it doesn’t show the internal HD, just “OS Boot Manager” (presumably EFI/Boot/bootx64.efi).

I’ve got some honey-do list items to take care of before the sun goes down and I’ll be at the VA almost all of tomorrow, so I won’t be able to get back to it until Thursday.

BTW- this was originally a Windows 7 mbr/legacy boot system which I converted to UEFI/gpt before installing LEAP 42.1. I upgraded to Windows 10 just prior to the published expiration of the free upgrade.

Since I blew away the original bootx64.efi, I think I’ve got 4 alternatives to try:

  1. Burn a Windows 10 DVD and efi boot from that and try to do a repair. That may restore the EFI/Boot/bootx64.efi OS Boot Manager.
  2. Efi boot from the LEAP 42.3 DVD and try to redo the upgrade. With any luck, that will fix my problems.
  3. Copy grubx64.efi, grub.efi and grub.cfg from /boot/efi/EFI/opensuse to /boot/efi/EFI/Boot and rename grubx64.efi to bootx64.efi.
  4. Restore the entire drive from the clonezilla image and convert the LEAP 42.1 to Tumbleweed.

I’ll let you know how far down the list I need to go before it starts working again.

Thanks,
ron

Hi
If you can try a full UEFI boot rather than CSM with winX?

No joy.
I wiped out the original OS Boot Manager (EFI/Boot/bootx64.efi) after the LEAP 42.1 install because it ONLY booted Windows 7 (now 10). It didn’t even give me a choice. Just straight to Windows.

That’s why I copied grubx64.efi from EFI/opensuse to EFI/Boot and renamed it bootx64.efi after renaming the old OS Boot Manager (HP speak) to bootx64.efi-old. On subsequent boots I got complaints about not finding grub.efi and grub.cfg, so I copied them to EFI/Boot as well. Then the machine started booting properly into grub and from there i could get to either openSuSE or Windows. That’s when I blew away the original bootx64.efi

Right now it won’t boot into ANYTHING with a full EFI (no CSM) boot.

And that is why doing a Windows repair install was first on my list. I’m hoping that a repair install will restore the original bootx64.efi.

More on Thursday,

ron

Executive summary–
It must have been a poltergeist.

While waiting for the Windows iso dvd to finish burning, I decided to try upgrading the non-functional 42.3 to 42.3. I got the complaint that the system was not a valid upgrade target, but I told it to go ahead. I tried that approach 3 times, as it kept erroring out, but got further each time. Until the last time-- at that point the system wouldn’t boot from the hard drive in either UEFI nor legacy mode. It just didn’t recognize the hard drive.

So I wiped the drive and restored everything from my clonezilla image. Hooray! I was back in business.

  1. I could boot up either windows or openSUSE from the grub menu.
  2. I could hit F9 at startup and had lots of options:
    a) I could boot from the OS Boot Manager (which got me into the grub menu)
    b) I could boot from the Notebook Upgrade Bay (optical drive) which would boot either a UEFI or legacy bootable optical disc. And if it was
    booting in UEFI mode, “UEFI” was in parenthesis for that option.
    c) I could network boot (IP4 or IP6)
    d) I could boot from EFI file and it actually saw the internal hard drive, so I could go into any of the subdirectories in the ESP and choose to boot
    directly into that OS entry.

In short, everything was again working like it was supposed to work. So I tried installing LEAP 42.2 again (since that was the source of my original problem). The firmware was still configured to boot in UEFI with CSM mode. And it did boot into UEFI mode, when I got to the part of the upgrade where the package manager presents the summary of what the upgrade will entail I carefully examined the section for the bootloader. It was set to install grub2-efi, use os-prober, remove any legacy mbr. So I went ahead with the upgrade and waited to see what happened.

Once again, there was no menu entry for Windows. So I confirmed that I could boot into Windows via F9->Boot from EFI file (I could). I booted back into LEAP 42.2 and confirmed that /etc/default/grub was still configured to enable os-prober (it was). So I

# grub2-mkconfig > grub.cfg

to see if os-prober would work this time. It did. I got notifications on the console and the was also an entry between the BEGIN and END statements for 30_os-prober in the new, local grub.cfg. So I moved the new grub.cfg into /boot/grub2 and just for good measure did a

# update-bootloader

before restarting the machine.

The grub menu came up as expected, and I can boot into either Windows or LEAP 42.2. I’m still experimenting to see if I can figure out why Malcom can get by with only bootx64.efi in /EFI/Boot (in the ESP), but I reconfirmed that if I remove grub.efi and grub.cfg as loaded in /EFI/opensuse from /EFI/Boot, the machine will boot straight into Windows, with no chance of getting into grub (and openSUSE).

I have to assume that the first time I tried upgrading that this machine, for whatever reason, booted from the DVD in legacy mode, and not UEFI mode. I don’t know why. It doesn’t do it after the restore from image, and it shouldn’t have done it earlier. But that’s the only explanation for the earlier behavior.

Thanks for your patience,
ron

Hi
The HP Bios efi nvram will probably have a hard drive entry? If so I think there is some hard coding to boot into windows… a feature :wink: ?

I wouldn’t find that at all surprising, even though according to the docs on the HP website, this particular model could also be configured with Linux in lieu of Windows (IIRC, it was some version of SUSE 11.x).

On the off chance that there was an alphabetical component, I renamed /EFI/opensuse to /EFI/1-opensuse. It still booted into Windows.

But I noticed something strange (this time-- I hadn’t noticed it before). Before it booted Windows there was a very brief error message in the upper left corner of the screen which read somethign to the effect:

error loading grub.cfg

There were a couple more lines but I couldn’t make them out.

I have also noticed that the LEAP 42.[23] ISOs have grub.efi and grub.cfg in addition to bootx64.efi in the EFI/Boot directory. All I know is that their presence is required in that directory on this machine in order to automatically boot into grub and get the grub menu.

Thanks again for the patience and information. I have no idea WHY the first upgrade attempt of LEAP 42.2 booted in legacy mode, but that’s the only logical explanation for what happened. I still have to decide whether to move on to LEAP 42.3 or go back to 42.1 and convert to Tumbleweed, but that’s not a decision you can make for me.

ron