os-prober failed on btrfs root partition

English Install/Boot/Login
1

I use
os-prober-1.76-lp151.2.1.x86_64 and
grub2-2.02-lp151.21.9.1.x86_64 on leap 15.1 on the suggested btrfs.
uname -a Linux XXXX 4.12.14-lp151.28.36-default #1 SMP Fri Dec 6 13:50:27 UTC 2019 (8f4a495) x86_64 x86_64 x86_64 GNU/Linux
After updating - grub2 needed about 30 seconds to start initrd!
The cause of it was that os-prober produces no output anymore!
sudo os-prober → pause 2 seconds → no output

In /etc/default/grub
I disabled os-prober with
GRUB_DISABLE_OS_PROBER=“true”

and booting works like in former times - but it’s a workaround!

Does anybody out there with a root - btrfs experiences the same behaviour?

2

Hi and welcome to the Forum :slight_smile:
The purpose of os-prober is for the other operating systems (multi boot) not the running system, if it’s a single boot machine then is should be unchecked via YaST bootloader or via manual edit and rebuilding grub.

3

That seems like a mistaken diagnosis. Booting does not use “os-prober”. The only use of “os-prober” is to generate “grub.cfg” (defines the boot menu). It is only run while updating grub.

I don’t know why loading “initrd” was slow. But it is probably because “btrfs” is a complex file system, and it took many operations to read the file. Note that loading “initrd” uses BIOS or UEFI firmware operations, since it occurs before the kernel is running.

Back at the beta testing stage, I had Leap 15.1 running in a virtual machine, with “btrfs”. Most of the time it was fine. On one particular boot, it took several minutes for the boot menu to show up. It probably would have taken an hour to boot. I aborted the boot, and then booted from rescue media. Using the rescue media, I mounted the “btrfs” file system, and then I unmounted it. After that, booting worked fine. My guess is that the file system got itself into an awkward state that was hard for grub to use. I have not had that happen again.

In /etc/default/grub
I disabled os-prober with
GRUB_DISABLE_OS_PROBER=“true”

and booting works like in former times - but it’s a workaround!

Does anybody out there with a root - btrfs experiences the same behaviour?

I have "Leap 15.2 Alpha with “btrfs” (in a virtual machine). I disable OS_PROBER, because I don’t need it.

But I just booted the machine, and ran “os-prober”. It produced no output. This was actually what I expected, because there are no other operating systems for it to probe.

Seems normal to me.

On my current desktop with Leap 15.1, running “os-prober” produced 3 lines of output


# os-prober
/dev/sda1@/efi/Microsoft/Boot/bootmgfw.efi:Windows Boot Manager:Windows:efi
/dev/mapper/nwr2wdc2-root1:openSUSE Tumbleweed:openSUSE:linux
/dev/mapper/nwr2wdc2-root3:openSUSE Leap 15.0:openSUSE:linux

As you can see, it does not mention the running Leap 15.1. It mentions only the other installed systems (Tumbleweed, Leap 15.0 and Windows 8.1).

I really don’t think you have an os-prober problem. Rather, you have a problem that “btrfs” file systems occasionally can get into a temporary state where they are slow until fixed on the next successful boot.

4

On my btrfs partitions I have some older versions of opensuse installed (leap 15.0 for example) - so it’s some kind of multi-boot!
In the past I could boot from this partition by grub2-menu - it is not possible now.
OK - I don’t miss it very much - but strange anyway

5

Running “os-prober” from the command line is supposed to find those other systems. If it does, then re-enable os-prober and those other systems should show up again in the boot menu.

6

OK - I will keep my eyes open - if os-prober somewhere in the future (after an update) find my other system-partitions again.
I had hoped somebody has the same problem and has worked out a solution (there were some messages in the net with problems of grub2 and btrfs - partitions - but they seemed to be solved in the current versions!?
But you know some bugs try a revival!
Thanks anyway!

7

Thus far, “btrfs” seems to be working better during my testing of Leap 15.2 Alpha, than it ever did for Leap 15.1. I should add, however, that I have been staying with “ext4” on the systems that I mainly use.