dual boot menu vs. new kernels [Solved]

[imschmeg]

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).

[CharlesV]

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

[MXRobo]

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!

[imschmeg]

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?

[dolphin_oracle]

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

[siamhie]

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.

[imschmeg]

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?

[dolphin_oracle]

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.

[imschmeg]

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?

[operadude]

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