Kernel update also runs grub to deploy new boot code ...but

Feedback
1

It doesn’t run it with the OS-Prober and THAT is a huge problem for me as I run 10 different distros and coming up on a boot menu with only Manjaro on it just doesn’t do it for me …no offense intended :slight_smile:

Fortunately almost all the distros have at least a plain-jane (unversioned) vmlinuz and initrd link in /boot so manual booting is always as simple as

set root=(hd0,X)
linux /boot/vmlinuz
initrd /boot/initrd
boot

but here again Manjaro falls short as right now it shows only vmlinuz-6.12-x86_64 and initramfs-6.12-x86_64.img respectively but unrespecfully for multi-OS perverts

Suse for example create an unversioned link to the latest pair on kernel update AND run grub WITH os-prober (by default I think).

Gurus generally advise to ‘deploy boot code’ (as oppopsed to running grub which is a nondescriptor) using only one and preferably regularly the same distro. For me that’s Suse Tumbleweed on this day. I would have no problem with all distros having grub deploy boot code on every kernel change IF they all did it the same way using unversioned links and os-prober. My 2 cents.

2

Check what’s in this file and whether the option is set or not:

grep GRUB_DISABLE_OS_PROBER /etc/default/grub

Have a look at the contents - at the line right above this one, where it explains what to do to enable/disable it:

less /etc/default/grub

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

and watch your language, please - re: multi-OS-peeves

3

@six-wheeler

Hello from a fellow multibooter.

Manjaro has been controlling grub on my desktop PC since 2015. The thing though is I don’t enable os_prober because I find that when you have many distros on the same machine, updating grub takes forever (10 to 15 mins just to generate grub menu!).

Instead, I have custom grub entries for all my distros that I save in /boot/grub/custom.cfg of my main Manjaro install [I have 2 on this machine].

When you use custom.cfg file to store custom entries, you don’t need to update grub whenever you edit said file. The entries just appear after your normal Manjaro grub menu. Or you can do as I do and rename /etc/grub.d/41_custom as /etc/grub.d/09_custom. That way, my custom entries appear before the normal Manjaro grub entries on the boot screen [which are controlled by the 10_linux script].

All my distros’ root partitions have a label, and my custom entries for each distro are configfile entries that target the /boot/grub/grub.cfg found in each labelled partition.

That way, when I click on a particular custom menu entry, it basically opens up the grub.cfg file of the distro in question in Manjaro’s boot menu screen.

I have found that the best way to go over the years.

Example of such an entry:

# ----------------------------------
# Arch-Cosmic-Test configfile at sdbxx
# ----------------------------------
menuentry "Arch-Cosmic Configfile sdbxx" --class gnu-linux --class gnu --class os {
	insmod part_gpt
	insmod part_msdos
	insmod ext2
	insmod chain
	insmod multiboot
	insmod configfile 
	search --set=root --label arch-cosmic
	configfile /boot/grub/grub.cfg
}

I just have a general boot entry template with tons of insmod settings because I do have both msdos and gpt partition-table drives, and so far this kitchen sink template hasn’t failed me yet.

1 Like
4

I’m not here to give my opinion on each person’s method.

I find it strange that it takes so much time. I wonder why.

It’s just a simple question. I’m not denying it.

Depending on the environment, if there are many SATA, SD-CARD (empty), etc. connected, it may take a little time, but I think it only takes a few more seconds at most. Of course, this is limited to my environment.

If you have HDDs set to automatic sleep, it will take time to wake them up.

My main Manjaro . grub.cfg

❱ cat grub.cfg | grep ^menuentry 
menuentry 'Manjaro Linux' --class manjaro --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-cbb345de-02d2-4fd7-a2ce-2659621511f8' {
menuentry 'Mint (21.3) (on /dev/nvme0n1p10)' --class linuxmint --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-77b840f0-838d-4ad3-8964-6ec9e55a9dbd' {
menuentry 'Windows Boot Manager (on /dev/nvme0n1p13)' --class windows --class os $menuentry_id_option 'osprober-efi-0553-F36D' {
menuentry 'Windows Boot Manager (on /dev/nvme0n1p2)' --class windows --class os $menuentry_id_option 'osprober-efi-4D25-5935' {
menuentry 'Manjaro Linux (on /dev/nvme0n1p3)' --class manjaro --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-efc533ab-b471-4d6f-83d4-eca5ddffa238' {
menuentry 'Manjaro Linux (on /dev/nvme0n1p6)' --class manjaro --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-c2d98d31-7d69-4ea4-9acc-6afc26c0b080' {
menuentry 'CachyOS (on /dev/nvme0n1p7)' --class cachyos --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-e8ca7940-b61f-4ab8-a6e3-7de29357c84b' {
menuentry 'EndeavourOS (on /dev/nvme0n1p8)' --class endeavouros --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-0ee65980-9006-446d-b3e5-dca58beb73ee' {
menuentry "systemrescue-11.00 with loopback.cfg" {
menuentry "Dr.Parted-Live24.10 with loopback.cfg" {
menuentry "clonezilla-live-3.2.0-5-amd64.iso with loopback.cfg" {
menuentry "Manjaro KDE ISO STABLE"  {
menuentry "shutdown" {
menuentry "reboot" {
5

I can’t explain it. It is slow whichever distro I try to update grub in, thus I have disabled os_prober in all my distros. And it’s been like this for many years once my distros accumulated.

Based on a disk health check done last week, my drives are fine. They are mostly HDD.

Thanks for taking the time to comment. In any case, I’m happy to have custom entries so I don’t have to return to the main distro to update grub whenever another of the distros has a kernel upgrade.

PS. like you, I also have custom entries for direct boot of some isos, among them, Manjaro xfce, clonezilla, MX23 and MX23 Workbench.

1 Like
6

Simple question.
I’m not sure what you’re talking about with my poor language skills.

Do you mean that other distributions are not displayed as candidates in the grub menu? In other words, only manjaro.

7

such perverts know how to manage their system and don’t cast blame when they cannot have it their way.

Manjaro has versioning for a reason - supported multiple installed kernels requires just that

os-prober tries to scan every partition on the system for possible operating systems - and that is time consuming - the more partitions - the longer time …

That will take time - the better option is the one presented by @wongs - I want to add, it is quite brilliant and error resistant.

The original poster registred on March 4. - just throwing a rant - on March 4. and leave it, did not bother to respond.

This requires a @moderators action - in the meantime - unlisted the topic

8

@wongs

Normally, it takes less than 20 seconds. It’s the same for other distributions I have installed. Just for reference. I don’t mean to criticize anyone.
case of osprober enabled.

When all SATA is dormant.
time sudo grub-mkconfig -o /boot/grub/grub.cfg
real    1m18.035s
When SATA is not dormant.
time sudo grub-mkconfig -o /boot/grub/grub.cfg
real    0m12.516s
10

@linux-aarhus
Thanks.

Specifically, in what cases does it take so long? I’m very interested. I thought, maybe. I never install OS on HDD, so maybe that’s why. In my case, all OS is deployed to NVMe. I think it’s standard these days.

Today, my HDDs have two ZFS volumes.
One bcachefs (Muliti devices,like raid).
One btrfs volume. Everything is working fine.

11

I guess I must be one of those perverts; though I use refind (installed to the EFI fallback location) to manage the actual multi-booting; I’ve never had issue with that arrangement; each OS is left to handle it’s own bootloader after the chainload.

Agreed.

In the absence of a Rant category, I’ve moved this to Feedback. Topic is now closed.