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.
I disabled os-prober with
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
/dev/sda1@/efi/Microsoft/Boot/bootmgfw.efi:Windows Boot Manager:Windows:efi
/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.