[Testing Update] 2021-04-16 - Kernels, Mesa, Wine, Plasma5, KDE Frameworks, LibreOffice, Bluez

The line in /etc/default/grub should be “GRUB_DISABLE_OS_PROBER=false” or just “#” in the begining of the line.
You should do a “sudo update-grub” in terminal.

The OS Prober message is expected, this is not a failure of any sort. It warns you that OS Prober is disabled in your Grub config file so it won’t detect other OS. Show you Grub config file maybe you overlooked something.

@servimo && @omano: If I understood @michaldybczak’s post correctly they are reporting a mis-detection of the current config state on their machine and subsequently a wrong (not fitting) message.

1 Like

I understood, hence the need to see his Grub config file, when I update Grub with the configuration he says he has, it works as intended.

Generating grub configuration file ...
Found theme: /boot/grub/themes/pacbang/theme.txt
Found linux image: /boot/vmlinuz-5.10-x86_64
Found initrd image: /boot/amd-ucode.img /boot/initramfs-5.10-x86_64.img
Found initrd fallback image: /boot/initramfs-5.10-x86_64-fallback.img
Warning: os-prober will be executed to detect other bootable partitions.
It's output will be used to detect bootable binaries on them and create new boot entries.
Found Windows Boot Manager on /dev/sdc1@/efi/Microsoft/Boot/bootmgfw.efi
Adding boot menu entry for UEFI Firmware Settings ...
done

(And I just noticed a typo in the message, it should be “Its” and not “It’s”)

1 Like

Exactly. My os-prober was disabled with that fatal update some time ago (a month or two ago?) but I fixed it with the recommended command, which added a proper line in config and updated it. Since then, os-prober is working fine, Win10 is detected.

The message in the current update erroneously claims that os-prober is disabled, which is not and claims that I should uncomment line that is already uncommented. As far I understand, the script in the update simply failed its task as it fed me with an incorrect message.

So basically, I didn’t have to do anything but the update suggested otherwise.

2 Likes

The check isn’t fit to work with multiple occurences of the word GRUB_DISABLE_OS_PROBER in /etc/default/grub - that might be the case with @michaldybczak’s file.

2 Likes

Changed from Unstable to Testing now to not get any breaking changes

Hence my initial suggestion:

Disclosing what broke and how would be useful.

Ah, that’s it. The command that was suggested added the line on the end:
GRUB_DISABLE_OS_PROBER=false

However, the config was updated and somewhere in the middle I also have:

# Uncomment this option to enable os-prober execution in the grub-mkconfig command
#GRUB_DISABLE_OS_PROBER=false

So it looks like the check noticed this and stopped looking further as it was what it expected.
I deleted the extraneous line, so it won’t be misleading any checks next time.

1 Like

This would surprise me. Lines with # are expected to be ignored, does not matter what follows. Exact syntax matters and of course sudo update-grub is needed after changing the grub file.

What he means is the script that is modifying the grub config, not the config file itself…

Thanks for the link, interesting, but this is a bit confusing behavior, lines with # should be ignored IMHO, that’s the meaning of #, isn’t it?

As far I understand, the script checks whether the os-prober is enabled or not, so it looks for the hashed or not hashed line. Depending on the result it shows info that os-prober is enabled or disabled.

In my case the script found the hashed line first, so it gave me info that os-prober is disabled. It didn’t check the rest of the config where there was additional and not hashed line.

That’s the point, a hashed line should be ignored IMHO and not provide any info. I would not expect that a hashed line makes any difference! Luckily, I took care on the pacnew, immediately.

When the config file is interpreted, yes the # lines are comments, so they are ignored.

The thing is that the script that is modifying this config file should figure out wheter os-prober is disabled or not. The thing is that it could have been disabled explicitly by the user by setting it to true or by just commenting out the whole line.

The problem is that after finding first the hashed line it’s no longer looking for a non-hashed setting afterwards…

2 posts were split to a new topic: Firefox meh after update to v88

16 posts were merged into an existing topic: Firefox meh after update to v88