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
0
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).
[/FONT]
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)
Boot0006* EFI DVD/CDROM
Boot0007* EFI Network
Boot0008* EFI DVD/CDROM (MATSHITABD-MLT UJ262)
Boot2001* EFI USB Device
Boot2002* EFI DVD/CDROM
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
Boot0006* EFI DVD/CDROM 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
Boot2002* EFI DVD/CDROM 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
NAME FSTYPE LABEL UUID MOUNTPOINT
sda
├─sda1 /boot/efi
├─sda2 [SWAP]
├─sda3 /var/cache
└─sda4 /home
sr0
>
And now, with the user ‘root’:
# blkid -U 85FD-C13A
/dev/sda1
# partx --show /dev/sda1
NR START END SECTORS SIZE NAME UUID
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 … 
[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
sda
├─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
sr0
#
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 …