After Leap 42.1 kernel security update I lost Tumbleweed option to boot.

Hi all,
I have two separate ssd drives and decided to wipe them out using gparted and created
a gpt disk for use on a minimal x installation of openSUSE Leap 42.1 and Tumbleweed’s latest snapshot.
in efi mode.
The third drive is a rotating disk I use for storage and swap.

This is how the partitioning goes.

Tumbleweed on /dev/sda
/dev/sda1 /boot/efi
/dev/sda2 /
/dev/sda3 /home
openSUSE Leap 42.1 on /dev/sdb
/dev/sdb1 /
/dev/sdb2 /home

Swap is in the third drive
openSUSE Leap 42.1 and Tumbleweed share a common
/boot/efi partition which is the /dev/sda1 /boot/efi

Now the story of installation,
Today I made a minimal x installation of openSUSE Leap 42.1
and did not bother to update, (maybe my mistake).
After the installation, I followed the minimal x installation of Tumbleweed.
All went well. When I rebooted the machine, Tumbleweed now is responsible
for booting both operating systems. I tried both of them and I was successful booting.
The problem came-out after, when I tried to update openSUSE Leap 42.1. There was
kernel security update and after the update was finished and rebooted the machine
The gub2 boot screen changed, it is now Leap that handles the boot process and
Tumbleweed vanished from the grub2 boot screen options.I also notice that the
/tumbleweed/root/boot/efi/ folder is empty. Previously I had Tumbleweed and Leap
in this machine, the only difference is that, both operating system has it’s own
or separate /boot/efi partition.

Any advice is appreciated, I thank you in advance.

If Tumbleweed and Leap are sharing the same EFI partition, then I would normally expect that the last to install would be in charge of booting. That seems to be Tumbleweed.

If this was the first update since install, then I seem to recall that there was an update to grub2, which installed here on Nov 21. You would have just installed that at the same time as the kernel update. That would have reinstalled booting, and left Leap in charge of booting.

If you turned of “probe for foreign OS” in boot settings in Leap, then you would not have an entry to boot Tumbleweed.

That’s my best guess as to what has happened.

As to what to do to fix your problem – it depends on whether you are using secure boot. In particular, it depends on whether you are using the UEFI nvram entry for “opensuse” or for “opensuse-secureboot”. You can check by looking at the output from

# efibootmgr -v

I have tried several way of handling different opensuse versions with EFI. And what I have settled on is what I am doing now. So in the directory “/boot/efi/EFI/opensuse”, I have two subdirectories. One is “tumbleweed” and the other is “42_1”. I have copied the boot file content to those directories for the two versions. Then, when I want to change which has boot priority, I copy the corresponding subdirectory to its parent directory.

If there’s an update that switches things around, I copy the updated files back to the appropriate subdirectory. I copy files that match .

I named the subdirectory “42_1” rather than “42.1” so that it would not match .

Hi,
Thanks for the response.
Here is the the output of efibootmgr -v

BootCurrent: 0000
Timeout: 0 seconds
BootOrder: 0000,0001,0002,0005,0006,0007,0008
Boot0000* opensuse-secureboot    HD(1,GPT,bff9945b-c585-485a-8176-dd891a9e79a7,0x800,0x82000)/File(\EFI\opensuse\shim.efi)

And probe foreign os is enabled on Leap

Anyway to try probing the other os (tumbleweed) outside yast?
Please advice.

To add to my previous post
It doesn’t matter to me which os will handle the booting
as long as both will appear in the grub2 boot screen as an option

They should, except that perhaps the use of “btrfs” confuses this. Or at least that was a problem back when I tried “btrfs” with 13.1.

As for your specific problem, look at “/boot/efi/EFI/opensuse/grub.cfg”. Since you are currently booting Leap, that’s the Leap version of the file. Save a backup copy somewhere (such as in a subdirectory).

That file should contain something like:


set btrfs_relative_path="yes"
search --fs-uuid --set=root f6ae00ee-3678-4c75-935d-5e8ca82a5ad0
set prefix=(${root})/boot/grub2
configfile $prefix/grub.cfg

That funky string on the end of the second line will be the UUID of the partition for “/boot” on Leap (it will be a different number from what I show).

Change that to the UUID of the partition for “/boot” on Tumbleweed, and you should resume booting Tumbleweed. You can get the UUID with the “blkid” command.

Hi,

I followed your point and replace the line as you pointed in your post with / uuid of tumbleweed and reboot.
The grub2 boot screen now reverted to tumbleweed and the openSUSE Leap 42.1 option is now visible.
However, selecting to boot the openSUSE Leap 42.1 to boot was no go, so I selected Tumbleweed and I was
able to reach the login screen and finally was able to make it operational again. I went to yast2-bootloader
and run the boot loader and reboot and now openSUSE Leap 42.1 is now working from the Tumbleweed
grub2 boot screen option.

There could be some differences with the boot loader of Tumbleweed vs. Leap 42.1, it looks like Leap is a bit crippled
by failing to probe foreign os.

Thanks for your quick and precise assessment of my problem. I can now say this thread as solve.

Because of the kernel update in Leap, you have to update the boot loader in Tumbleweed for it to boot Leap. Sorry, I should have mentioned that. My aim was to get you into Tumbleweed, so that you fix things.

There could be some differences with the boot loader of Tumbleweed vs. Leap 42.1, it looks like Leap is a bit crippled
by failing to probe foreign os.

You can check that with

 grep PROBER /etc/default/grub

My guess is that it does probe. However Leap is using an older version of “os-prober” which might be giving problems.

Hi,

Thanks again.
I added the tumbleweed snapshot dvd iso awhile ago as a repository in Leap
and updated the grub2, efi, os-prober etc. that I was thinking missing link
in Leap, but there was no difference. It can’t probe tumbleweed.:\

I am happy now to see that I can boot both os any time I want.
There might be an update in the future that will fix this.