MX Linux Forum

Posted: **Thu Jan 16, 2025 10:02 am**

I have a dual boot setup with MX 23.5 AHS and Debian Testing, with the boot menu setup by MX. This is working almost perfectly, except:

When a new kernel is installed in Debian Testing, I have to boot MX and use the MX Boot Options tool to get the boot menu to see that new kernel.

Is there a way to get the Debian Testing install to update the boot menu so that it sees its new kernel? I know I could update grub from Debian Testing, but then I think I get the same problem in reverse - where new MX kernels would not automatically get into the boot menu.

In other words, I'd really like to keep the MX boot menu setup (it's nicer and more easily configurable than standard Debian), but somehow have a new kernel installed into Debian Testing trigger just enough of an update to it to register the new kernel (as well as remove any no longer installed kernels).

Posted: **Fri Jan 17, 2025 11:10 am**

Please post your QSI. ( MX Menu, Quick System Info, Copy for Forum, Paste here )

Posted: **Fri Jan 17, 2025 1:37 pm**

Unless I'm missing something, isn't this simply the fact that you must run sudo update-grub on the distro that "manages the grub" after a new kernel is installed on the non-managing distro?
I don't think that there's a common workaround.

Maybe you could add to Session and Startup > Application Startup, not sure about running sudo in this though.
Or write a script that runs every startup, login, cronjob, or by a keystroke or alias - haven't done any.

Cheers!

Posted: **Fri Jan 17, 2025 3:58 pm**

I guess the question is really about what the OS Probe in Grub does, and when it does it. It has to be doing something at boot time in order to discover new OS installs that were not there on previous boots. But it seems to retain its knowledge of past discoveries to the point of limiting the available kernels in those installs to what it found that first time. It seems like it would be better in my case if it didn't retain this information, and instead determined what kernels are available for each install at the time of the boot. Is it trying to save time?

Does anyone know if there is a way to configure the OS Prober, other than the basic on-or-off flag?

Posted: **Fri Jan 17, 2025 4:04 pm**

imschmeg wrote: Fri Jan 17, 2025 3:58 pm I guess the question is really about what the OS Probe in Grub does, and when it does it. It has to be doing something at boot time in order to discover new OS installs that were not there on previous boots. But it seems to retain its knowledge of past discoveries to the point of limiting the available kernels in those installs to what it found that first time. It seems like it would be better in my case if it didn't retain this information, and instead determined what kernels are available for each install at the time of the boot. Is it trying to save time?

Does anyone know if there is a way to configure the OS Prober, other than the basic on-or-off flag?

grub menus are not built at boot time. it either happens when update-grub is issued manually, or when triggered by a kernel install. even when our installer installs grub, it issues and "update-grub" to update the menu.

you could probably make an apt hook to trigger a custom chroot action (update-grub) on the inactive OS, but the script would be custom to your machine, and I honestly don't know how to do that. the trigger would be on kernel install changes. I don't know how to do that, but apt hooks do exist for other packages.

let's say grub is on sda1

then

Code: Select all

mkdir -p  /mnt/mountpoint
mount /dev/sda1 /mnt/mountpoint
mount --bind /dev /mnt/mountpoint/dev
mount --bind /sys /mnt/mountpoint/sys
mount --bind /proc /mnt/mountpoint/proc
chroot /mnt/mountpoint update-grub
umount /mnt/mountpoint/dev
umount /mnt/mountpoint/sys
umount /mnt/mountpoint/proc
umount /mnt/mountpoint

Posted: **Fri Jan 17, 2025 4:27 pm**

I have a dual boot setup with MX fluxbox and MX XFCE.

fluxbox is the boot controller, so if XFCE gets a kernel upgrade,
I simply boot to fluxbox and update grub (sudo update-grub in terminal) so that XFCE's new kernel shows in the grub menu.

I do the same thing when removing old kernels from XFCE.

Posted: **Fri Jan 17, 2025 7:52 pm**

dolphin_oracle wrote: Fri Jan 17, 2025 4:04 pm grub menus are not built at boot time. it either happens when update-grub is issued manually, or when triggered by a kernel install. even when our installer installs grub, it issues and "update-grub" to update the menu.

I could have sworn that I've seen the grub menu pick up OSs that are on bootable USB drives that were attached to the machine after having their OSs installed. But maybe I'm hallucinating.

you could probably make an apt hook to trigger a custom chroot action (update-grub) on the inactive OS, but the script would be custom to your machine, and I honestly don't know how to do that. the trigger would be on kernel install changes. I don't know how to do that, but apt hooks do exist for other packages.

When I have the MX boot menu, why doesn't installing a new kernel in the non-MX OS (Debian testing) cause grub to use that OS's boot menu instead? It's doing an update-grub as a result of the new kernel, right? Is there some kind of test the OS does that says if the boot menu isn't identified as from this particular OS install, then it doesn't update the boot menu?

Posted: **Fri Jan 17, 2025 8:38 pm**

imschmeg wrote: Fri Jan 17, 2025 7:52 pm
dolphin_oracle wrote: Fri Jan 17, 2025 4:04 pm grub menus are not built at boot time. it either happens when update-grub is issued manually, or when triggered by a kernel install. even when our installer installs grub, it issues and "update-grub" to update the menu.
I could have sworn that I've seen the grub menu pick up OSs that are on bootable USB drives that were attached to the machine after having their OSs installed. But maybe I'm hallucinating.

you could probably make an apt hook to trigger a custom chroot action (update-grub) on the inactive OS, but the script would be custom to your machine, and I honestly don't know how to do that. the trigger would be on kernel install changes. I don't know how to do that, but apt hooks do exist for other packages.
When I have the MX boot menu, why doesn't installing a new kernel in the non-MX OS (Debian testing) cause grub to use that OS's boot menu instead? It's doing an update-grub as a result of the new kernel, right? Is there some kind of test the OS does that says if the boot menu isn't identified as from this particular OS install, then it doesn't update the boot menu?

because there are two parts. the boot loader and the menu. the boot loader automatically points to the particular boot partition. so the boot loader is specific to a particular grub menu. update-grub doesn't change where the boot loader points, just updates the menu with whatever is available when the update-grub is run.

Posted: **Sat Jan 18, 2025 11:18 am**

Would something like rEFInd work in my case?:

It sounds like it does the necessary scanning at boot time. And rEFInd exists in the Debian repo. Would it be compatible with MX?

Posted: **Sat Jan 18, 2025 11:40 am**

imschmeg wrote: Sat Jan 18, 2025 11:18 am Would something like rEFInd work in my case?:

It sounds like it does the necessary scanning at boot time. And rEFInd exists in the Debian repo. Would it be compatible with MX?

rEFInd is totally compatible with MX.

I have been using it for over three years. See my (long-ish) post from this point:

viewtopic.php?p=668133#p668133

I installed rEFInd via MXPI (MX Package Installer (found in MX-Tools), in the "Enabled Repos" tab). I just checked. It's still there.

I love it, and have never had a problem with it, since installing it over 3 years ago!

The link above goes on, but includes icon files that you can use with rEFInd. Very slick!

HTH

Posted: **Sat Jan 18, 2025 2:00 pm**

operadude wrote: Sat Jan 18, 2025 11:40 am rEFInd is totally compatible with MX.

Does rEFInd show multiple ways of booting each OS install, such as MX's usual two kernels X sysVinit/systemD? Does it remember a default or last option?

Do MX Boot Options and MX Boot Repair know about rEFInd, and if so, how do they interact?

Would it help if I installed rEFInd in both OS installs that I'm dual booting?

Posted: **Sun Jan 19, 2025 2:34 am**

imschmeg wrote: Sat Jan 18, 2025 2:00 pm
operadude wrote: Sat Jan 18, 2025 11:40 am rEFInd is totally compatible with MX.
Does rEFInd show multiple ways of booting each OS install, such as MX's usual two kernels X sysVinit/systemD? Does it remember a default or last option?

Do MX Boot Options and MX Boot Repair know about rEFInd, and if so, how do they interact?

Would it help if I installed rEFInd in both OS installs that I'm dual booting?

A bit above my pay-grade, but I can tell you that you can drop in the rEFInd menu multiple OSs to boot from. I have 3 OSs, with icons, showing on my rEFInd main GUI menu (MX Fluxbox, KDE, & Xfce). Also, if I happen to plug-in a bootable USB, it will show-up, with an icon and name, on the rEFInd GUI menu (nice!).

After selecting an OS to boot-into, you are taken to the standard MX GRUB menu, and from there, you have all your boot options, including booting into another OS, e.g. Windows (which I do, on a separate drive).

AFAIK, rEFInd is not installed per OS. It is installed on the EFI partition (I think-- again, I'm not sure about the exact details: others, e.g. @fehlix can address the technical aspects), which is independent of the partitions where the OSs reside. So, think of it as a UEFI/BIOS staging option, if that makes sense. All the rEFInd stuff happens BEFORE any OS loads, so you need to install it only once.

And, you can install it, try it out, and if you need help, just ask the Forum

There are many, many folks here with skills way more advanced than mine, who can help you out of a tight spot (as they have done for me)

I would give it a try...and if it's not your cup of tea, just uninstall it.

Posted: **Sun Jan 19, 2025 1:48 pm**

I'm reading the rEFInd doc, which is very extensive. I think I understand what it does now, and how to configure things. It seems like rEFInd installs itself as an boot manager, which becomes known to your machine's hardware (non-volatile RAM based) BIOS/EFI system. You can go into your machine's BIOS boot-order settings and have the machine boot rEFInd first before any other installed OS - although, as with any new entry that is installed, it should show up as the first (and thus default) entry at that time anyway. When you boot to rEFInd, instead of that loading up an OS's GRUB menu, it runs rEFInd and that searches at that time among all currently connected drives for partitions that contain OSs. Which one you choose at that point will then run its GRUB menu (if it has one, like linuxes do, else just boot like Windows would).

So the way to configure things on a multi-boot system is to install rEFInd, set it as the first (default) boot option in the BIOS boot order, and then turn off OS prober in you grub settings in each OS install on that machine. Each OS will manage its own GRUB menu, ignoring the other installed OSs then - but you use rEFInd first to decide which OS's GRUB menu to launch. Installing a new kernel in any OS will update its GRUB menu. That kernel will then (based on how the owning OS works, but usually it does this) become the new default for that OS's GRUB menu. Hence no more obsolete/missing kernel selections in GRUB menus (as is my current problem with using MX's GRUB menu with OS prober). Yeah!

This also means that having rEFInd installed doesn't mean any of the other boot options are missing - they're just not the first in your machine's boot order. You can still get to them from your machine's BIOS, such as through a one-time boot menu if your hardware has that (usually available by holding down some function key at boot time).

And it means that rEFInd and MX Boot Options won't interfere. MX Boot Options configures the MX-specific GRUB menu, which is reachable from rEFInd.

Hmmm.... Also, this means that if I could have my machine always just show its "one-time boot menu" when booting with some timeout before continuing with the default (first) entry, then I wouldn't need rEFInd. Because that is all that rEFInd does (minus the GUI differences).

I'm not sure of the above - because I haven't tried it yet (working up the confidence), and having finished reading all of the doc. Maybe rEFInd tries to bypass the OS-specific GRUB menus, and offer direct choices to the OS kernel selections? In which case, it wouldn't work with MX as well as MX's own GRUB menu - because it wouldn't offer sysVinit vs. systemD options. I don't think.

I'm also not sure about MX Boot Repair - that could interfere with rEFInd, depending on what Boot Repair does.

@operadude - when you boot with rEFInd, and then select MX, do you then get the MX boot menu, or does rEFInd bypass that and give you multiple MX selections based on the kernels you have installed in MX? If it bypasses the MX Grub menu, how does it show the different MX boot options, such as different kernels and sysVinit vs. systemD?

Posted: **Mon Jan 20, 2025 2:40 am**

@operadude - when you boot with rEFInd, and then select MX, do you then get the MX boot menu, or does rEFInd bypass that and give you multiple MX selections based on the kernels you have installed in MX? If it bypasses the MX Grub menu, how does it show the different MX boot options, such as different kernels and sysVinit vs. systemD?

See what I wrote before:

After selecting an OS to boot-into, you are taken to the standard MX GRUB menu, and from there, you have all your boot options, including booting into another OS, e.g. Windows (which I do, on a separate drive).

Once presented with the MX GRUB menu for the OS you selected with rEFInd, you have an "Advanced Options" tab/entry that you can select for your MX distro. I believe from the "Advanced Options" tab, you can select which kernel to boot from.

Why not give it a try?

Good Luck

Posted: **Mon Jan 20, 2025 3:30 pm**

It works! Mostly. One issue I have is how do I reset the MX grub boot menu to NOT show what it picked up when using OS prober. In other words, only show MX boot choices. Merely setting /etc/default/grub to have GRUB_DISABLE_OS_PROBER=true and doing an update-grub didn't change the menu back. I even tried using MX Boot Options afterwards to make minor changes just to make sure something was getting updated - and those options did take effect.

How does one remove old OS Prober-introduced choices from MX's grub boot menu?

Posted: **Mon Jan 20, 2025 3:47 pm**

imschmeg wrote: Mon Jan 20, 2025 3:30 pm It works! Mostly. One issue I have is how do I reset the MX grub boot menu to NOT show what it picked up when using OS prober. In other words, only show MX boot choices. Merely setting /etc/default/grub to have GRUB_DISABLE_OS_PROBER=true and doing an update-grub didn't change the menu back. I even tried using MX Boot Options afterwards to make minor changes just to make sure something was getting updated - and those options did take effect.

How does one remove old OS Prober-introduced choices from MX's grub boot menu?

Code: Select all

sudo dpkg-reconfigure grub-pc

and deselect the os-prober option.

then run update-grub.

Posted: **Mon Jan 20, 2025 4:22 pm**

imschmeg wrote: Mon Jan 20, 2025 3:30 pm How does one remove old OS Prober-introduced choices from MX's grub boot menu?

The safest may be this b/c update-grub will ignore those parts which do not hold an execution bit:

Code: Select all

sudo chmod -x /etc/grub.d/30_os-prober

At least as long grub-customizer was not used. Alternatively removing os-prober package may also help.

Posted: **Mon Jan 20, 2025 6:01 pm**

The sudo dpkg-reconfigure grub-pc followed by update-grub trick didn't work. But the chmod -x trick (followed by update-grub) did work.

Thanks!

Posted: **Tue Jan 21, 2025 2:23 am**

imschmeg wrote: Mon Jan 20, 2025 6:01 pm The sudo dpkg-reconfigure grub-pc followed by update-grub trick didn't work. But the chmod -x trick (followed by update-grub) did work.

Thanks!

Really glad you got this sorted, via help from none other than both Masters

Not that they need (or want?) the attribution, but as a point of order, it is best to choose as "[SOLVED]" the post that actually solved your issue, which, I believe, you mean to be post #17, authored by none other than the indominatable fehlix, who, incidentally, was the one who recommended to me rEFInd, and helped me with the multi-distro install (viewtopic.php?p=668133#p668133), all those years (3+) ago

To clarify, you selected your own post (#18) as the one that solved your issue.

Anyway, glad that you are satisfied.

Am I right, or am I right, about the awesomeness of this Forum?

Posted: **Tue Jan 21, 2025 11:08 am**

Oops!

Posted: **Tue Jan 21, 2025 2:38 pm**

@imschmeg

Good on You, Bro

MX Linux Forum

dual boot menu vs. new kernels

dual boot menu vs. new kernels

Re: dual boot menu vs. new kernels

Re: dual boot menu vs. new kernels

Re: dual boot menu vs. new kernels

Re: dual boot menu vs. new kernels

Re: dual boot menu vs. new kernels

Re: dual boot menu vs. new kernels

Re: dual boot menu vs. new kernels

Re: dual boot menu vs. new kernels

Re: dual boot menu vs. new kernels

Re: dual boot menu vs. new kernels

Re: dual boot menu vs. new kernels

Re: dual boot menu vs. new kernels

Re: dual boot menu vs. new kernels

Re: dual boot menu vs. new kernels

Re: dual boot menu vs. new kernels

Re: dual boot menu vs. new kernels [Solved]

Re: dual boot menu vs. new kernels [Solved]

Re: dual boot menu vs. new kernels [Solved]

Re: dual boot menu vs. new kernels

Re: dual boot menu vs. new kernels