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
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.
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.
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.
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" {
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.
such persons 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
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
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.
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.
Quite, and it’s in there alright, uncommented. But asking someone who installs Manjaro for the first time to first go tweaking files seems a little off to me.
What do you mean by watch your language? It was humor in case you hadn’t noticed AND it was aimed at myself, my highness as a multi-OS pervert.
When Os-Prober runs on multi-OS systems IT can become a nightmare (another topic). But in spite of this when I install a distro for the first time I like to have it run Os-Prober so that at least once THAT new OS will have done all the grub ritual. Normally I just have the same OS do the grub bit all the time, in my case at the moment that’s Tumbleweed. What WOULD be in order would be an alert for multi-OS users that Os-Prober will/will-not be run by default.
Editing /etc/default/grub is a very standard way to configure GRUB. It is explicitly designed for user modification, and the GRUB_DISABLE_OS_PROBER=false option is a documented setting.
I know many people have a knee-jerk reaction - editing system files can feel intimidating… But… any changes in this file are pretty low-risk - you’re only uncommenting existing options with the file being backed up by grub-mkconfig or update-grub.
Having used Linux since Ubuntu Hardy Heron many moons ago, I would definitely go into this file and check it’s contents whatever distribution I had installed - though for more casual users or noobs it generally only needs checking out if there’s some kind of issue.
Manjaro (like Arch and other derivatives) does not enable os-prober by default as of recent updates, and this is intentional due to security concerns.
This tool mounts all partitions to detect other OSes, which could exploit filesystem vulnerabiltities or insecure configurations - especially under Secure Boot scenarios.
Manjaro Linux, as distribution, is different from other distributions, as the distribution has chosen to enable os-proper, out of courtesy to the many users which choose to install Manjaro as their first Linux system, and they often do so side-by-side with Windows.
It makes absolutely no sense to run a scan of the system - just in case the user has a boatload of other operating systems installed.
Your use case is special as you have not one, not two but
Such use will make the os-prober take a long time to complete.
Your perceived annoyance is not a flaw of Manjaro - but a result of your choice to have a lot of different operating systems available on the same system.
Such a choice is an advanced use and the system administrator is assumed to have the necessary knowledge to deal with the situation.
You might be better served using rEFInd as the primary UEFI bootloader, effectively chainloading any other installed bootloader in the mix.
This would allow each OS to maintain control of it’s own respective Grub instance, and can negate the need for os-prober entirely.
rEFInd can be configured to boot the last booted entry instead of relying on Grub for that functionality, which also works around compatibility issues with Grub on a BTRFS filesystem which prevent Grub from booting the last booted (Grub) entry.
Indeed. If Manjaro wants to be user friendly (for user unfriendly arch distro there is…arch) disabling os-prober is a regression and if it absolutely has to be, it should be easy to change on install.
It’s not on every boot, it is only run on regenerating grub menu, which occurs on kernel update, which is, for the most users, once a month. And it runs for maybe 0.25 sec, on my sytem with 1 ssd with 7partitions and one windows.
Maybe you are mistaking it with refind, which scans everything every boot by default.
