I use multiboot with several distributions in the EOS Grub menu with a legacy BIOS on a desktop machine, Grub is installed in the MBR. I updated the kernel in one of the “foreign” Linux distributions. My question is, after running sudo os-prober, is it sufficient to rebuild the Grunb configuration file with the grub-mkconfig -o /boot/grub/grub.cfg command, or is there something else to do?
No need to run
priro to running
This should be sufficient as it will call os-prober supposing you have
GRUB_DISABLE_OS_PROBER=false
in /etc/default/grub.
Of course, disable os-prober is set to false. In the past, long before the well-known August update of grub, I used grub-customizer when it was not so buggy. When I started it, it still ran the os-prober script fine, but then got a message saying it couldn’t save the changes because the EOS entry in the grub menu created by the EOS installation doesn’t have an advanced menu. Shouldn’t this possibly affect the correct execution of grub-mkconfig?
My other question is that according to the Grub section of the Arch Wiki, in order for grub-mkconfig to find the other installed operating systems, the partitions that boot them must first be mounted. Is this correct?
Because according to my memories, when there is also a kernel update with EOS during a package update, during the operations after downloading and installing the packages, I see that the os-prober runs from time to time, and I am not sure that the other system partitions were automatically mounted before it.
FWIW I use grub chain loading to boot multiple distros - I think this is more robust as when the “alien” distro is updated (for example kernels are changed) the it is booted with appropriate settings…
At the moment the only “foreign distro” I have is a legacy Antergos installation (migrated to endeavouros) and booted by adding an entry to /etc/grub.d/40_custom
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries. Simply type the
# menu entries you want to add after this comment. Be careful not to change
# the 'exec tail' line above.
# root is the efi partition of the distro you wish to chainload, which is basically a passthrough the that systems grub prompt. hdX is zero based, gptY is 1 based.
#chainloader is the path to the grub efi stub within the efi boot partition.
menuentry "Antergos" class="Antergos" {
search --no-floppy --fs-uuid --set=root xxxxxxxx-xxxxx-xxxx-xxxx-xxxxxxxxxxxx
configfile /boot/grub/grub.cfg
}
It does mean grub is “fired up” twice - I am fine with that.
1 Like
Does this mean that you can chain one Grub to start another?
Looks like that part of wiki needs revision 
When os-prober is run, it calls grub-mount which mounts and unmounts the partitions of the other installed systems:
No need to mount the partitions by yourself. You could verify this by having two terminal windows aide by side. In one you could have htop running and in the other sudo os-prober
It might. What is the output of:
ls /etc/grub.d
?
If you are still having files modified by grub-customizer in there, I would strongly suggest to restore back them to default.
You could do that by:
sudo mv /etc/grub.d /etc/grub.d.old
sudo pacman -S grub
Afterwards, you could regenerate your grub.cfg.
1 Like
In the past, I installed different operating systems, including Linux distributions, on different disks independently. At that time something similar happened, that I could start Grub created by the Linux distribution installed on the second disk from the Grub installed in the MBR on the first disk.
It’s actually quite easy, once you memorize this.
On an MBR (Legacy Bios) system:
Only ONE distro must be allowed to call the os-prober script. That one distro then is in charge of the GRUB. All others aren’t.
That means rebooting after every grub-update for any distro.
Installing grub to /dev/sda and the like is only allowed for the distro “in charge of grub”, consequently.
And updating the correct grub boot-menue for all distros installed will only be reached after updating grub from the distro “in charge” of grub, after any grub-update of any other distro.
Just remember this, and everything else will work smoothely and follow suit…
Even the best Linux Wiki in the world cannot be perfect. 
I’m not at the machine right now, but I don’t remember seeing anything out of the ordinary here, but I’ll check it out.
1 Like
This is perfectly the case with me, as you wrote, EOS takes care of all boot-related tasks. OpenSUSE, for example, during its installation intelligently asked where to install Grub, in the MBR or in the root of its own partition, of course I chose the latter. In my experience, not all distributions offer a choice in this regard.
1 Like
That can make things go “haywire”. 
Here is the output.
00_header 20_linux_xen 31_os-prober.bak 41_custom README
01_grub-customizer_menu_color_helper 30_os-prober 33_uefi-firmware backup
10_linux 30_os-prober.bak 35_fwupd LS_linux.bak
10_linux.bak 30_uefi-firmware 40_custom proxifiedScripts
Although I rebuilt the grub configuration, which also ran os-prober, but then after running the command there was an error message, which was also discussed here on the forum, in another topic dealing with grub-customizer. So I took your advice and renamed grub.d instead and reinstalled grub. That was the forum thread. Latest Update to Grub has an error with grub-mkconfig (when using grub-customizer)
By the way, the readme file in the backup directory also describes what to do if the system does not start. This is about almost the same as what you suggested. The developer is also aware that there are bugs with his program. By the way, even after the rebuild, there was no advanced menu for the entry of EOS, although os-prober also warned about this. After running the Grub Customizer, I got the same warning, maybe if I hadn’t taken it into account, the grub configuration could have been saved there too.
Finally, let me make an addition here as well, thanking you for your help. Reinstalling grub calls os-prober and then grub-mkconfig after it runs, so there is no need to rebuild the grub configuration after that. This is why EOS is suitable for both average and beginner users, because once someone gets used to the command line, many things can be done comfortably.
1 Like
Glad to hear that you have Grub up and running!
Perhaps if you have
GRUB_DISABLE_SUBMENU=y
in /etc/default/grub, it needs to be commented out. And then of course the mandatory regeneration of the grub.cfg.
If there is no such line in the said file just add:
# GRUB_DISABLE_SUBMENU=y
1 Like
Do you think that after uncommenting the disable submenu in the grub file and then rebuilding the grub.cfg, this action will automatically create an advanced submenu for the EndeavorOS section of the grub menu? If this is true, then the grub customizer would become usable again, since this is exactly what it required during its run after running os-prober.
Either that or
# GRUB_DISABLE_SUBMENU=true
and regenerating grub.cfg should give you the submenu “Advanced Options for …”
For reference, please see:
I see in the grub manual that the kernel with the highest version number is placed in the top-level menu entry, the other found kernels in the sub-menu. Why wasn’t this grub menu structure created during installation? I think it’s because the original installation was already two years ago. By the way, interestingly, with the grub customizer, I previously configured the system not to start with the lts kernel in the very first entry of grub, and now that I deleted grub.d and reinstalled grub, this setting was not deleted, but remained.
Update:In the meantime, I commented out the disable grub submenu and rebuilt the new grub configuration. Up until now, the flat grub menu with many lines has bothered me, now it has been shortened nicely. So now the default startup kernel entry is lts, the stable kernel entry can be found in the advanced menu. The grub customizer will probably work after this, although I will avoid using it in the future. Although, for example, it would be easier to customize which is the default startup kernel entry with the grub customizer. .
1 Like
Not really. It’s quite straight forward doing so with your current setup.
- In the Grub boot menu, choose “Advanced …”.
- From the top, count from 0 to get the number for your desired default boot entry.
- Once booted into your system, edit /etc/default/grub.
- Set GRUB_DEFAULT=“N” replacing N with the number you got before. Save and close the file.
- Regenerate your grub.cfg
1 Like
It’s really simple.
Small addition.
This is most likely true, because in my experience, every time you start grub customizer, it calls os-prober and then saves the new configuration, and it takes quite a long time, longer than editing the grub file and rebuilding grub.cfg . …
1 Like
I just had time to look. The /etc/default/grub file contains: GRUB_DEFAULT=“EndeavourOS, on linux”, this is the third entry in Grub’s advanced menu for EndeavorOS. However, grub.cfg has these lines in order for EndeavorOS.
menuentry 'EndeavourOS' --class endeavouros --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-4404304a-b754-42c2-a1fb-3232a078e8e8' {
load_video
set gfxpayload=keep
insmod gzio
insmod part_msdos
insmod ext2
set root='hd0,msdos7'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos7 --hint-efi=hd0,msdos7 --hint-baremetal=ahci0,msdos7 4404304a-b754-42c2-a1fb-3232a078e8e8
else
search --no-floppy --fs-uuid --set=root 4404304a-b754-42c2-a1fb-3232a078e8e8
fi
echo 'Loading kernel linux-lts ...'
linux /boot/vmlinuz-linux-lts root=UUID=4404304a-b754-42c2-a1fb-3232a078e8e8 rw quiet loglevel=3 nowatchdog
echo 'Kiinduló ramdisk betöltése…'
initrd /boot/intel-ucode.img /boot/initramfs-linux-lts.img
}
submenu 'Speciális beállítások ehhez: EndeavourOS' $menuentry_id_option 'gnulinux-advanced-4404304a-b754-42c2-a1fb-3232a078e8e8' {
menuentry 'EndeavourOS, on linux-lts' --class endeavouros --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-linux-lts-advanced-4404304a-b754-42c2-a1fb-3232a078e8e8' {
load_video
set gfxpayload=keep
insmod gzio
insmod part_msdos
insmod ext2
set root='hd0,msdos7'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos7 --hint-efi=hd0,msdos7 --hint-baremetal=ahci0,msdos7 4404304a-b754-42c2-a1fb-3232a078e8e8
else
search --no-floppy --fs-uuid --set=root 4404304a-b754-42c2-a1fb-3232a078e8e8
fi
echo 'Loading kernel linux-lts ...'
linux /boot/vmlinuz-linux-lts root=UUID=4404304a-b754-42c2-a1fb-3232a078e8e8 rw quiet loglevel=3 nowatchdog
echo 'Kiinduló ramdisk betöltése…'
initrd /boot/intel-ucode.img /boot/initramfs-linux-lts.img
}
menuentry 'EndeavourOS, on linux-lts (fallback initramfs)' --class endeavouros --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-linux-lts-fallback-4404304a-b754-42c2-a1fb-3232a078e8e8' {
load_video
set gfxpayload=keep
insmod gzio
insmod part_msdos
insmod ext2
set root='hd0,msdos7'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos7 --hint-efi=hd0,msdos7 --hint-baremetal=ahci0,msdos7 4404304a-b754-42c2-a1fb-3232a078e8e8
else
search --no-floppy --fs-uuid --set=root 4404304a-b754-42c2-a1fb-3232a078e8e8
fi
echo 'Loading kernel linux-lts ...'
linux /boot/vmlinuz-linux-lts root=UUID=4404304a-b754-42c2-a1fb-3232a078e8e8 rw quiet loglevel=3 nowatchdog
echo 'Kiinduló ramdisk betöltése…'
initrd /boot/intel-ucode.img /boot/initramfs-linux-lts-fallback.img
}
menuentry 'EndeavourOS, on linux' --class endeavouros --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-linux-advanced-4404304a-b754-42c2-a1fb-3232a078e8e8' {
load_video
set gfxpayload=keep
insmod gzio
insmod part_msdos
insmod ext2
set root='hd0,msdos7'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos7 --hint-efi=hd0,msdos7 --hint-baremetal=ahci0,msdos7 4404304a-b754-42c2-a1fb-3232a078e8e8
else
search --no-floppy --fs-uuid --set=root 4404304a-b754-42c2-a1fb-3232a078e8e8
fi
echo 'Loading kernel linux ...'
linux /boot/vmlinuz-linux root=UUID=4404304a-b754-42c2-a1fb-3232a078e8e8 rw quiet loglevel=3 nowatchdog
echo 'Kiinduló ramdisk betöltése…'
initrd /boot/intel-ucode.img /boot/initramfs-linux.img
}
menuentry 'EndeavourOS, on linux (fallback initramfs)' --class endeavouros --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-linux-fallback-4404304a-b754-42c2-a1fb-3232a078e8e8' {
load_video
set gfxpayload=keep
insmod gzio
insmod part_msdos
insmod ext2
set root='hd0,msdos7'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos7 --hint-efi=hd0,msdos7 --hint-baremetal=ahci0,msdos7 4404304a-b754-42c2-a1fb-3232a078e8e8
else
search --no-floppy --fs-uuid --set=root 4404304a-b754-42c2-a1fb-3232a078e8e8
fi
echo 'Loading kernel linux ...'
linux /boot/vmlinuz-linux root=UUID=4404304a-b754-42c2-a1fb-3232a078e8e8 rw quiet loglevel=3 nowatchdog
echo 'Kiinduló ramdisk betöltése…'
initrd /boot/intel-ucode.img /boot/initramfs-linux-fallback.img
}
}
if [ "x$default" = 'EndeavourOS, on linux' ]; then default='Advanced options for EndeavourOS>EndeavourOS, on linux'; fi;
From this I deduce that by default the system should boot with the third entry in the Grub EndeavorOS advanced menu, which boots the stable kernel. Instead, by default, the system boots with the EndeavorOS entry, which is the first kernel entry in grub.cfg, and starts the lts kernel. This is probably because I installed the LTS kernel later after the original installation and it ended up at the top of the Grub menu.
In the meantime, I continued to research. https://wiki.archlinux.org/title/GRUB/Tips_and_tricks#Changing_the_default_menu_entry
Based on this, I think this is the correct solution: GRUB_DEFAULT=“1>2”
I look forward to your opinion as well.