Can't boot after upgrade from Leap 42.2 to 42.3

Hello, I decided to upgrade my single-installation Leap 42.2 server as that version is no longer supported. The upgrade (from a USB drive) seemed to go OK but when the system had it’s first reboot, it went straight into the Asus (EUFI) motherboard setup mode instead of booting into the new installation (I’d removed the USB drive - was that right?). I am able to boot into the new system using ‘Boot Linux system’ option on the USB drive, but I don’t know what to do to fix this problem. Can anyone give me any pointers?

Is the UEFI set to boot openSUSE by default. Assuming a EFI boot and not a legacy :\ Guess we need more info then just “it’s broke”

Original boot method, new boot method (hope they are not different)

Assuming you got it running show efibootmgr -v

Well I think the problem is that the original and new are not the same. I’m fairly sure that the original system was a UEFI boot (is there some way of checking this now?) but the new one isn’t. I get:

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

And in the Yast->Boot Loader, I have ‘GRUB2’ not ‘GRUB2 with EFI’.
I’ve disabled Secure Boot in the BIOS setup, but it doesn’t (apparently) make any difference, and I’m worried that I’m going to make things worse by fiddling around in the BIOS settings. I can still boot into the USB drive and from there to my Leap system, but if I remove the USB drive it just boots into the BIOS setup.
Having searched around a bit, as I understand it the upgrade and boot installation is dependent on the mode in which the installation media itself was booted (is that right?) - in which case, is it possible that I’ve somehow managed to boot my (apparently UEFI compatible) USB drive in non-EFI mode?
And if that’s what has happened, what’s the best way of untangling this mess?! Eg if I can ‘force’ the USB drive to boot in UEFI mode (and how would I do that?), do I just run the Upgrade process again - would that work?
I don’t really care whether the end system is UEFI or non-UEFI - it’s a home file server - I just want it to work! And as it seems that upgrades are going to be necessary at least every year, it would be good to learn so that I don’t make a mistake again.
Thanks for any help.

Therefore the box does have UEFI and therefore you should choose “GRUB2 with EFI” in YaST.
[HR][/HR]It worked OK with Leap 42.2 but, not with 42.3: possibly something in the 42.3 GRUB2 is a little bit more picky with respect to non-UEFI setup with a UEFI-capable motherboard.

Thanks for the replies. This is where I’m up to. I’ve done as suggested and changed to ‘GRUB2 with EFI’ - that seemed to install OK. However the system still wouldn’t boot.
I checked that Secure Boot was disabled in the BIOS, and double checked with:

od -An -t u1 /sys/firmware/efi/vars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c/data

Running efibootmgr now gives:

efibootmgr -v
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0002,0001
Boot0001* UEFI: KingstonDataTraveler G3    PciRoot(0x0)/Pci(0x12,0x2)/USB(2,0)/HD(1,MBR,0x1b681c50,0x107c,0x1e84)..BO
Boot0002* Hard Drive     BBS(HD,,0x0)..GO..NO........o.W.D.C. .W.D.1.0.J.F.C.X.-.6.8.N.6.G.N.0....................A...........................>..Gd-.;.A..MQ..L. . . . .W. .-.D.X.W.1.X.1.A.A.7.H.L.H.X........BO..NO........q.K.i.n.g.s.t.o.n.D.a.t.a.T.r.a.v.e.l.e.r. .G.3....................A.......................D..Gd-.;.A..MQ..L.K.i.n.g.s.t.o.n.D.a.t.a.T.r.a.v.e.l.e.r. .G.3........BO..NO........i.M.a.s.s. .S.t.o.r.a.g.e. .D.e.v.i.c.e....................A.......................<..Gd-.;.A..MQ..L.M.a.s.s. .S.t.o.r.a.g.e. .D.e.v.i.c.e........BO

That looked odd to me! So I tried creating a new EFI entry to the grubx64.efi file in /boot/efi/EFI/opensuse [FONT=arial](my EFI partition is [FONT=courier new]/dev/sda3):[/FONT]

efibootmgr -c -p 3 -l \\EFI\\opensuse\\grubx64.efi -L "opensuse-grubx64"
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0000,0002,0001
Boot0001* UEFI: KingstonDataTraveler G3
Boot0002* Hard Drive 
Boot0000* opensuse-grubx64

But again, it wouldn’t boot from the hard disk. And more strangely, when I ran [FONT=courier new]efibootmgr again, the new entry had disappeared.
Next I ran gdisk to see if the GPT partitioning was OK, first:[/FONT]

gdisk /dev/sda
GPT fdisk (gdisk) version 0.8.8

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

which looks alright, but then:

gdisk -l
GPT fdisk (gdisk) version 0.8.8

Problem opening -l for reading! Error is 2.
The specified file does not exist!

looks bad. Could this be a problem?

So I’m still stuck, and would be grateful for any more clues (or tests).


I believe you need to give gdisk a drive to list check with man gdisk for calling details

Yes you’re right, so ignore the last bit. So I think GPT is set up OK?
Another thing which might help. As l said, I can’t boot the system directly, but can boot it from the installation USB drive using ‘More…->Boot Linux system’. But if I select ‘Boot from hard drive’ (ie the first item) I get an error "Not a valid root partition’ (something like that, I’m not in front of it at the moment). What’s more if I now try ‘Boot Linux system’ it falls with another error, and I have to restart.
Can anyone tell me what the ‘boot from hard drive’ option on the installation medium is trying to do, as that may be a significant clue?
Thanks for help so far

Please check the boot order displayed in UEFI/BIOS and if possible move the openSUSE EFI up in the priority list.

Please check again the current settings displayed by ‘efibootmgr’.

From the rescue system on the installation .ISO, please check what “parted -l” is reporting for the partitions on the disk.

Just making sure that, we have an example of functional non-dual-boot (openSUSE Leap 42.3 only) laptop UEFI settings:

 # parted -l
Model: ATA ST1000LX015-1U71 (scsi)
Disk /dev/sda: 1000GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system     Name     Flags
 1      1049kB  165MB   164MB   fat16           primary  boot
 2      165MB   8225MB  8060MB  linux-swap(v1)  primary
 3      8225MB  94,1GB  85,9GB  btrfs           primary
 4      94,1GB  1000GB  906GB   xfs             primary

 # gdisk -l /dev/sda
GPT fdisk (gdisk) version 0.8.8

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 1953525168 sectors, 931.5 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 5974E051-0815-44FC-922E-85F5B7855739
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 1953525134
Partitions will be aligned on 2048-sector boundaries
Total free space is 3437 sectors (1.7 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048          321535   156.0 MiB   EF00  primary
   2          321536        16064511   7.5 GiB     0700  primary
   3        16064512       183832575   80.0 GiB    0700  primary
   4       183832576      1953523711   843.9 GiB   0700  primary
 # efibootmgr 
BootCurrent: 0000
Timeout: 0 seconds
BootOrder: 0000,0002,2001,2002,2003
Boot0000* opensuse-secureboot
Boot0002* EFI HDD Device (ST1000LX015-1U7172)
Boot0007* EFI Network
Boot2001* EFI USB Device
Boot2003* EFI Network
 # efibootmgr --verbose
BootCurrent: 0000
Timeout: 0 seconds
BootOrder: 0000,0002,2001,2002,2003
Boot0000* opensuse-secureboot   HD(1,GPT,432f0931-2e5c-4274-955b-92239c264ee4,0x800,0x4e000)/File(\EFI\opensuse\shim.efi)
Boot0002* EFI HDD Device (ST1000LX015-1U7172)   PciRoot(0x0)/Pci(0x11,0x0)/Ata(0,0,0)/HD(1,GPT,432f0931-2e5c-4274-955b-92239c264ee4,0x800,0x4e000)RC
Boot0007* EFI Network   RC
Boot0008* EFI DVD/CDROM (MATSHITABD-MLT UJ262)  PciRoot(0x0)/Pci(0x11,0x0)/Ata(1,0,0)/CDROM(1,0x224,0x1ed469)RC
Boot2001* EFI USB Device        RC
Boot2003* EFI Network   RC

dcurtisfra, thanks again for your reply. This is what I have for the partitions:

parted -l
Model: ATA WDC WD10JFCX-68N (scsi)
Disk /dev/sda: 1000GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags: pmbr_boot

Number  Start   End     Size    File system     Name     Flags
 1      1049kB  34.4GB  34.4GB  btrfs           primary  legacy_boot
 2      34.4GB  68.7GB  34.4GB  btrfs           primary
 3      68.7GB  68.8GB  107MB   fat16           primary  boot
 4      68.8GB  77.4GB  8587MB  linux-swap(v1)  primary
 5      77.4GB  1000GB  923GB   xfs             primary

What jumps out immediately is the disk flag, which you don’t have on your working setup, and the partition flag on 1 which should be ‘boot’ only. I will find try changing them and see if it makes a difference. For the efibootmgr:

efibootmgr -v
BootCurrent: 0003
Timeout: 0 seconds
BootOrder: 0003,0002
Boot0002* Hard Drive     BBS(HD,,0x0)..GO..NO........o.W.D.C. .W.D.1.0.J.F.C.X.-.6.8.N.6.G.N.0....................A...........................>..Gd-.;.A..MQ..L. . . . .W. .-.D.X.W.1.X.1.A.A.7.H.L.H.X........BO..NO........i.M.a.s.s. .S.t.o.r.a.g.e. .D.e.v.i.c.e....................A.......................<..Gd-.;.A..MQ..L.M.a.s.s. .S.t.o.r.a.g.e. .D.e.v.i.c.e........BO..NO........q.K.i.n.g.s.t.o.n.D.a.t.a.T.r.a.v.e.l.e.r. .G.3....................A.......................D..Gd-.;.A..MQ..L.K.i.n.g.s.t.o.n.D.a.t.a.T.r.a.v.e.l.e.r. .G.3........BO
Boot0003* UEFI: KingstonDataTraveler G3    PciRoot(0x0)/Pci(0x12,0x2)/USB(1,0)/HD(1,MBR,0x1b681c50,0x107c,0x1e84)..BO

I don’t have any other bootable devices (eg DVD) on the system. As I mentioned above, I can’t get changes made using efibootmgr to persist.
Your diagnostic questions are helping me to learn, which I appreciate.

Problem solved. I can’t thank you enough. I switched the disk and partition 1 flags off using parted. The BIOS now ‘sees’ the opensuse system, I changed the boot order (and switched off the CSM in the BIOS while I was at it) et voila. A working system that boots properly.
The moral of this story (apart from, what a great support community) is - if you’re upgrading a UEFI system with a USB drive and need to enter the BIOS to boot it, make sure you boot it in UEFI mode! I would have thought that the upgrade process ought to be able to detect the mismatch and gracefully fail somehow - but that’s easy for me to say…

On your system, the FAT16 partition number ‘3’ is the EFI boot partition; the Btrfs partition number ‘1’ is a legacy (MBR) bootable partition.
You need to make sure that, for the case of an UEFI boot, partition number ‘3’ is the one to be used by the boot process.

The boot order is indicating that, first a USB stick will be selected for the boot process and then, if the USB stick is not available, a Western Digital HDD will be selected for the boot process.
Unfortunately, the entry for the Western Digital HDD doesn’t point to an openSUSE SHIM EFI file located in the EFI boot partition (partition number ‘3’).
“/etc/fstab” has to contain an entry to mount the Western Digital HDD partition number ‘3’ as “/boot”:
You should be able to find the HDD partition number ‘3’ in “/dev/disk/by-id/”.

In addition, ‘efibootmgr’ seems to be reporting some corruption for the case of the “Boot0002” entry: there shouldn’t be any references to a Kingston Data Traveler USB stick in that Western Digital HDD entry.

Just for the record, an example UEFI/Btrfs/XFS /etc/fstab:

 > cat /etc/fstab
UUID=c0a219eb-5ea7-470b-9297-3e0d70964554 swap swap defaults 0 0
UUID=fa6a0367-a191-447e-8298-35761792b861 / btrfs defaults 0 0
UUID=fa6a0367-a191-447e-8298-35761792b861 /boot/grub2/i386-pc btrfs subvol=@/boot/grub2/i386-pc 0 0
UUID=fa6a0367-a191-447e-8298-35761792b861 /boot/grub2/x86_64-efi btrfs subvol=@/boot/grub2/x86_64-efi 0 0
UUID=fa6a0367-a191-447e-8298-35761792b861 /opt btrfs subvol=@/opt 0 0
UUID=fa6a0367-a191-447e-8298-35761792b861 /srv btrfs subvol=@/srv 0 0
UUID=fa6a0367-a191-447e-8298-35761792b861 /tmp btrfs subvol=@/tmp 0 0
UUID=fa6a0367-a191-447e-8298-35761792b861 /usr/local btrfs subvol=@/usr/local 0 0
UUID=fa6a0367-a191-447e-8298-35761792b861 /var/cache btrfs subvol=@/var/cache 0 0
UUID=fa6a0367-a191-447e-8298-35761792b861 /var/crash btrfs subvol=@/var/crash 0 0
UUID=fa6a0367-a191-447e-8298-35761792b861 /var/lib/libvirt/images btrfs subvol=@/var/lib/libvirt/images 0 0
UUID=fa6a0367-a191-447e-8298-35761792b861 /var/lib/machines btrfs subvol=@/var/lib/machines 0 0
UUID=fa6a0367-a191-447e-8298-35761792b861 /var/lib/mailman btrfs subvol=@/var/lib/mailman 0 0
UUID=fa6a0367-a191-447e-8298-35761792b861 /var/lib/mariadb btrfs subvol=@/var/lib/mariadb 0 0
UUID=fa6a0367-a191-447e-8298-35761792b861 /var/lib/mysql btrfs subvol=@/var/lib/mysql 0 0
UUID=fa6a0367-a191-447e-8298-35761792b861 /var/lib/named btrfs subvol=@/var/lib/named 0 0
UUID=fa6a0367-a191-447e-8298-35761792b861 /var/lib/pgsql btrfs subvol=@/var/lib/pgsql 0 0
UUID=fa6a0367-a191-447e-8298-35761792b861 /var/log btrfs subvol=@/var/log 0 0
UUID=fa6a0367-a191-447e-8298-35761792b861 /var/opt btrfs subvol=@/var/opt 0 0
UUID=fa6a0367-a191-447e-8298-35761792b861 /var/spool btrfs subvol=@/var/spool 0 0
UUID=fa6a0367-a191-447e-8298-35761792b861 /var/tmp btrfs subvol=@/var/tmp 0 0
UUID=fa6a0367-a191-447e-8298-35761792b861 /.snapshots btrfs subvol=@/.snapshots 0 0
UUID=85FD-C13A       /boot/efi            vfat       umask=0002,utf8=true  0 0
UUID=31ee5d31-773e-4a8f-8862-876413323c28 /home                xfs        defaults              1 2

And the UUID decode:

 > lsblk --fs
├─sda1                   /boot/efi
├─sda2                   [SWAP]
├─sda3                   /var/cache
└─sda4                   /home

And now, with the user ‘root’:

 # blkid -U 85FD-C13A
 # partx --show /dev/sda1
 1  2048 321535  319488 156M primary 432f0931-2e5c-4274-955b-92239c264ee4

As you can hopefully see from my post #11 (which may have crossed with yours), thanks to your diagnostic tips (especially using parted -l) I’m all sorted now. I’m so grateful.

Thanks also for your responsiveness during the trouble-shooting.
Can you possibly post the output of “efibootmgr --verbose”? It would nice to confirm that, the entry for the HDD is now displaying a sensible value.

Yes, it’s quite easy to get confused in the BIOS/UEFI boot choices and, most of the examples seem to be for Microsoft machines … :frowning:
[HR][/HR]BTW: I should have posted the “lsblk -f” example for the case that the user ‘root’ is used:

 # lsblk -f
NAME   FSTYPE LABEL UUID                                 MOUNTPOINT
├─sda1 vfat         85FD-C13A                            /boot/efi
├─sda2 swap         c0a219eb-5ea7-470b-9297-3e0d70964554 [SWAP]
├─sda3 btrfs        fa6a0367-a191-447e-8298-35761792b861 /
└─sda4 xfs          31ee5d31-773e-4a8f-8862-876413323c28 /home

So - I now get this:

efibootmgr -v
BootCurrent: 0004
Timeout: 0 seconds
BootOrder: 0004,0005
Boot0004* opensuse    HD(3,GPT,1d306f3b-88ea-4d9f-bbac-36d01055461a,0x7ffd800,0x33000)/File(\EFI\OPENSUSE\GRUBX64.EFI)..BO
Boot0005* UEFI OS    HD(3,GPT,1d306f3b-88ea-4d9f-bbac-36d01055461a,0x7ffd800,0x33000)/File(\EFI\BOOT\BOOTX64.EFI)..BO

This all looks OK? The 2nd entry is one I created myself as a test following something I found online (the opensuse .efi file was just copied and renamed). I’ll probably get rid of it now. I’ve also disabled Compatibility Support in the BIOS, as it seems I don’t need it and it may be a menace!
I’ve spent several hours trying to crack this problem, time which I’ll never get back. Yet weirdly I feel happier now than I did beforehand. Is that just me…? Thanks again.

Yes indeed! The 1st boot in the list is now pointing to an EFI file, and GPT is mentioned, which is what’s needed …