Just installed openSUSE Leap 16.0 (beta) to see if it would run my favourite filemanager (worker, its versatile, highly configurable and as it is decades in the making light on resources http://boomerangsworld.de/cms/worker/downloads/worker-5.2.2.tar.zst) which runs great.
BUT
The splash screen has entries for my previous Leap 15.6 and Mint 22, but I cannot boot them.
During the installation of 16.0 I marked the partitions for my installed distros that I wanted to keep (as above with also an older Mint) and these have indeed been left intact (the UUIDs of the Mint partitions are still the same). But I did allow my ESP partition to be overwritten, thinking that the installer Agama would allow multi-booting as I could when installing previous editions of Leap. While Mint boot menu did not offer booting SUSE I could boot it (SUSE) from my PC’s BIOS but now those entries are no longer there.
It seems that the best way to get back to my previous distros is to try and repair the Mint 22 boot up? :-\
P.S. I’m sure I selected a UK keyboard (the installer doesn’t offer a type-and-check-box) but I have a US keyboad 
Now a retired software engineer (35+ years), I learned early to never install a pre-GA release of an operating system to the bare-metal. Only install them in a virtual machine.
Especially for the Agama installer … it is also in a pre-GA state and is well-known to be very buggy. Okay, I’m done with personal opinions.
First question: you wrote “The splash screen has entries” … are you referring to the GRUB boot menu?
When you attempt to boot Leap 15.6 and Mint 22 … “I can not boot them”.
Why? What errors do you see, if any ?? (you can usually press ESC after selecting an entry to see text output). Do you see anything? Or does it lock up?
You can boot Leap 15.6 using your PC’s BIOS boot selection, and you state, “but now those entries are no longer there”. Does that mean, if you reboot back into the BIOS boot menu options, you no longer see ANY entries?
Or you don’t see the original GRUB boot menu? (that could be because you changed the default boot choice in the BIOS … if yes, change back to original).
Note: all the following presumes grub2-x86_64-efi installed by Agama and in control, not systemd-boot.
The ESP is home to the UEFI bootloader entries that the UEFI BIOS loads from. Thus, your prior installations’ boot entries are now history. They are actually quite easy to recreate from a rescue boot, but before you try, examine the ESP’s directory tree to see whether Agama put an opensuse directory there, or something else. If only BOOT and opensuse, then you need to adjust your 15.6 and/or 16.0’s /etc/default/grub files’ GRUB_DISTRIBUTOR= entry(s) to some unique value(s), such as GRUB_DISTRIBUTOR="leap16" or GRUB_DISTRIBUTOR="opensuse156". Whatever value(s) you assign will when this process is complete become the applicable directory name(s) for the installation on the ESP, and within UEFI BIOS setup. Once done editing, YaST Bootloader can be used to employ these changes on the current ESP. Optionally, the same can be done with efibootmgr. Mint may have a tool equivalent to YaST, but whether or not it does, efibootmgr can do Mint too, whether within Mint boot or openSUSE. One of my own notes contains the following example of new entry creation:
## gb250 20221108
# grep DISTR /etc/default/grub
GRUB_DISTRIBUTOR="opensusetw"
# efibootmgr -c -L "opensusetw" -d /dev/nvme0n1 -l '\EFI\opensusetw\grubx64.efi'
# efibootmgr
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0004,0005,0003
Boot0000* opensusetw
Boot0003* CD/DVD Drive
Boot0004* UEFI OS
Boot0005* Hard Drive
#
As you formatted the ESP, you’ll also need to update /etc/fstab for each installation to conform the ESP’s UUID= to match its current value, unless your fstabs are configured to use an alternate to UUID= that was not changed by the ESP formatting process.
@Stoobie Times they are a changing 
Is it using systemd-boot? If so my understanding is for dual/multiboot it just needs a loader enrty…
See https://en.opensuse.org/Systemd-boot and https://manpages.opensuse.org/Tumbleweed/systemd-boot/loader.conf.5.en.html
As pointed out by @myswtest it’s for testing and shouldn’t be used on something that is in use… If it’s a test system, then I would start again to document and report as a bug…
And how is it Agama fault? You decided to remove bootloaders of other installed Linux systems and Agama did what you told it to do.
Yes, because you decided to remove them.
Working with Computers since the introduction of the HP 21MX E-Series in 1976 I learned the same year to never trust software engineers. I always rely on common sense instead.
This implies to always install to bare-metal.
Users losing their EFI System Partition may want to boot into a netinstall iso and click “More > Boot Linux System > Select a system to boot”.
“splash screen”? Do you mean Grub?
Have you booted to a Live /Rescue USB flash drive (or similar) to access the hard drive distros??
Booting using the netinstall usb I used to install does not give the option of “More> Boot Linux System >”. It does give the option of booting from the hard disk which unsurprisingly results in the same booting into emergency system of the distro (see my further replies for details). The UEFI fimware options menu choice does not offer the previous distros since those ar lost as pointed out by MrMazda and arvidjaar.
I should probably try the 15.6 install USB or a SUSE rescue USB?
yep - worked here
Apologies for delay in replying, I have been finding and copying files I needed urgently (was using an overlay file-system so some were on one file-system and some on another).
Yes I did mean the GRUB boot menu.
I did try using my installation of VirtualBox but the iso I had downloaded and checked would not install on it (froze at initrd). Googling I only found a reference to using VMware so I gave up and tried installing from it to find it was in fact missing some repositories so went for the net install instead (did not think that would work with VirtualBox). So I should have used an old spare machine. Lesson learned.
[quote]
I was too hasty. Booting Leap 15.6 it seemed to stop after several rounds of
Stopped Virtual Console Setup
Stopping ditto
Starting ditto
and other started … and reached target…
Then a long pause and and then a couple of minutes of dracut-initqueue: starting timeout scripts alternating with other warning entries. then starting the emergency shell. It allows a root login with the password and offers a rdsosreport.txt with much information for debugging.
The Mint shows much less information and boots int toe root login directly, offering only journalctl -xb for info. But it did load my overlay filesystem!
That suggestion worked well (ran grub-mkconfig -o /boot/grub/grub.cfg as suggested by the comment at the head of the /etc/default/grub file since there is no longer any YAST in Leap 16.0 see SDB:System upgrade to Leap 16.0 - openSUSE Wiki)
Thanks.
Well perhaps I should have tried the “upgrade” option from the 15.6 Leapinstallation iso. But I didn’t do that, I chrooted into my 15.6 from the rescue prompt as per the fine details in a youtube video by KMDtech on openSUSE (try this search https://www.youtube.com/results?search_query=How+to+fix+Grub+KMDTech). I think it worked but it won’t boot probably because the UUID of the ESP partition is changed. I thought a dracut -f might rebuild the initramfs but the kernel on the installation iso is older than any still in the /boot directory of my (now broken) installation. With my luck if I wait for a new respin of the installation iso its kernel will probably be too new for me! I suppose the “right thing” to do is to copy the kernel from the iso into the /boot directory before running dracut but I’m not sure…
Any thoughts?
You don’t say what you did, and I won’t use Youtube to try to find out what you did, or anyone else did, as a substitute for print documentation. What did you do? What does “won’t boot” actually put on the screen, any error messages? What’s the last thing you see before you determine it “won’t boot”?
From what I can tell here on one of my own, the ESP’s filesystem UUID may be entirely irrelevant to boot success, but I suppose that could be because of the non-default value LABEL I use instead of UUID for persistent_policy=:
# cat /etc/dracut.conf.d/13-persistent-local.conf
persistent_policy="by-label"
# efibootmgr | grep tw
Boot0000* opensusetw HD(1,GPT,6419............................1b27,0x800,0xa0000)/File(\EFI\opensusetw\grubx64.efi)
# lsblk -o NAME,FSTYPE,LABEL,PARTUUID,UUID | head -4
NAME FSTYPE LABEL PARTUUID UUID
...
├─nvme0n1p1 vfat PT3P01ESP 6419............................1b27 30A0-3A09
# lsinitrd | grep -iE 'uuid|label|esp|vfat'
drwxr-xr-x 2 root root 0 Jun 24 19:42 etc/systemd/system/dev-disk-by\x2dlabel-PT3P01ESP.device.d
-rw-r--r-- 1 root root 60 Jun 24 19:42 etc/systemd/system/dev-disk-by\x2dlabel-PT3P01ESP.device.d/timeout.conf
lrwxrwxrwx 1 root root 40 Jun 24 19:42 etc/systemd/system/initrd.target.wants/dev-disk-by\x2dlabel-PT3P01ESP.device -> ../dev-disk-by\x2dlabel-PT3P01ESP.device
-rwxr-xr-x 1 root root 35000 Jun 10 07:16 usr/lib64/libuuid.so.1.3.0
lrwxrwxrwx 1 root root 16 Jun 24 19:42 usr/lib64/libuuid.so.1 -> libuuid.so.1.3.0
-rw-r--r-- 1 root root 28489 Jun 19 11:39 usr/lib/modules/6.12.34-1-longterm/kernel/drivers/input/keyboard/applespi.ko.zst
-rw-r--r-- 1 root root 15787 Jun 19 11:39 usr/lib/modules/6.12.34-1-longterm/kernel/fs/fat/vfat.ko.zst
lrwxrwxrwx 1 root root 8 Jun 24 19:42 usr/sbin/fsck.vfat -> fsck.fat
-rw-r--r-- 1 root root 94 Jun 24 19:42 var/lib/dracut/hooks/emergency/80-\x2fdev\x2fdisk\x2fby-label\x2fPT3P01ESP.sh
-rw-r--r-- 1 root root 38 Jun 24 19:42 var/lib/dracut/hooks/initqueue/finished/devexists-\x2fdev\x2fdisk\x2fby-label\x2fPT3P01ESP.sh
root=LABEL=pt3p07stw rootfstype=ext4 rootflags=rw,noatime
#
Clearly, my systems’ initrds do not appear to reference filesystem UUIDs.
Something that worked for me in the past following a disk migration that resulted in new UUID on the ESP was to append rd.hostonly=0 rd.auto=1 to Grub’s linu lines. Once successfully booting using those options, another initrd rebuild or new kernel installation dispensed with those options’ subsequent need.
I’ve traditionally had infrequent need to run dracut in chroot, so don’t remember details of the procedure since mkinitrd was retired, but I think simply dracut -f won’t do. I think at least -kver and <output-file> are required parameters, if not more.
Hmm. from the links you gave I’m guessing the Leap16 installation might be using systemdboot. But I have been trying to get my Leap 15.6 working and lost the option to boot Leap16…
I will try and follow your leads. In the meantime I will put down “what I did”.
I booted from a Leap 15.6 iso and got the rescue system by choosing
more > Rescue System > Choose Keyboard > Login prompt
and entering root (no password).
From the root prompt I could run lsblk of fdisk -l and blkid to verify my partitions IDs.
Then ran this code:-
mnt /dev/nvme0n1pX /mnt # X representing the partition number for my openSUSE Leap15.6
mount /dev/nvme0n1pY /mnt/boot/efi # Y representing the partition number for my efi partition (1 in my case)
for i in /dev /dev/pts /proc /sys /run; do mount -B $i /mnt$i; done # mounts psuedo filesystems from the running rescue system into the chroot directory
chroot /mnt # chroot into 15.6 as root; gets a red root prompt
mount -t efivarfs none /sys/firmware/sys/efi/efivars # make efi vars available in chroot environment (note only one f in destination directory)
grub2-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader=opensuse # The directory opensuse was already present on my 15.6 system so I went with that suggestion
os-prober # showed other OSs present including Leap 16.0
grub2-mkconfig -o /boot/grub2/grub.cfg # made new grub.cfg configuration file
exit # exit out of chroot back to rescue systemAt this point I unmounted the psuedo filesystems before rebooting but I suppose this is unnecessary.
On rebooting the SUSE grub screen was headed up by Leap 15.6 (with an advanced options below it followed by Leap 16 and Mint 22 (each with an advanced options menu entry). Only the Leap 16 and Mint 22 would boot into the familiar desktop. In Mint 22 the efi partition was not mounted so I suppose it is not using that partition somehow?
Then I repeated the above process with a new download of the 15.6 iso (as my original iso said it was a beta version). Now I still have a total of three OSs to try and boot from the grub menu but Leap 16 has been replaced by Mint 21.3, which also does not boot properly. It starts off by declaring its root partion to be clean, waits a few minutes then says “Timed out waiting for device /dev/disk/by-uuid/D017-FC0B” followed by some dependency failed messages and then allows booting into mergency mode. lsblk does not show a uuid corresponding to D017-FC0B and it must be the UUID of thye boot partition for Leap 15.6.
Choosing the Leap 15.6 option results in a few messages suggesting a normal boot (described earlier in another reply of mine on this topic) followed after a few minutes by recurrent entries saying [number that I think represents time since started] dracut-initqueue[476]: Warning: /lib/dracut/hooks/initqueue/finished/devexists\x2fdev\x2fd… D017-FC0B …
Then one saying starting timeout scripts, then one saying still waiting then these three lines repeated until
[ 203.992361] dracut-initqueue[476]: Warning: could not boot
Starting Dracut Emergency Shell…
Warning: /dev/disk/by uuid/D017-C0B does not exist
Generating “/run/initramfs/rdsosreport.txt”
Then a few more lines and “Give root password for maintenance”
Hope that clears up my situation; will try your suggestions.
Perhaps I could’ve found a way to boot using this option (it didn’t work straight off). I also tried using the update option. I went for a re-install in the end, so not marking this as solved. Then I could run YAST from the desktop . I will miss it in Leap 16 (not using the beta version until I get a second machine to run) and I think I didn’t see the “Have a lot of fun” message on logging in on a terminal…
Thank you to all for their help and advice.