Installed Leap 15.3 but it won't boot

I have Leap 15.2 installed on a hard disk and installed Leap 15.3 on a SSD. The SSD is first in the boot loader, but it never boots even if I choose the SSD from the BIOS boot menu. It always boots Leap 15.2 on the hard disk instead. I probably did something wrong somewhere. Some of the things I’m unsure about:

  • Installer questions:
    • secure boot enable/disable?
    • update NVRAM enable/disable?
  • BIOS configuration:
    • CSM enable/disable?
    • secure boot enable/disable?

I looked at the EFI partition in both installations. In Leap 15.2 I have:

**boot   ****grub   ****opensuse**

bootx64.efi   fallback.efi

MokManager.efi   boot.csv   grub.cfg   grub.efi   shim.efi

MokManager.efi   boot.csv   grub.cfg   grub.efi   grubx64.efi   shim.efi

In Leap 15.3 I have:



So certainly a lot less in the Leap 15.3 installation. I intended to, but may not have, install both as UEFI not BIOS boot.

I would guess you have separate efi partitions on the HDD and SSD? If so, it’s just the efi NVRAM not knowing the order. In your BIOS Boot menu can you select an EFI file to boot from? If so, use this to browse to the SSD efi entry and select to boot from the grubx64.efi file.

If it’s not there, then some more work is needed…

That’s fine if you are not using secure-boot. However, if you have enabled secure-boot, then that won’t work for booting 15.3.

Can you provide the output from:

efibootmgr -v

It should not matter whether you get that from booting 15.2 or from booting the installer to the rescue system.

efibootmgr -v:

EFI variables are not supported on this system.

Secure boot is disabled in the BIOS. During installation, I disabled secure boot in the installer. I thought that was only needed for Windows and I don’t run Windows on this computer. I figured it might cause problems if it was enabled.
I also disabled NVRAM update because I didn’t know what that does. Maybe that’s what borked the installation.
I have an installation of Leap 15.2 on a hard disk with it’s own EFI partition, and and installation of Leap 15.3 on a NVMe SSD with it’s own EFI partition.
I’m thinking about reinstalling Leap 15.3 and leaving secure boot and update NVRAM enabled and see what happens.
I haven’t found an option to choose an EFI entry during boot. The boot menu only presents the devices to boot from.
I wanted both Leap 15.2 and Leap 15.3 to use EFI boot not BIOS boot. However, I read that if booting from ISW/IRST RAID 1 that the bootloader has to be installed in the MBR. Does that mean it can only use BIOS boot and not EFI boot?

That indicates that you are using tradition BIOS/MBR booting, so what’s in the EFI partition does not matter.

I don’t know about RAID and EFI. Maybe someone else can comment on that.

However, I’m not sure what you are showing. Perhaps you installed 15.3 for UEFI booting, but then booted the installer to the rescue system using traditional MBR booting to get that output (from “efibootmgr -v”).

I have NVRAM update disable here. But at some time in the past, it was enabled for the install. I’m not sure what happens if you disable that during install.

The flag for secure-boot support should not matter, as long as you have disabled secure-boot.

On systems with all installations installed in EFI mode, the BIOS may present a BBS menu with only one option. If you have multiple installations of any same distro sharing a single ESP, such as a 15.2, a 15.3, a 15.4 and a TW, without a minimal configuration adjustment to all-1 (e.g. 4-1=3), there will be only one entry in the ESP filesystem to boot from, labeled “opensuse”. This is the equivalent of Grub on MBR on legacy systems, where the last to be installed or have a kernel added or removed, becomes in charge by writing to the MBR, usurping control from whichever installation last had control.

To avoid this there are multiple options. The best is probably via /etc/default/grub, replacing the null value for GRUB_DISTRIBUTOR= to something unique, as with the null value, the actual value becomes opensuse. On one of mine which is booted ATM it is GRUB_DISTRIBUTOR=“opensuse154”. My others are opensusetw, opensuse153, etc.

Something else I do in addition, is comment out the fstab line for the ESP partition on all installations but one, which results in no ESP filesystem modifications as a result of Grub installation or updates from any of the other installations.

Yet another customization is my use of /boot/grub2/custom.cfg. This is a self-built Grub menu script that depends on the symlinks to kernels and initrds, which automatically gets incorporated in the menu Grub displays at boot, via customization in /etc/grub.d/. When custom.cfg exists, its entries are automatically incorporated in the menu it displays at boot, due to the presence of 40_custom and 41_custom in /etc/grub.d/. By copying 40_custom and 41_custom to 06_custom and 07_custom, the custom.cfg entries are moved to the top of the Grub boot menu. Because of the symlink usage in custom.cfg, it needs maintenance quite infrequently, mainly when a distro is added, dist-upgraded or removed.

Users may easily miss a critical step. Write down a checklist:

More background:

Host i3-4130 has triple boot:

i3-4130:~ # find /boot/efi/EFI/ -maxdepth 1
/boot/efi/EFI/opensuse    # default, happens frequently to be overwritten inadvertently
/boot/efi/EFI/tumbleweed  # Tumbleweed
/boot/efi/EFI/Microsoft   # Windows
/boot/efi/EFI/BOOT        # backup
/boot/efi/EFI/leap        # Leap
i3-4130:~ # 

Tumbleweed grub configuration:

**i3-4130:~ #** cat /etc/default/grub              
# If you change this file, run 'grub2-mkconfig -o /boot/grub2/grub.cfg' afterwards to update 
# /boot/grub2/grub.cfg. 

# Uncomment to set your own custom distributor. If you leave it unset or empty, the default 
# policy is to determine the value from /etc/os-release 
**GRUB_DISTRIBUTOR=Tumbleweed **
GRUB_CMDLINE_LINUX_DEFAULT="quiet plymouth.enable=0 net.ifnames=0 mitigations=auto" 

# Uncomment to automatically save last booted menu entry in GRUB2 environment 

# variable `saved_entry' 
#Uncomment to enable BadRAM filtering, modify to suit your needs 

# This works with Linux (no patch required) and with any kernel that obtains 
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...) 
# GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef" 
#Uncomment to disable graphical terminal (grub-pc only) 

# The resolution used on graphical terminal 
#note that you can use only modes which your graphic card supports via VBE 

# you can see them in real GRUB with the command `vbeinfo' 
# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux 
#Uncomment to disable generation of recovery mode menu entries 

#Uncomment to get a beep at grub start 

# GRUB_INIT_TUNE="480 440 1" 
**i3-4130:~ #**


I’m leaving the existing Leap 15.2 installation as is and installing Leap 15.3 on another drive. Each installation has it’s own drive with ESP and root partitions. To multi-boot, I’m trying to use the BIOS boot menu (to choose the boot device) instead of the GRUB boot menu (to choose an installed system). Should this work as well?


I’ll study this information and work on it further.


Thanks for the help and information

Affirmative. (“Yes” is too short, rejected as sole input.)

I decided to go ahead and redo the installation as I thought it may automagically work if I answered the questions correctly, and indeed it did. It did not show an option to import users, maybe because I didn’t know to mount /home during install? I have a separate home partition in Leap 15.2 and want to use that with Leap 15.3. How can I manually import existing users from my Leap 15.2 installation? I figure I can edit fstab and add an entry to mount /home and copy the passwd and shadow files. Would that work or is there more that must be done?

Examine /etc/passwd on the old installation to find the uid & gid for each user. Alternatively, run ls -n on the filesystem normally mounted to home, which will show the numeric uid and gid for each directory. On the new installation, do

useradd -g *gid* -u *uid* *username*

for each account that needs to be added. Follow that up by setting passwords for each account and you should be good to go for login purposes, but you’ll probably want to add some users to some non-default groups either via YaST, or by editing /etc/group, according to what you find in the old /etc/group file.