On 03/07/23 23:20, Carlos E.R. wrote:
> On 2023-07-03 20:21, MarioCPPP wrote:
>> On 03/07/23 06:46, Carlos E.R. wrote:
>>> On 2023-07-03 00:55, MarioCPPP wrote:
>>>> On 02/07/23 14:46, Carlos E.R. wrote:
>>>>> On 2023-07-02 14:21, MarioCPPP wrote:
>>>>>> On 02/07/23 12:14, Carlos E.R. wrote:
>>>>>>> On 2023-07-02 02:55, Bit Twister wrote:
>>>>>>>> On Sat, 1 Jul 2023 23:08:06 +0200, J.O. Aho wrote:
>>>>>>>>> On 7/1/23 16:13, MarioCPPP wrote:
>>>>>>>>>> On 30/06/23 12:24, Carlos E.R. wrote:
>>>>>>>>>
>>>> CUT
>>>>
>>>>>>
>>>>>> I underline I did not do this "on purpose", but let
>>>>>> the installer do what it reputed it right.
>>>>>
>>>>> Irrelevant. You have to tell the installers what to do.
>>>>> :-)
>>>>
>>>> the choices were ... none. The disk was an MBR legacy
>>>> one, with a huge Debian install on.
>>>
>>> And you choose to install something else beside it,
>>> without telling it to NOT use the mbr. WRONG.
>>
>> I keep on not understanding.
>> If MX would have not installed itself, how could he become
>> bootable ?
>> I must be dumb, but I preferred not to use some other disk
>> (even I have others), because in that case, to be able to
>> boot MX, I would have needed to invoke BIOS boot device
>> selection, which was less straight forward
> I'll try again.
>
> Assuming a single hard disk.
>
> You install distro linux_1, using defaults.  It does
> "install grub on mbr".
>
> Now, there is a single MBR per hard disk. The MBR is just
> 512 bytes. It contains a partition table that holds 4
> partitions (fixed table), and a tiny code.
>
> When an IBM PC CLONE boots, or a derived machine using
> traditional BIOS, it finds the first hard disk and reads the
> first sector (512) bytes of the first disk, loads that into
> RAM at a predefined location, and starts the code in that
> location.
>
> It is very simple.
>
> Now the computer will do whatever that tiny code says, and
> nothing else. Ok, when that code comes from a normal grub2
> install, it will load several sectors from that hard disk,
> which are stored in a non assigned space that starts on LBA
> 0 (grub is on LBA 1), and then run that bigger code (it is
> several sectors; the size is stored in the MBR code).
>
> That bigger code will eventually read a _hardcoded_
> partition to find /boot/grub2/grub.cfg and present to you
> that menu, to boot "linux_1".
>
>    That menu may, eventually, include entries to boot instead
>    another operating system, that were put in the menu by
> os-prober.
>
> Notice this: hardcoded. Not at runtime, but at install time
> (or update time).
>
>
>
> Now, you install distro linux_2, using defaults.  It does
> "install grub on mbr".
>
> Now, there is a single MBR per hard disk. The MBR is just
> 512 bytes. It contains a partition table that holds 4
> partitions (fixed table), and a tiny code.
>
> When an IBM PC CLONE boots, or a derived machine using
> traditional BIOS, it finds the first hard disk and reads the
> first sector (512) bytes of the first disk, loads that into
> RAM at a predefined location, and starts the code in that
> location.
>
> It is very simple.
>
> Now the computer will do whatever that tiny code says, and
> nothing else. Ok, when that code comes from a normal grub2
> install, it will load several sectors from that hard disk,
> which are stored in a non assigned space that starts on LBA
> 0 (grub is on LBA 1), and then run that bigger code (it is
> several sectors; the size is stored in the MBR code).
>
> That bigger code will eventually read a _hardcoded_
> partition to find /boot/grub2/grub.cfg and present to you
> that menu, to boot "linux_2".
>
>    That menu may, eventually, include entries to boot instead
>    another operating system, that were put in the menu by
> os-prober.
>
> Notice this: hardcoded. Not at runtime, but at install time
> (or update time).
I noticed, but I fail to understand what would forbid that
this hardcoding should be impossible later, exploiting the
same mechanism.
>
>
>
>
> Now you will say that I repeated the same paragraph. Yes, I
> did, intentionally, to stress the point that linux_2 by
> default overwrites and destroys what linux_1 did during
> install.
>
>
>
> Do you understand this?
>
>
> And every time you manage to boot linux_1 somehow, and
> update it, or do operations to reinstall grub, it will
> destroy the boot system of linux_2.
>
> And every time you manage to boot linux_2 somehow, and
> update it, or do operations to reinstall grub, it will
> destroy the boot system of linux_1.
this point is obscure : why DESTROY and not simply
NOT-UPDATED ? I mean, why the new update should discard what
had just been identified before ?
And more : to have os-prober runned at each update, on both
sides, should not update also the list of bootable images
found ? What is the use of os-prober then ?
I fail to undetstand why is it not possible to use the same
mechanism that WORKS on a new install at every update of
grub or kernel.
If not automatedly, why not manually (and how).
The way seem to exist technically : every new install
detects ALL the status quo at a given time.
I would need to ensure this same route is followed also for
"minor updates" that are not full install.
>
>
> Do you understand this?
in part, but not enough, and I fear I won't without more
details of how it works
>
>
> Now you ask how can I install properly another Linux and
> we'll take it from there.
>
> The thing to understand first is that either linux_1 or
> linux_2 (or both) can not use MBR to boot, it must use a
> different sector.
>
>
--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
MarioCPPP

On 7/4/23 13:23, MarioCPPP wrote:
> On 03/07/23 23:19, J.O. Aho wrote:

>> No, you can't just run the os-probe manually, it's a "module" for
>> grub2 which is run by grub2 if you had configured grub to have
>>
>> GRUB_DISABLE_OS_PROBER=false
>
> I have edited this SOMEWHERE, actually, even if I have forgotten which
> of the two distro was using then.
> Since, for both, I keep auto-mounted the other partition, in order to
> perform exactly this kind of deep maintenance, how to install os-prober
> if not just installed, and how to configure both grubs copies to run
> os-prober ?

Yes, you need to install os-prober and then enable it in
/etc/default/grub (at least the location for all the distros I have
used). Then next time grub.cfg is updated (either manually run or a
kernel update) you will have the other installations detected.

>> Even if you could run it manually, it will not change anything in your
>> /boot/grub/grub.cfg (or /boot/grub2/grub.cfg, path can be different in
>> different distros)
>
> this point remains obscure to me ... what is the actual function of
> os-prober, if not to detect all installed systems aside ? And why does
> this detection not affect the config file ?

For it do not write anything to grub, it's a tool that grub uses to find
other OS installations on your storage media. The magic of making the
grub.cfg is done within grub.

>> It's like you have two cars and one single car garage, you will not be
>> able to have both cars in the garage, you need to pick which one to
>> always keep in the garage.
>

> (actually, both SETS of cars, since each distro could well
> have more than a bootable kernel image stored, I tend to keep at least
> two, most recent, and the immediate preceding one)

No, it's just two cars, the cars are the grub installations, not the
kernels, the kernels would be the the seats in the car, of corse grub do
not have the limit as a normal car has on the amount of seats.

> I thought I understood a different thing from BitTwister metaphore, that is
> BOTH cars ARE OUT,

No, you will always have one car in in the metaphor, as you can't drive
more than one car at the time. The car is the MBR+grub.cfg together, the
garage is your primary boot device.

> I mean, MBR just passes control, but per se, not necessarily to a single
> distro (the one that last updated MBR pointers), provided the os-prober
> utility scanned all partitions ...
> Another thing : is it there sth I can pragmatically do now to mitigate
> the future problems ?

The boatloader on your primary boot device (MBR) is a small program that
tells how to load the OS or in this case the rest rest of Grub, it will
point at a specific partition where it will find stage files and the
grub.cfg which do have information about the kernels.

When you have multiple distros installed, the MBR can't point at all the
distros, it has to point at one distros /boot, to not get odd
functionality you don't want the other distros to mess with MBR, so you
should store the grub in the partition data instead. The only distro
that needs os-prober enabled is the primary one, the other distros can
have it disabled.

--
//Aho

On 7/4/23 13:30, MarioCPPP wrote:
> On 03/07/23 23:20, Carlos E.R. wrote:
>> On 2023-07-03 20:21, MarioCPPP wrote:

>> And every time you manage to boot linux_1 somehow, and update it, or
>> do operations to reinstall grub, it will destroy the boot system of
>> linux_2.
>>
>> And every time you manage to boot linux_2 somehow, and update it, or
>> do operations to reinstall grub, it will destroy the boot system of
>> linux_1.
>
> this point is obscure : why DESTROY and not simply NOT-UPDATED ? I mean,
> why the new update should discard what had just been identified before ?

For it's more work to clean out sections for kernels you don't have than
recreate the whole file from scratch, this also will lead to less code
complexity, make it more stable and execution time will be a lot shorter.

> And more : to have os-prober runned at each update, on both sides,
> should not update also the list of bootable images found ? What is the
> use of os-prober then ?

You will also change the order of the kernels and the primary kernel may
not belong to the distro you want to have as your main boot distro.

> I fail to undetstand why is it not possible to use the same mechanism
> that WORKS on a new install at every update of grub or kernel.

This only works if one distro controls the MBR of your primary boot device.

> If not automatedly, why not manually (and how).

You would manually have to edit grub.cfg with the risks that you render
all distros unbootalbe when grub fails due of syntax error in the file.

> The way seem to exist technically : every new install detects ALL the
> status quo at a given time.

Install microsoft windows and see what happens with grub, the same thing
happens when you install a new distro, the only difference is that it
installs grub on MBR, which makes you to miss the problem you have.

> I would need to ensure this same route is followed also for "minor
> updates" that are not full install.

Yes, by only allowing one distro to store it's grub loader on the MBR
and the rest has their BR grub loader on the partitions.

--
//Aho

Groovy hepcat Carlos E.R. was jivin' in alt.os.linux on Fri, 30 Jun 2023
08:24 pm. It's a cool scene! Dig it.

> On 2023-06-29 18:00, MarioCPPP wrote:
>> On 29/06/23 08:14, J.O. Aho wrote:
>>> On 6/28/23 19:08, MarioCPPP wrote:
>>>> On 28/06/23 14:25, Paul wrote:
>>>
>>>>> 2) Initramfs also has a swap check.
>>>>>
>>>>> open /etc/initramfs-tools/conf.d/resume
>>>>> replace RESUME=UUID=xxx with RESUME=none  (or use the correct
>>>>> blkid!)
>>>>> issue sudo update-initramfs -u
>>>>> reboot your system
>>>>>
>>>>> I did an update-grub just in case.
>>>>
>>>> but in which of the two ?
>>>
>>> If you configured your grub correctly
>>
>> I have never ever configured it at all.
>> Each (of the two) distro I've installed, did it all on its own. The
>> only thing I've chosen is where : the SAME MBR of the same drive (it
>> is a legacy partitioned, non GPT), and the order. Long beforehand,
>> Debian. Recently, MX 23.
>
> Oh, shit {big moan} :-(
>
> You CAN NOT install two linuxes using the same MBR.

What are you talking about? Linux isn't installed in the MBR. If you
mean grub, okay; but that's not Linux.
I've had many Linuxen installed on one machine, even on one drive
having but one MBR, and they all cohabited just fine. But they were
booted via just one grub installation.
The mistake Mario made was installing multiple grubs, one apparently
overwriting the previously existing one. You only need the one boot
loader. You don't have to install grub with a new distro. Keep the
original grub installation, update it within the distro that it came
with, and all should be fine (grub-wise).
However, since MX is a Debian derivative, it's entirely possible that
they use the same version of grub. This may reduce the incidence of
problems: at least until one of the distros has an update. But I would
still refrain from using the original distro for grub operations, in
the circumstances.

--

----- Dig the NEW and IMPROVED news sig!! -----

-------------- Shaggy was here! ---------------
Ain't I'm a dawg!!

Groovy hepcat Fonntuggnio was jivin' in alt.os.linux on Fri, 30 Jun 2023
02:20 am. It's a cool scene! Dig it.

> I have examined both Debian's folders and MX23's folders of
> /etc/grub.d and ...
> NONE contains a file (or subfolder) named default_grub

Try /etc/default/grub. This is the file Debian and its derivatives
(incl. MX) use.

--

----- Dig the NEW and IMPROVED news sig!! -----

-------------- Shaggy was here! ---------------
Ain't I'm a dawg!!

On Tue, 04 Jul 2023 07:12:56 -0400, MarioCPPP <NoliMihiFrangereMentulam@libero.it> wrote:
> On 03/07/23 21:57, David W. Hodgins wrote:
>> If you have two linux installs, and only one of them has
>> os-prober enabled, then

> how could I enable os-prober on both ?
>
>> boot the version without os-prober, and install a kernel,
>> the other linux install
>> will disappear from the grub menu.
>
> disappear COMPLETELY you mean, or the old voices would still
> show up ?

Not show up when booting. The other install will still be there, just not
shown in the boot menu.

> If the first, how to enable os-prober then ?

Make sure os-prober is installed in both linux installs, and that is enabled
in both installs ...

# ll /usr/bin/os-prober
-rwxr-xr-x 1 root root 6727 Jan 20 05:59 /usr/bin/os-prober*
# grep PROBER /etc/default/grub
GRUB_DISABLE_OS_PROBER=false

Note the double negative. Disable=false means enabled.

This way whichever install last had something done that caused the grub menu
to get rebuilt will be the one that gets displayed will be the one that creates
the menu that is shown. It will not matter which one last wrote the mbr as both
should show the same entries in the grub menu.

The other parameters stored in /etc/default/grub should be kept the same,
except for the distributor, and theme, to help avoid confusion later.

Regards, Dave Hodgins

On 04/07/23 14:40, J.O. Aho wrote:
> On 7/4/23 13:30, MarioCPPP wrote:
>> On 03/07/23 23:20, Carlos E.R. wrote:
>>> On 2023-07-03 20:21, MarioCPPP wrote:

>
>> I would need to ensure this same route is followed also
>> for "minor updates" that are not full install.
>
> Yes, by only allowing one distro to store it's grub loader
> on the MBR and the rest has their BR grub loader on the
> partitions.

How this is done "ex post" ?
I mean, how can I tell MX23, that is just installed : move
your grub data from whatever they are to your own partition
? I must add that I don't have any more UNUSED partitions.

In case, MX23 would remain bootable using BIOS boot device
selection at power on ?

>

--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
MarioCPPP

On Tue, 4 Jul 2023 13:23:02 +0200, MarioCPPP wrote:
> On 03/07/23 23:19, J.O. Aho wrote:
>> On 7/3/23 20:21, MarioCPPP wrote:
>>
>>> no ok, I am not asking for blind instructions. I'd better
>>> understand how to correct the problem that should arise
>>> upon kernel upgrade on either of the distros.
>>>
>>> Now I make an assumption : if, say, I upgrade Debian
>>> kernel to 6.2 (now it is 6.1), MX won't see it ... but it
>>> should still be able to detect the former one. Right so far ?
>>> If so, I could boot older kernel in Debian, and do
>>> update-grub, or manually launch Os-prober (I still have to
>>> undestand its options).
>>
>> No, you can't just run the os-probe manually, it's a
>> "module" for grub2 which is run by grub2 if you had
>> configured grub to have
>>
>> GRUB_DISABLE_OS_PROBER=false
>
> I have edited this SOMEWHERE, actually, even if I have
> forgotten which of the two distro was using then.
> Since, for both, I keep auto-mounted the other partition, in
> order to perform exactly this kind of deep maintenance, how
> to install os-prober if not just installed, and how to
> configure both grubs copies to run os-prober ?

Usual grub includes the os-prob code.

>
>
> this point remains obscure to me ... what is the actual
> function of os-prober, if not to detect all installed
> systems aside ? And why does this detection not affect the
> config file ?

os-probe job to to open all partitions, find bootable images
and add them to grub.cfg.

ick which one to always keep in the garage.
>
> I thought I understood a different thing from BitTwister
> metaphore, that is
> BOTH cars (actually, both SETS of cars, since each distro
> could well have more than a bootable kernel image stored, I
> tend to keep at least two, most recent, and the immediate
> preceding one) ARE OUT, since MBR is not a garage for cars,
> but just a pointer.

BitTwister did not provide the metaphore. bittwister gave you what happens
in a nutshell at your level.
You are making it harder to understand what is happening.

> This pointer contains just two lists of things, and
> whichever distro last updated it,

Poor choice of words at this point. A mbr right is only done
during install and when you wish to change it.

> the only thing important
> had been : did such an update SCAN all the partitions to
> detect whatever kernel image is there ?

That is what os-prober does if not disabled by you modifying
a grub configuration file.

> I mean, MBR just passes control, but per se, not necessarily
> to a single distro (the one that last updated MBR pointers),

No se about it. mbr does pass control the boot loader to be in charge.

> provided the os-prober utility scanned all partitions ...
>
> Yes, I still don't understand the situation, considering I
> don't come to the same conclusions as most (much more
> skilled than me) of you.
>
> Another thing : is it there sth I can pragmatically do now
> to mitigate the future problems ?

Your lack of just basic understanding will prevent you from coding the
instructions to automate the process. :(
)

> If so, what ?

Dead easy. Create script to detect if kernel has changed on non-Production
os, run grub update, copy latest grub.cfg to all other installs.

On 04/07/23 20:19, David W. Hodgins wrote:
> On Tue, 04 Jul 2023 07:12:56 -0400, MarioCPPP
> <NoliMihiFrangereMentulam@libero.it> wrote:
>> On 03/07/23 21:57, David W. Hodgins wrote:
>>> If you have two linux installs, and only one of them has
>>> os-prober enabled, then
>
>> how could I enable os-prober on both ?
>>
>>> boot the version without os-prober, and install a kernel,
>>> the other linux install
>>> will disappear from the grub menu.
>>
>> disappear COMPLETELY you mean, or the old voices would still
>> show up ?
>
> Not show up when booting. The other install will still be
> there, just not
> shown in the boot menu.
>
>> If the first, how to enable os-prober then ?
>
> Make sure os-prober is installed in both linux installs, and
> that is enabled
> in both installs ...
>
> # ll /usr/bin/os-prober

uhm, it says command not found.
I alsto tried apt install ll, but it does not find anything.
Maybe it's a typo and I am too dumb to guess what ... I'll
try LS, maybe

> -rwxr-xr-x 1 root root 6727 Jan 20 05:59 /usr/bin/os-prober*
> # grep PROBER /etc/default/grub
> GRUB_DISABLE_OS_PROBER=false

this one here on Debian is SET TO FALSE already.
Now I check in MX23 ...

yes, also on MX23 it is set to false.

Anyway, as I had asked to J.Aho, who suggested to move MX23
grub files from ... from where they are now, to its own
partition (if they aren't there already), how to ?

>
> Note the double negative. Disable=false means enabled.

yes :D

>
> This way whichever install last had something done that
> caused the grub menu
> to get rebuilt will be the one that gets displayed will be
> the one that creates
> the menu that is shown. It will not matter which one last
> wrote the mbr as both
> should show the same entries in the grub menu.
>
> The other parameters stored in /etc/default/grub should be
> kept the same,
> except for the distributor, and theme, to help avoid
> confusion later.
>
> Regards, Dave Hodgins

I have followed the advices. Now I'll put forth and hope for
the best (one of my Stroustroup preferred citation) :D :D

--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
MarioCPPP

On 04/07/23 09:01, Peter 'Shaggy' Haywood wrote:
> Groovy hepcat Carlos E.R. was jivin' in alt.os.linux on Fri, 30 Jun 2023
> 08:24 pm. It's a cool scene! Dig it.
>
>> On 2023-06-29 18:00, MarioCPPP wrote:
>>> On 29/06/23 08:14, J.O. Aho wrote:
>>>> On 6/28/23 19:08, MarioCPPP wrote:
>>>>> On 28/06/23 14:25, Paul wrote:
>>>>
>>>>>> 2) Initramfs also has a swap check.
>>>>>>
>>>>>> open /etc/initramfs-tools/conf.d/resume
>>>>>> replace RESUME=UUID=xxx with RESUME=none  (or use the correct
>>>>>> blkid!)
>>>>>> issue sudo update-initramfs -u
>>>>>> reboot your system
>>>>>>
>>>>>> I did an update-grub just in case.
>>>>>
>>>>> but in which of the two ?
>>>>
>>>> If you configured your grub correctly
>>>
>>> I have never ever configured it at all.
>>> Each (of the two) distro I've installed, did it all on its own. The
>>> only thing I've chosen is where : the SAME MBR of the same drive (it
>>> is a legacy partitioned, non GPT), and the order. Long beforehand,
>>> Debian. Recently, MX 23.
>>
>> Oh, shit {big moan} :-(
>>
>> You CAN NOT install two linuxes using the same MBR.
>
> What are you talking about? Linux isn't installed in the MBR. If you
> mean grub, okay; but that's not Linux.
> I've had many Linuxen installed on one machine, even on one drive
> having but one MBR, and they all cohabited just fine. But they were
> booted via just one grub installation.
> The mistake Mario made was installing multiple grubs, one apparently
> overwriting the previously existing one. You only need the one boot
> loader. You don't have to install grub with a new distro. Keep the
> original grub installation, update it within the distro that it came
> with, and all should be fine (grub-wise).
> However, since MX is a Debian derivative, it's entirely possible that
> they use the same version of grub. This may reduce the incidence of
> problems: at least until one of the distros has an update. But I would
> still refrain from using the original distro for grub operations, in
> the circumstances.
good to learn. Moreover, incidentally, MX23 that I have
installed lately is based on Bookworm specifically, which
happens to be the Debian version here. So maybe they will
also tend to update kernel's version "pairedly" ... I have
chosen not to install ArtiX kernel, that is available only on MX

--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
MarioCPPP

On Tue, 4 Jul 2023 20:34:38 +0200, MarioCPPP wrote:
> On 04/07/23 20:19, David W. Hodgins wrote:
>> On Tue, 04 Jul 2023 07:12:56 -0400, MarioCPPP
>> <NoliMihiFrangereMentulam@libero.it> wrote:
>>> On 03/07/23 21:57, David W. Hodgins wrote:
>>>> If you have two linux installs, and only one of them has
>>>> os-prober enabled, then
>>
>>> how could I enable os-prober on both ?
>>>
>>>> boot the version without os-prober, and install a kernel,
>>>> the other linux install
>>>> will disappear from the grub menu.
>>>
>>> disappear COMPLETELY you mean, or the old voices would still
>>> show up ?
>>
>> Not show up when booting. The other install will still be
>> there, just not
>> shown in the boot menu.
>>
>>> If the first, how to enable os-prober then ?
>>
>> Make sure os-prober is installed in both linux installs, and
>> that is enabled
>> in both installs ...
>>
>> # ll /usr/bin/os-prober
>
> uhm, it says command not found.
> I alsto tried apt install ll, but it does not find anything.

$ type ll
ll is aliased to `ls -l --human-readable'

> Maybe it's a typo and I am too dumb to guess what ... I'll
> try LS, maybe

Feature of our preferred distro Mageis. :)

>
>> -rwxr-xr-x 1 root root 6727 Jan 20 05:59 /usr/bin/os-prober*
>> # grep PROBER /etc/default/grub
>> GRUB_DISABLE_OS_PROBER=false
>
> this one here on Debian is SET TO FALSE already.
> Now I check in MX23 ...
>
> yes, also on MX23 it is set to false.

Knew the setting because grub had both in menu for selection.

> Anyway, as I had asked to J.Aho, who suggested to move MX23
> grub files from ... from where they are now, to its own
> partition (if they aren't there already), how to ?

That will take more work and best chance screwing up and I
wish you luck getting grub re-installed without losing what you have.

On 2023-07-04 13:30, MarioCPPP wrote:
> On 03/07/23 23:20, Carlos E.R. wrote:
>> On 2023-07-03 20:21, MarioCPPP wrote:
>>> On 03/07/23 06:46, Carlos E.R. wrote:
>>>> On 2023-07-03 00:55, MarioCPPP wrote:
>>>>> On 02/07/23 14:46, Carlos E.R. wrote:
>>>>>> On 2023-07-02 14:21, MarioCPPP wrote:
>>>>>>> On 02/07/23 12:14, Carlos E.R. wrote:
>>>>>>>> On 2023-07-02 02:55, Bit Twister wrote:
>>>>>>>>> On Sat, 1 Jul 2023 23:08:06 +0200, J.O. Aho wrote:
>>>>>>>>>> On 7/1/23 16:13, MarioCPPP wrote:
>>>>>>>>>>> On 30/06/23 12:24, Carlos E.R. wrote:
>>>>>>>>>>
>>>>> CUT
>>>>>
>>>>>>>
>>>>>>> I underline I did not do this "on purpose", but let the installer
>>>>>>> do what it reputed it right.
>>>>>>
>>>>>> Irrelevant. You have to tell the installers what to do. :-)
>>>>>
>>>>> the choices were ... none. The disk was an MBR legacy one, with a
>>>>> huge Debian install on.
>>>>
>>>> And you choose to install something else beside it, without telling
>>>> it to NOT use the mbr. WRONG.
>>>
>>> I keep on not understanding.
>>> If MX would have not installed itself, how could he become bootable ?
>>> I must be dumb, but I preferred not to use some other disk (even I
>>> have others), because in that case, to be able to boot MX, I would
>>> have needed to invoke BIOS boot device selection, which was less
>>> straight forward
>> I'll try again.
>>
>> Assuming a single hard disk.
>>
>> You install distro linux_1, using defaults.  It does "install grub on
>> mbr".
>>
>> Now, there is a single MBR per hard disk. The MBR is just 512 bytes.
>> It contains a partition table that holds 4 partitions (fixed table),
>> and a tiny code.
>>
>> When an IBM PC CLONE boots, or a derived machine using traditional
>> BIOS, it finds the first hard disk and reads the first sector (512)
>> bytes of the first disk, loads that into RAM at a predefined location,
>> and starts the code in that location.
>>
>> It is very simple.
>>
>> Now the computer will do whatever that tiny code says, and nothing
>> else. Ok, when that code comes from a normal grub2 install, it will
>> load several sectors from that hard disk, which are stored in a non
>> assigned space that starts on LBA 0 (grub is on LBA 1), and then run
>> that bigger code (it is several sectors; the size is stored in the MBR
>> code).
>>
>> That bigger code will eventually read a _hardcoded_ partition to find
>> /boot/grub2/grub.cfg and present to you that menu, to boot "linux_1".
>>
>>     That menu may, eventually, include entries to boot instead
>>     another operating system, that were put in the menu by os-prober.
>>
>> Notice this: hardcoded. Not at runtime, but at install time (or update
>> time).
>>
>>
>>
>> Now, you install distro linux_2, using defaults.  It does "install
>> grub on mbr".
>>
>> Now, there is a single MBR per hard disk. The MBR is just 512 bytes.
>> It contains a partition table that holds 4 partitions (fixed table),
>> and a tiny code.
>>
>> When an IBM PC CLONE boots, or a derived machine using traditional
>> BIOS, it finds the first hard disk and reads the first sector (512)
>> bytes of the first disk, loads that into RAM at a predefined location,
>> and starts the code in that location.
>>
>> It is very simple.
>>
>> Now the computer will do whatever that tiny code says, and nothing
>> else. Ok, when that code comes from a normal grub2 install, it will
>> load several sectors from that hard disk, which are stored in a non
>> assigned space that starts on LBA 0 (grub is on LBA 1), and then run
>> that bigger code (it is several sectors; the size is stored in the MBR
>> code).
>>
>> That bigger code will eventually read a _hardcoded_ partition to find
>> /boot/grub2/grub.cfg and present to you that menu, to boot "linux_2".
>>
>>     That menu may, eventually, include entries to boot instead
>>     another operating system, that were put in the menu by os-prober.
>>
>> Notice this: hardcoded. Not at runtime, but at install time (or update
>> time).
>
> I noticed, but I fail to understand what would forbid that this
> hardcoding should be impossible later, exploiting the same mechanism.

Certainly, but it will still be hardcoded. Meaning, when it boots, it is
impossible to present a menu or something to select another boot. It
will stay this way till you do some other update or installation of things.

>> Now you will say that I repeated the same paragraph. Yes, I did,
>> intentionally, to stress the point that linux_2 by default overwrites
>> and destroys what linux_1 did during install.
>>
>>
>>
>> Do you understand this?
>>
>>
>> And every time you manage to boot linux_1 somehow, and update it, or
>> do operations to reinstall grub, it will destroy the boot system of
>> linux_2.
>>
>> And every time you manage to boot linux_2 somehow, and update it, or
>> do operations to reinstall grub, it will destroy the boot system of
>> linux_1.
>
> this point is obscure : why DESTROY and not simply NOT-UPDATED ? I mean,
> why the new update should discard what had just been identified before ?

It destroys. It is as it is.

There is only ONE MBR and ONE space after the MBR and before the
partition 1, between LBA 0 and LBA X.

It is a single, hardcoded, space in the hard disk. Only one system can
install its boot there. A second system destroys the boot of the first
one, and installs itself there. There is no cooperation. The system is
doing as told: install to MBR. You should have told it NOT to install to
MBR.

There is no "identified" part in this.

>
> And more : to have os-prober runned at each update, on both sides,
> should not update also the list of bootable images found ? What is the
> use of os-prober then ?

Forget os-prober, it doesn't intervene at all at this level.

What is done with os-prober is to change the menu. Do you remember this
paragraph:

«That menu may, eventually, include entries to boot instead
another operating system, that were put in the menu by os-prober.»

The menu happen last, at the top level, after the MBR (LBA 0) and LBA
1..X have loaded.

>
> I fail to undetstand why is it not possible to use the same mechanism
> that WORKS on a new install at every update of grub or kernel.
> If not automatedly, why not manually (and how).
> The way seem to exist technically : every new install detects ALL the
> status quo at a given time.
> I would need to ensure this same route is followed also for "minor
> updates" that are not full install.

Then you have not understood what I carefully typed yesterday :-(

>
>>
>>
>> Do you understand this?
>
> in part, but not enough, and I fear I won't without more details of how
> it works
>
>>
>>
>> Now you ask how can I install properly another Linux and we'll take it
>> from there.
>>
>> The thing to understand first is that either linux_1 or linux_2 (or
>> both) can not use MBR to boot, it must use a different sector.

Possibilities:

1)

Disable Linux_2 from updating grub, ever. Or mentally remember to
never update grub from Linux_2. Preferably, remove grub packages and
programs.

Update linux_1 using grub+os-prober to include in the MENU an entry
to boot linux_2. This step has to be repeated on linux_1 everytime the
kernel in Linux_2 is updated (remember that grub in linux_2 is disabled).

2) Modify Linux_2 to install grub instead inside the linux_2 partition.

Modify grub menu of linux 1 to chainload grub of linux_2 partition.
For example, on openSUSE this is done editing "/etc/grub.d/40_custom".

3) (my preferred method)

Modify Linux_1 to install grub instead inside the linux_1 partition.
Modify Linux_2 to install grub instead inside the linux_2 partition.

Install to MBR a modified boot code that will boot the partition that
is marked bootable.

Possibly others.

--
Cheers,
Carlos E.R.

On 2023-07-04 20:24, MarioCPPP wrote:
> On 04/07/23 14:40, J.O. Aho wrote:
>> On 7/4/23 13:30, MarioCPPP wrote:
>>> On 03/07/23 23:20, Carlos E.R. wrote:
>>>> On 2023-07-03 20:21, MarioCPPP wrote:
>
>
>>
>>> I would need to ensure this same route is followed also for "minor
>>> updates" that are not full install.
>>
>> Yes, by only allowing one distro to store it's grub loader on the MBR
>> and the rest has their BR grub loader on the partitions.
>
> How this is done "ex post" ?
> I mean, how can I tell MX23, that is just installed : move your grub
> data from whatever they are to your own partition ? I must add that I
> don't have any more UNUSED partitions.

No. If you installed MX23 on /dev/sda4, its grub goes to the boot sector
of that same sda4.

The method depends on each distribution. For instance, on openSUSE it is
very easy: I start YaST2, choose boot configuration, and change in the
menu the partition where grub is to go.

> In case, MX23 would remain bootable using BIOS boot device selection at
> power on ?

No. The bios can only boot whatever is in the MBR. If what is there is
the grub from linux_1, you have to make it present to you a menu entry
to chainload the grub of linux_2, and/or to probe and find other linuxes
and include boot entries for them.

However, the MBR can contain instead "generic boot code" which loads and
boots whatever partition is marked bootable. This is the preferred
method for multibootin. You would tell linux_1 to install grub to its
own "/", and you would tell linux_2 to install grub to its own "/".

--
Cheers,
Carlos E.R.

On 2023-07-04 09:01, Peter 'Shaggy' Haywood wrote:
> Groovy hepcat Carlos E.R. was jivin' in alt.os.linux on Fri, 30 Jun 2023
> 08:24 pm. It's a cool scene! Dig it.
>
>> On 2023-06-29 18:00, MarioCPPP wrote:
>>> On 29/06/23 08:14, J.O. Aho wrote:
>>>> On 6/28/23 19:08, MarioCPPP wrote:
>>>>> On 28/06/23 14:25, Paul wrote:
>>>>
>>>>>> 2) Initramfs also has a swap check.
>>>>>>
>>>>>> open /etc/initramfs-tools/conf.d/resume
>>>>>> replace RESUME=UUID=xxx with RESUME=none  (or use the correct
>>>>>> blkid!)
>>>>>> issue sudo update-initramfs -u
>>>>>> reboot your system
>>>>>>
>>>>>> I did an update-grub just in case.
>>>>>
>>>>> but in which of the two ?
>>>>
>>>> If you configured your grub correctly
>>>
>>> I have never ever configured it at all.
>>> Each (of the two) distro I've installed, did it all on its own. The
>>> only thing I've chosen is where : the SAME MBR of the same drive (it
>>> is a legacy partitioned, non GPT), and the order. Long beforehand,
>>> Debian. Recently, MX 23.
>>
>> Oh, shit {big moan} :-(
>>
>> You CAN NOT install two linuxes using the same MBR.
>
> What are you talking about? Linux isn't installed in the MBR. If you
> mean grub, okay; but that's not Linux.

Read again. I said "You CAN NOT install two linuxes *using* the same
MBR". I did not say "in the same MBR".

--
Cheers,
Carlos E.R.

On Tue, 04 Jul 2023 16:08:40 -0400, Carlos E. R. <robin_listas@es.invalid> wrote:
> No. If you installed MX23 on /dev/sda4, its grub goes to the boot sector
> of that same sda4.

Given Mario's level of understanding at this point, I do not recommend confusing
the issue further by adding the complexity of chained boot loading.

It is safe to have both installs use the mbr for grub2 provided both installs
use os-prober.

It's correct that the mbr will be overwritten by whichever install last had
a kernel installed, or uninstalled, or where update-grub was last run.

If both linux installs use os-prober, that won't matter. Both installs will
have versions of grub.cfg that allows booting either install.

Regards, Dave Hodgins

On 7/4/23 20:24, MarioCPPP wrote:
> On 04/07/23 14:40, J.O. Aho wrote:
>> On 7/4/23 13:30, MarioCPPP wrote:
>>> On 03/07/23 23:20, Carlos E.R. wrote:
>>>> On 2023-07-03 20:21, MarioCPPP wrote:
>
>
>>
>>> I would need to ensure this same route is followed also for "minor
>>> updates" that are not full install.
>>
>> Yes, by only allowing one distro to store it's grub loader on the MBR
>> and the rest has their BR grub loader on the partitions.
>
> How this is done "ex post" ?
> I mean, how can I tell MX23, that is just installed : move your grub
> data from whatever they are to your own partition ?

This you tend to do when you install the distribution, you should have a
option to tell where to install the BR. Of course you can do it manually
afterwards

sudo grub-install /dev/sdaX --force

If you want to play it safer, you can try to set it on the swap
partition (or in worst case, take a part of the swap and make a new
partition, you will not notices a missing 50MB).

> In case, MX23 would remain bootable using BIOS boot device selection at
> power on ?

Depends on the BIOS, but I would guess it will not be bootable without
another bootloader pointing at it (grub/silo/lilo/...)

Alternative is to make a custom boot entry that loads the MX grub
config (this needs to be done on the debian one and afterwards the
grub.cfg needs to be regenerated):

--- /etc/grub.d/50_mx-grub ---
#! /bin/sh
set -e
cat << EOF
menuentry "MXLinux Grub" {
insmod ext2
set root='hd0,msdos4'
configfile /boot/grub/grub.cfg
} EOF
--- eof ---
Don't forget "chmod 755 /etc/grub.d/50_mx-grub"

The hd0 is Grubs way of saying that it's the first hard disk device
which has many times been the sda. The msdos just tells you you are
using the legacy partition table and the 4 is telling which partition it
is see table under:

1 = primary partition 1
2 = primary partition 2
3 = primary partition 3
4 = primary partition 4
5 = the first extended partition (regardless of how many primary)
6 = the second extended partition
7 = the third extended partition
and so on.

As I'm not a mind reader, you need to experiment if you go this way.
Don't forget to disable grub from installing itself in MX,

--
//Aho

On 7/4/23 22:30, David W. Hodgins wrote:
> On Tue, 04 Jul 2023 16:08:40 -0400, Carlos E. R.
> <robin_listas@es.invalid> wrote:
>> No. If you installed MX23 on /dev/sda4, its grub goes to the boot sector
>> of that same sda4.
>
> Given Mario's level of understanding at this point, I do not recommend
> confusing
> the issue further by adding the complexity of chained boot loading.
>
> It is safe to have both installs use the mbr for grub2 provided both
> installs
> use os-prober.
>
> It's correct that the mbr will be overwritten by whichever install last had
> a kernel installed, or uninstalled, or where update-grub was last run.
>
> If both linux installs use os-prober, that won't matter. Both installs will
> have versions of grub.cfg that allows booting either install.

Oh, but yes it will have issues, Grub do make changes in the stage files
which can make them incompatible with the grub loader stage installed by
earlier versions, then you will not be able to load even the grub rescue
prompt. I can see times when the distros won't be insync with the
version of Grub or that they not been updated by the end user at the
same frequency.

--
//Aho

On 2023-07-04 22:57, J.O. Aho wrote:
> On 7/4/23 22:30, David W. Hodgins wrote:
>> On Tue, 04 Jul 2023 16:08:40 -0400, Carlos E. R.
>> <robin_listas@es.invalid> wrote:
>>> No. If you installed MX23 on /dev/sda4, its grub goes to the boot sector
>>> of that same sda4.
>>
>> Given Mario's level of understanding at this point, I do not recommend
>> confusing
>> the issue further by adding the complexity of chained boot loading.
>>
>> It is safe to have both installs use the mbr for grub2 provided both
>> installs
>> use os-prober.
>>
>> It's correct that the mbr will be overwritten by whichever install
>> last had
>> a kernel installed, or uninstalled, or where update-grub was last run.
>>
>> If both linux installs use os-prober, that won't matter. Both installs
>> will
>> have versions of grub.cfg that allows booting either install.
>
> Oh, but yes it will have issues, Grub do make changes in the stage files
> which can make them incompatible with the grub loader stage installed by
> earlier versions, then you will not be able to load even the grub rescue
> prompt. I can see times when the distros won't be insync with the
> version of Grub or that they not been updated by the end user at the
> same frequency.

Yes. IMHO the status quo can be, rather will be, a source of problems
for the foreseeable future.

--
Cheers,
Carlos E.R.

On Tue, 04 Jul 2023 17:09:32 -0400, Carlos E. R. <robin_listas@es.invalid> wrote:
> On 2023-07-04 22:57, J.O. Aho wrote:
>> Oh, but yes it will have issues, Grub do make changes in the stage files
>> which can make them incompatible with the grub loader stage installed by
>> earlier versions, then you will not be able to load even the grub rescue
>> prompt. I can see times when the distros won't be insync with the
>> version of Grub or that they not been updated by the end user at the
>> same frequency.
>
> Yes. IMHO the status quo can be, rather will be, a source of problems
> for the foreseeable future.

Since the stage 1 part of the boot loader from the mbr will be using the
grub.cfg and stage2 from the same install, how can what's in the other
install impact it?

Regards, Dave Hodgins

On Tue, 4 Jul 2023 22:57:50 +0200, J.O. Aho wrote:
> On 7/4/23 22:30, David W. Hodgins wrote:

>> If both linux installs use os-prober, that won't matter. Both installs will
>> have versions of grub.cfg that allows booting either install.

Only if the "Production" grub is kept up to date.

> Oh, but yes it will have issues, Grub do make changes in the stage files
> which can make them incompatible with the grub loader stage installed by
> earlier versions, then you will not be able to load even the grub rescue
> prompt. I can see times when the distros won't be insync with the
> version of Grub or that they not been updated by the end user at the
> same frequency.

Yep, been there, done that, and have the T-shirt and hat. :)

Hopefully grub.cfg will not become incompatible in the future.

In my stupid opinion the OP needs to make Debian the controlling grub because
that is the default/desired boot for the majority of time.

Anytime MX has a kernel update, he just boots Debian and runs grub-update.
Very straight forward and a very small chance of screwing up.

On 04/07/23 22:08, Carlos E. R. wrote:
> On 2023-07-04 20:24, MarioCPPP wrote:
>> On 04/07/23 14:40, J.O. Aho wrote:
>>> On 7/4/23 13:30, MarioCPPP wrote:
>>>> On 03/07/23 23:20, Carlos E.R. wrote:
>>>>> On 2023-07-03 20:21, MarioCPPP wrote:
>>
>>
>>>
>>>> I would need to ensure this same route is followed also
>>>> for "minor updates" that are not full install.
>>>
>>> Yes, by only allowing one distro to store it's grub
>>> loader on the MBR and the rest has their BR grub loader
>>> on the partitions.
>>
>> How this is done "ex post" ?
>> I mean, how can I tell MX23, that is just installed : move
>> your grub data from whatever they are to your own
>> partition ? I must add that I don't have any more UNUSED
>> partitions.
>
> No. If you installed MX23 on /dev/sda4, its grub goes to the
> boot sector of that same sda4.
>
> The method depends on each distribution. For instance, on
> openSUSE it is very easy: I start YaST2, choose boot
> configuration, and change in the menu the partition where
> grub is to go.
>
>
>> In case, MX23 would remain bootable using BIOS boot device
>> selection at power on ?
>
> No. The bios can only boot whatever is in the MBR.

my BIOSes (at least in legacy mode), I mean all I've had
insofar, scanned ALL hardware devices, and if sth bootable
is found, add them to the list one can switch. I mean, I
have 4 internal physical disks, some MBR, some GPT, and if I
installed a lot of OSes on each, the BIOS would enable me to
boot from any one of them. But I find it annoying to use
this way. Often I don't even remember the key to invoke the
feature at the very start of the bios control.

The current situation though is different, since I have
installed the two Distro on two distinct partition belonging
to one single physical drive (which is MBR), so the bios
boot selection feature is useless here.

I don't dare move MX to another disk

> If what
> is there is the grub from linux_1, you have to make it
> present to you a menu entry to chainload the grub of
> linux_2, and/or to probe and find other linuxes and include
> boot entries for them.
>
>
> However, the MBR can contain instead "generic boot code"
> which loads and boots whatever partition is marked bootable.
> This is the preferred method for multibootin. You would tell
> linux_1 to install grub to its own "/", and you would tell
> linux_2 to install grub to its own "/".
>

how can I discover where it is installed currently ? I see
each distro has one /boot/grub folder, with subfolders like
(locale, i386-pc, fonts) which is located onto the same
"self" partition (the same of /bin /usr and so).

where else should be located ? Is this what you call grub
install or else ?

MX23 too has the same structure (on ITS own root, on the
other partition), plus one "themes" folder, not present in
Debian.

On 2023-07-05 00:13, David W. Hodgins wrote:
> On Tue, 04 Jul 2023 17:09:32 -0400, Carlos E. R.
> <robin_listas@es.invalid> wrote:
>> On 2023-07-04 22:57, J.O. Aho wrote:
>>> Oh, but yes it will have issues, Grub do make changes in the stage files
>>> which can make them incompatible with the grub loader stage installed by
>>> earlier versions, then you will not be able to load even the grub rescue
>>> prompt. I can see times when the distros won't be insync with the
>>> version of Grub or that they not been updated by the end user at the
>>> same frequency.
>>
>> Yes. IMHO the status quo can be, rather will be, a source of problems
>> for the foreseeable future.
>
> Since the stage 1 part of the boot loader from the mbr will be using the
> grub.cfg and stage2 from the same install, how can what's in the other
> install impact it?

Because Linux_2 is still capable of writing again in the MBR.

--
Cheers, Carlos.

On 2023-07-05 10:22, Fonntuggnio wrote:
> On 04/07/23 22:08, Carlos E. R. wrote:
>> On 2023-07-04 20:24, MarioCPPP wrote:
>>> On 04/07/23 14:40, J.O. Aho wrote:
>>>> On 7/4/23 13:30, MarioCPPP wrote:
>>>>> On 03/07/23 23:20, Carlos E.R. wrote:
>>>>>> On 2023-07-03 20:21, MarioCPPP wrote:
>>>
>>>
>>>>
>>>>> I would need to ensure this same route is followed also for "minor
>>>>> updates" that are not full install.
>>>>
>>>> Yes, by only allowing one distro to store it's grub loader on the
>>>> MBR and the rest has their BR grub loader on the partitions.
>>>
>>> How this is done "ex post" ?
>>> I mean, how can I tell MX23, that is just installed : move your grub
>>> data from whatever they are to your own partition ? I must add that I
>>> don't have any more UNUSED partitions.
>>
>> No. If you installed MX23 on /dev/sda4, its grub goes to the boot
>> sector of that same sda4.
>>
>> The method depends on each distribution. For instance, on openSUSE it
>> is very easy: I start YaST2, choose boot configuration, and change in
>> the menu the partition where grub is to go.
>>
>>
>>> In case, MX23 would remain bootable using BIOS boot device selection
>>> at power on ?
>>
>> No. The bios can only boot whatever is in the MBR.
>
> my BIOSes (at least in legacy mode), I mean all I've had insofar,
> scanned ALL hardware devices,

Yes, but MarioCPPP has only one hardware device.

> and if sth bootable is found, add them to
> the list one can switch. I mean, I have 4 internal physical disks, some
> MBR, some GPT, and if I installed a lot of OSes on each, the BIOS would
> enable me to boot from any one of them. But I find it annoying to use
> this way. Often I don't even remember the key to invoke the feature at
> the very start of the bios control.

Not the case here.

>
> The current situation though is different, since I have installed the
> two Distro on two distinct partition belonging to one single physical
> drive (which is MBR), so the bios boot selection feature is useless here.
>
> I don't dare move MX to another disk

Are you MarioCPPP under another name? If this is so, please say so at
the start of the post, this is confusing.

>> If what is there is the grub from linux_1, you have to make it present
>> to you a menu entry to chainload the grub of linux_2, and/or to probe
>> and find other linuxes and include boot entries for them.
>>
>>
>> However, the MBR can contain instead "generic boot code" which loads
>> and boots whatever partition is marked bootable. This is the preferred
>> method for multibootin. You would tell linux_1 to install grub to its
>> own "/", and you would tell linux_2 to install grub to its own "/".
>>
>
> how can I discover where it is installed currently ?

We know that both are set to install grub on MBR, so the latest
install/update overwrites the first.

> I see each distro
> has one /boot/grub  folder, with subfolders like (locale, i386-pc,
> fonts) which is located onto the same "self" partition (the same of /bin
> /usr and so).
>
> where else should be located ? Is this what you call grub install or else ?

I told you already.

There is a tiny code installed in the MBR, which is LBA zero. There is a
relatively bigger code that starts at LBA one, and spans several sectors
before the first partition starts. Notice: this code is outside any
partition. This piece of code finally reads and loads parts from /boot/grub.

In grub parlance, these are stage 1, 1.5, and stage 2. As I am not sure
of the nomenclature, I avoided it.

Look at <https://en.wikipedia.org/wiki/GNU_GRUB>

Look at the graphic:

<https://en.wikipedia.org/wiki/GNU_GRUB#/media/File:GNU_GRUB_on_MBR_partitioned_hard_disk_drives.svg>

Do yo notice sector #0 and sectors 1..62? They are physically unmovable
and single.

Stage 2 can be on any partition, in /boot/grub

>
> MX23 too has the same structure (on ITS own root, on the other
> partition), plus one "themes" folder, not present in Debian.

That's stage 2. Stages 1 and 1.5 are unmovable.

Your problem is that every time you update linux_1 or linux_2, they
overwrite stage 1 and 1.5, rending the other linux unbootable by itself.

--
Cheers, Carlos.

On Wed, 05 Jul 2023 10:22:34 +0200, Fonntuggnio wrote:

<SNIP>

>
> my BIOSes (at least in legacy mode), I mean all I've had insofar,
> scanned ALL hardware devices, and if sth bootable is found, add them to
> the list one can switch. I mean, I have 4 internal physical disks, some
> MBR, some GPT, and if I installed a lot of OSes on each, the BIOS would
> enable me to boot from any one of them. But I find it annoying to use
> this way. Often I don't even remember the key to invoke the feature at
> the very start of the bios control.

And there it is. This poor soul has created a Frankenlinux of Huge
proportions. Best advice for this gentleman is to pick ONE linux as your
main driver, and then use Virtualbox to install and test other distros in
a few virtual machines.

<SNIP>

On Wed, 5 Jul 2023 10:22:34 +0200, Fonntuggnio wrote:

> my BIOSes (at least in legacy mode), I mean all I've had
> insofar, scanned ALL hardware devices, and if sth bootable
> is found, add them to the list one can switch. I mean, I
> have 4 internal physical disks, some MBR, some GPT, and if I
> installed a lot of OSes on each, the BIOS would enable me to
> boot from any one of them. But I find it annoying to use
> this way. Often I don't even remember the key to invoke the
> feature at the very start of the bios control.

All my systems tell of the key(s) to hit to get into the bios menu
at powerup/reboot.

>
> The current situation though is different, since I have
> installed the two Distro on two distinct partition belonging
> to one single physical drive (which is MBR), so the bios
> boot selection feature is useless here.
>
> I don't dare move MX to another disk

Your level of knowledge makes that a very good decision on your part.

>
>
>
> how can I discover where it is installed currently ? I see
> each distro has one /boot/grub folder, with subfolders like
> (locale, i386-pc, fonts) which is located onto the same
> "self" partition (the same of /bin /usr and so).

Yep, last install is the OS that has placed it's grub in charge of
booting.

>
> where else should be located ?

Depends on what you mean.

> Is this what you call grub install or else ?

Still a bit vague on your question. What does "this" refer to?

>
> MX23 too has the same structure (on ITS own root, on the
> other partition), plus one "themes" folder, not present in
> Debian.

I have no idea if MX is using the "themes feature that Debian is
not using or what. If grub versions are pretty close or the same
then we can guess Debian is not using the feature.

Running Installed rpm : grub2-common-2.06-27.mga9 on my Mageia Installed OS
which has the themes directory.

Easiest way to figure out which grub.cfg is being used is to
edit the first menuentry of each grub.cfg with an additional string (Deb,MX) and
reboot and read the presented grub menu.

Be sure to back out your grub.cf change after booting.

Note: next kernel calls grub-update which wipes all/any changes you make
with an editor.