On Wed, 05 Jul 2023 09:10:49 -0400, Carlos E.R. <robin_listas@es.invalid> wrote:

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

So what? It will be putting code in the mbr that points to it's stage 2 in /boot,
and uses it's grub.cfg file. This is not chain loading. Only one version of grub
is in use, and it can boot either install.

Regards, Dave Hodgins

On 7/5/2023 4:22 AM, 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.
>
> 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

Multi-booting is a topic that you learn by doing these things.

You cannot be afraid of making mistakes.

The basics of cloning a disk, you have to remember to make the BLKIDs unique.
And your reply would be "but but, that will break things".
And the answer is, "Yes, yes it will".

Make sure you have a Boot Repair CD.

1) Clone
2) Change BLKID values on destination disk.
3) Use Boot Repair CD, to make the destination disc bootable again, by itself.
This is the way that a lazy guy does the work.

+-----+----------+---------+----------+
| MBR | Swap | Debian | MXLinux |
+-----+----------+---------+----------+

Clone, remove the undesired partition by not cloning it.

+-----+----------+---------+----------+
| MBR | Swap | <none> | MXLinux |
+-----+----------+---------+----------+

List all the BLKIDs on the system. Make sure
to change the BLKIDs on the destination disk.

Now, unplug the source disk. Only the destination disk should be plugged in.
Boot the Boot Repair CD. Boot Repair this disk drive. By itself.

+-----+----------+---------+----------+
| MBR | Swap | <none> | MXLinux |
+-----+----------+---------+----------+

Now, do a test boot of the clone. Does it work ?

While booted in MXLinux, and with the MXLinux drive all by itself,
do a "sudo update-grub" or equivalent. Hopefully, this should
improve what you see in the boot menu on it.

As Yoda would say "Do or Do not, there is no Try".

You practice your craft, until you get it right.

The issues may be slightly different, on a legacy MSDOS setup,
versus a UEFI disk setup.

Being a fraidy-cat isn't going to get you anywhere.

So your first preparatory step, is preparing your Boot Repair CD.

The other thing you need, is hard drives, enough hard drives to
keep your materials safe, while you experiment.

This is my favorite drive, for boot experiments. WD1003FZEX.
Buy from a local retailer. On one of these I purchased locally,
the spindle did not spin. I took it back and got a substitute one
that did spin. That's the first retail drive that has been
dead-on-arrival. Still, the price is reasonable. And it does not
wear like an SSD flash-based drive.

https://www.newegg.com/black-wd1003fzex-1tb/p/N82E16822236625

As far as practices go, I prefer a /swapfile on each OS partition,
not because I am in love with the concept. Instead, the /swapfile
is preferred because of the lousy handling of swap by GRUB. In the
past, I used a swap partition quite successfully. But today, as
the lazy guy in the description, I no longer want to worry about
the BLKID of swap constantly being changed by something I've done,
so /swapfile is the preferred method now.

And yes, I have manually changed all the OSes on a multiboot Linux,
to using swapfile. I was angry at the time, and wanted to smack someone,
but I did it. I caught Ubuntu searching for RAID and BTRFS partitions
(two minute boot times), and at first I figured I'd screwed something
else up for this behavior to exist. Well, Ubuntu was doing this
stupid stuff, purely because it could not find swap. Never work on
computers when you're angry :-)

Paul

On Wed, 5 Jul 2023 12:25:48 -0400, Paul wrote:
> On 7/5/2023 4:22 AM, 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.
>>
>> 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
>
> Multi-booting is a topic that you learn by doing these things.
>
> You cannot be afraid of making mistakes.
>
> The basics of cloning a disk, you have to remember to make the BLKIDs unique.
> And your reply would be "but but, that will break things".
> And the answer is, "Yes, yes it will".
>
> Make sure you have a Boot Repair CD.
>
> 1) Clone
> 2) Change BLKID values on destination disk.
> 3) Use Boot Repair CD, to make the destination disc bootable again, by itself.
> This is the way that a lazy guy does the work.
>
> +-----+----------+---------+----------+
> | MBR | Swap | Debian | MXLinux |
> +-----+----------+---------+----------+
>
> Clone, remove the undesired partition by not cloning it.
>
> +-----+----------+---------+----------+
> | MBR | Swap | <none> | MXLinux |
> +-----+----------+---------+----------+
>
> List all the BLKIDs on the system. Make sure
> to change the BLKIDs on the destination disk.

AND update/fix /etc/fstab !!!!!!

> Now, unplug the source disk. Only the destination disk should be plugged in.
> Boot the Boot Repair CD. Boot Repair this disk drive. By itself.
>
> +-----+----------+---------+----------+
> | MBR | Swap | <none> | MXLinux |
> +-----+----------+---------+----------+
>
> Now, do a test boot of the clone. Does it work ?
>
> While booted in MXLinux, and with the MXLinux drive all by itself,
> do a "sudo update-grub" or equivalent. Hopefully, this should
> improve what you see in the boot menu on it.
>
> As Yoda would say "Do or Do not, there is no Try".
>
> You practice your craft, until you get it right.
>
> The issues may be slightly different, on a legacy MSDOS setup,
> versus a UEFI disk setup.
>
> Being a fraidy-cat isn't going to get you anywhere.
>
> So your first preparatory step, is preparing your Boot Repair CD.
>
> The other thing you need, is hard drives, enough hard drives to
> keep your materials safe, while you experiment.
>
> This is my favorite drive, for boot experiments. WD1003FZEX.
> Buy from a local retailer. On one of these I purchased locally,
> the spindle did not spin. I took it back and got a substitute one
> that did spin. That's the first retail drive that has been
> dead-on-arrival. Still, the price is reasonable. And it does not
> wear like an SSD flash-based drive.
>
> https://www.newegg.com/black-wd1003fzex-1tb/p/N82E16822236625
>
> As far as practices go, I prefer a /swapfile on each OS partition,
> not because I am in love with the concept. Instead, the /swapfile
> is preferred because of the lousy handling of swap by GRUB. In the
> past, I used a swap partition quite successfully. But today, as
> the lazy guy in the description, I no longer want to worry about
> the BLKID of swap constantly being changed by something I've done,
> so /swapfile is the preferred method now.
>
> And yes, I have manually changed all the OSes on a multiboot Linux,
> to using swapfile. I was angry at the time, and wanted to smack someone,
> but I did it. I caught Ubuntu searching for RAID and BTRFS partitions
> (two minute boot times), and at first I figured I'd screwed something
> else up for this behavior to exist. Well, Ubuntu was doing this
> stupid stuff, purely because it could not find swap. Never work on
> computers when you're angry :-)

It is not the fault of grub, per se, but the fact that the os installer
formats swap during install causing the swap partition to be changed.

I solved my problem by using a Partition Label, and modify /etc/fstab
to use the Partition Label.

$ lsblk -o NAME,TYPE,FSTYPE,MOUNTPOINT,LABEL,PARTLABEL | grep swap
NAME TYPE FSTYPE MOUNTPOINT LABEL PARTLABEL
s├─sda11 part swap [SWAP] swap swap

$ grep swap /etc/fstab
PARTLABEL=swap swap swap defaults,nofail 0 0

On 05/07/23 15:26, Carlos E.R. wrote:
> 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.
no, sorry, It was always myself. Often I got error message
from the server that does not let me post for unknown
reasons, and I reply with other accounts.
Fonntuggnio was myself.
I have a lot of drives (physical), but I did not use any
other for the system, since the same that I chose was an
nvme type (the faster) and half empty (since I had moved the
large /home on an HDD).
>
>> 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.
Well, not actually. It could have been potentially, If I had
installed MX onto another SDD (that is empty now).
>
>>
>> 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.
sorry ... the server was annoying with denials.
I forgot to state It wes myself :\
>
>
>
>>> 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.
in fact it shows themes from MX
>
>> 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>
I'll go, tnx
>
>
> 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.
that's one of the few thing I have understood.
But having enabled the os-prober on both, would this be
enough or no ?
>
>
--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
MarioCPPP

On 05/07/23 15:55, Bubba the Corn Dog wrote:
> 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.

it would not be useful for the main aim : to have a second
system to do offline backups of the main one.
I used to use Virtual Box, but lately It gave a lot of
problems, refusing to load saved images (getting stuck at 20
% forever, while beforehands it had been fast). Moreover a
virtual guest cannot do a backup of its host.

In the end I dropped Vbox usage

>
>
> <SNIP>

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

On 2023-07-05 17:17, David W. Hodgins wrote:
> On Wed, 05 Jul 2023 09:10:49 -0400, Carlos E.R.
> <robin_listas@es.invalid> wrote:
>
>> 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.
>
> So what? It will be putting code in the mbr that points to it's stage 2
> in /boot,
> and uses it's grub.cfg file. This is not chain loading. Only one version
> of grub
> is in use, and it can boot either install.

So what? It destroys stage 1 and 1.5 of linux_1, and boots instead linux_2.

--
Cheers, Carlos.

On Wed, 05 Jul 2023 21:08:16 +0200, MarioCPPP wrote:

> On 05/07/23 15:55, Bubba the Corn Dog wrote:
>> 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.
>
> it would not be useful for the main aim : to have a second system to do
> offline backups of the main one.
> I used to use Virtual Box, but lately It gave a lot of problems,
> refusing to load saved images (getting stuck at 20 % forever, while
> beforehands it had been fast). Moreover a virtual guest cannot do a
> backup of its host.
>
> In the end I dropped Vbox usage

I use VirtualBox to run/test six seperate Linux Distros and 1 Win10 vm. I
have never had Virtualbox stall loading a vdi file. Sounds to me like
you have some serious issues with you linux install. Like I suggested
earlier, pick ONE Linux distro as your main driver, do a clean install,
(I use LMDE5 which is based on Debian Bullseye), install Virtualbox,
create your vms are different HD's if you so desire.

If you want to do offline backups download clonezilla, install it on a
flash drive and let it do a complte image of you HD/SSD. Been using
clonezilla for 8 years, I use it now to backup my 1 TB Samsung Evo Plus
SSD. I store the images on my old 500 GB Samsung EVO 850 house ina
external usb enclosure. I use option #4 Partclone using DD and I have had
a failed backup in those 8 years.

I will stand by what I stated earlier, you have created as Massive
Frankenlinux of which there probably is no undoing the carnage. However
it is your freedom to continue torturing yourself if you so desire.

On Wed, 5 Jul 2023 21:05:19 +0200, MarioCPPP wrote:
> On 05/07/23 15:26, Carlos E.R. wrote:

>> 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.
>
> that's one of the few thing I have understood.
> But having enabled the os-prober on both, would this be
> enough or no ?

os-prober runs when grub-update is executed and only re-creates grub.cfg
for that install.

On Wed, 5 Jul 2023 21:08:16 +0200, MarioCPPP wrote:
> On 05/07/23 15:55, Bubba the Corn Dog wrote:
>> On Wed, 05 Jul 2023 10:22:34 +0200, Fonntuggnio wrote:
>>
>> 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.
>
> it would not be useful for the main aim : to have a second
> system to do offline backups of the main one.
> I used to use Virtual Box, but lately It gave a lot of
> problems, refusing to load saved images (getting stuck at 20
> % forever, while beforehands it had been fast). Moreover a
> virtual guest cannot do a backup of its host.

Very true.

> In the end I dropped Vbox usage

How sad, a perfect place to do a dual OS install one one guest
and experiment without screwing up current HOST.

On Wed, 05 Jul 2023 17:54:00 -0400, Carlos E.R. <robin_listas@es.invalid> wrote:
> So what? It destroys stage 1 and 1.5 of linux_1, and boots instead linux_2.

No it does not, unless /boot is also shared which is not what's being discussed.
It's the mbr and the mbr only that is being overwritten.

Regards, Dave Hodgins

On 7/5/23 21:08, MarioCPPP wrote:
> On 05/07/23 15:55, Bubba the Corn Dog wrote:
>> 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.
>
> it would not be useful for the main aim : to have a second system to do
> offline backups of the main one.

For that you could just have a USB stick with a distro, you just plug it
in when you want to do backups of the system and boot from the USB.

In the BIOS you could set the USB boot have higher priority than the
internal hard-drive.

--
//Aho

On 2023-07-06 01:33, David W. Hodgins wrote:
> On Wed, 05 Jul 2023 17:54:00 -0400, Carlos E.R.
> <robin_listas@es.invalid> wrote:
>> So what? It destroys stage 1 and 1.5 of linux_1, and boots instead
>> linux_2.
>
> No it does not, unless /boot is also shared which is not what's being
> discussed.
> It's the mbr and the mbr only that is being overwritten.

No, stage 1.5 is also overwritten. It is not inside /boot. It is on LBA
1..63

Overwriting only stage 1 and not 1.5 renders the machine unbootable, or
booting the wrong /boot.

--
Cheers, Carlos.

On 06/07/23 12:38, Carlos E.R. wrote:
> On 2023-07-06 01:33, David W. Hodgins wrote:
>> On Wed, 05 Jul 2023 17:54:00 -0400, Carlos E.R.
>> <robin_listas@es.invalid> wrote:
>>> So what? It destroys stage 1 and 1.5 of linux_1, and
>>> boots instead linux_2.
>>
>> No it does not, unless /boot is also shared which is not
>> what's being discussed.
>> It's the mbr and the mbr only that is being overwritten.
>
> No, stage 1.5 is also overwritten. It is not inside /boot.
> It is on LBA 1..63
>
> Overwriting only stage 1 and not 1.5 renders the machine
> unbootable, or booting the wrong /boot.
>

so how to make sure every time stage 1 is overwritten, then
also stage 1.5 is ?
I mean doing it on purpose, not simply let it done on a new
install (or, MAYBE, not sure of this, on grub-update) ?

One thing also I have not understood.

There is difference from a grub-update caused by a new
version or a manual one ?
In particular, when one attempts the command update-grub but
it answers : the package is just at its latest version ...
this way I presume nothing changes and no overwrite at all
happens. Or not ?

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

On 06/07/23 07:52, J.O. Aho wrote:
> On 7/5/23 21:08, MarioCPPP wrote:
>> On 05/07/23 15:55, Bubba the Corn Dog wrote:
>>> 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.
>>
>> it would not be useful for the main aim : to have a second
>> system to do offline backups of the main one.
>
> For that you could just have a USB stick with a distro, you
> just plug it in when you want to do backups of the system
> and boot from the USB.
well, I do have, but it is slow to load. Also that was the
main goal, but not the only one.
I also would prefer to have a second spare FULL system for
emergencies, particularly when i.g. the main one need some
deep mainteinance while at the same time beeing still able
to do some work (they share the data disk, so I can keep on
working on documents and data also from MX, at need).
I mean, you are not using continually a safety boat, but
it's useful that it is there

>
> In the BIOS you could set the USB boot have higher priority
> than the internal hard-drive.
>
--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
MarioCPPP

On Thu, 6 Jul 2023 13:55:54 +0200, MarioCPPP wrote:
> On 06/07/23 12:38, Carlos E.R. wrote:

>>
>> Overwriting only stage 1 and not 1.5 renders the machine
>> unbootable, or booting the wrong /boot.
>>
>
> so how to make sure every time stage 1 is overwritten, then
> also stage 1.5 is ?

What is your problem here, You can screw up the partition by formatting
it. What does is matter, in either case loss of data will prevent booting.

> I mean doing it on purpose, not simply let it done on a new
> install (or, MAYBE, not sure of this, on grub-update) ?

To my knowledge grub-update does not overwrite stage 1 and 2.
It only renames grub.cfg and creates a new one.

> One thing also I have not understood.
>
> There is difference from a grub-update caused by a new
> version or a manual one ?

One more time, trust me, grub-update will scan all your partitions
and create an entry for each kernel found in grub.cfg.

Does not matter how often you run it.
grub-update is executed by the kernel install/update package.

> In particular, when one attempts the command update-grub but
> it answers : the package is just at its latest version ...
> this way I presume nothing changes and no overwrite at all
> happens. Or not ?

Why assume. run update-grub and do a
ls -al /boot/
ls -al /boot/grub*

To answer your next post, partitions mounted read/write can be
shared between installs.

You just need to make sure that Uid,Gid and group access are the same for same
users .

to check run
id users_of_interest_here
on each booted install.

On Thu, 06 Jul 2023 06:38:53 -0400, Carlos E.R. <robin_listas@es.invalid> wrote:

> On 2023-07-06 01:33, David W. Hodgins wrote:
>> On Wed, 05 Jul 2023 17:54:00 -0400, Carlos E.R.
>> <robin_listas@es.invalid> wrote:
>>> So what? It destroys stage 1 and 1.5 of linux_1, and boots instead
>>> linux_2.
>>
>> No it does not, unless /boot is also shared which is not what's being
>> discussed.
>> It's the mbr and the mbr only that is being overwritten.
>
> No, stage 1.5 is also overwritten. It is not inside /boot. It is on LBA
> 1..63
>
> Overwriting only stage 1 and not 1.5 renders the machine unbootable, or
> booting the wrong /boot.

Sorry, my mistake. The stage 1 code is in the mbr itself before the primary
partition table, with 1.4 in the rest of the first track.
https://en.wikipedia.org/wiki/GNU_GRUB#Version_2_(GRUB_2)

Never the less, when either linux install adds or removes a kernel, both
stage1 and 1.5 get overwritten with the result that it uses the matching
grub.cfg and stage2 from it's /boot.

Regards, Dave Hodgins

On 2023-07-06 18:57, David W. Hodgins wrote:
> On Thu, 06 Jul 2023 06:38:53 -0400, Carlos E.R.
> <robin_listas@es.invalid> wrote:
>
>> On 2023-07-06 01:33, David W. Hodgins wrote:
>>> On Wed, 05 Jul 2023 17:54:00 -0400, Carlos E.R.
>>> <robin_listas@es.invalid> wrote:
>>>> So what? It destroys stage 1 and 1.5 of linux_1, and boots instead
>>>> linux_2.
>>>
>>> No it does not, unless /boot is also shared which is not what's being
>>> discussed.
>>> It's the mbr and the mbr only that is being overwritten.
>>
>> No, stage 1.5 is also overwritten. It is not inside /boot. It is on LBA
>> 1..63
>>
>> Overwriting only stage 1 and not 1.5 renders the machine unbootable, or
>> booting the wrong /boot.
>
> Sorry, my mistake. The stage 1 code is in the mbr itself before the primary
> partition table, with 1.4 in the rest of the first track.
> https://en.wikipedia.org/wiki/GNU_GRUB#Version_2_(GRUB_2)

Right.

Nice graphic:

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

>
> Never the less, when either linux install adds or removes a kernel, both
> stage1 and 1.5 get overwritten with the result that it uses the matching
> grub.cfg and stage2 from it's /boot.

Just updating the kernel should not touch stages 1 & 1.5; just updating
the menu text file(s) should be enough, because stage 2 is capable of
reading filesystems, and access files like the kernel by its name.

That's the beauty of grub vs lilo.

Stages 1 & 1.5 get written when updating grub itself, and maybe some
other operations.

Of course, some distro might do things differently and actually write
stages 1 & 1.5 when updating the kernel; unneeded but possible.

For instance, the openSUSE tool YaST writes everything when you edit the
timeout value, which is a useful feature to know.

--
Cheers, Carlos.

On Fri, 07 Jul 2023 06:29:56 -0400, Carlos E.R. <robin_listas@es.invalid> wrote:
> Just updating the kernel should not touch stages 1 & 1.5; just updating
> the menu text file(s) should be enough, because stage 2 is capable of
> reading filesystems, and access files like the kernel by its name.
>
> That's the beauty of grub vs lilo.
>
> Stages 1 & 1.5 get written when updating grub itself, and maybe some
> other operations.
>
> Of course, some distro might do things differently and actually write
> stages 1 & 1.5 when updating the kernel; unneeded but possible.
>
>
> For instance, the openSUSE tool YaST writes everything when you edit the
> timeout value, which is a useful feature to know.

If stage 1 and 1.5 don't get overwritten, how does booting end up loading
the new grub.cfg file?

Regards, Dave Hodgins

On 2023-07-07 19:07, David W. Hodgins wrote:
> On Fri, 07 Jul 2023 06:29:56 -0400, Carlos E.R.
> <robin_listas@es.invalid> wrote:
>> Just updating the kernel should not touch stages 1 & 1.5; just updating
>> the menu text file(s) should be enough, because stage 2 is capable of
>> reading filesystems, and access files like the kernel by its name.
>>
>> That's the beauty of grub vs lilo.
>>
>> Stages 1 & 1.5 get written when updating grub itself, and maybe some
>> other operations.
>>
>> Of course, some distro might do things differently and actually write
>> stages 1 & 1.5 when updating the kernel; unneeded but possible.
>>
>>
>> For instance, the openSUSE tool YaST writes everything when you edit the
>> timeout value, which is a useful feature to know.
>
> If stage 1 and 1.5 don't get overwritten, how does booting end up loading
> the new grub.cfg file?

Stage 1.5 can read the files it needs by name and path.

Do you know the tool "bootinfoscript"?
https://github.com/arvidjaar/bootinfoscript

It is just a script, try it on a computer with MBR,

An example of a multiboot MBR computer - I quote the text to break
Thunderbird from wrapping the lines:

> Boot Info Script 0.76 [13 April 2017]
>
> Last git commit: Also search for grub2 custom.cfg on FAT
> Commit date: 2017-04-23T05:49:05Z
>
>
> ============================= Boot Info Summary: ===============================
>
> => Syslinux ALTMBR (4.06 and higher) with boot partition 0x04 is installed in
> the MBR of /dev/sda.
> => Syslinux GPTMBR (4.04-5.01) is installed in the MBR of /dev/sdb.
>
> sda1: __________________________________________________________________________
>
> File system: ntfs
> Boot sector type: Windows 8/2012: NTFS
> Boot sector info: No errors found in the Boot Parameter Block.
> Operating System:
> Boot files: /bootmgr /Boot/BCD
>
> sda2: __________________________________________________________________________
>
> File system: ntfs
> Boot sector type: Windows 7/2008: NTFS
> Boot sector info: No errors found in the Boot Parameter Block.
> Operating System:
> Boot files: /bootmgr /boot/BCD /Windows/System32/winload.exe
>
> sda3: __________________________________________________________________________
>
> File system: crypto_LUKS
> Boot sector type: Unknown
> Boot sector info:
>
> sda4: __________________________________________________________________________
>
> File system: Extended Partition
> Boot sector type: Grub2 (v1.99-2.00)
> Boot sector info: Grub2 (v2.00) is installed in the boot sector of sda4
> and looks at sector 396060737 of the same hard drive
> for core.img. core.img is at this location and looks
> for (,msdos7)/boot/grub2. It also embeds following
> components:
>
> modules
> -------------------------------------------------------
> fshelp ext2 part_msdos biosdisk
> -------------------------------------------------------
>
> sda5: __________________________________________________________________________
>
> File system: swap
> Boot sector type: -
> Boot sector info:
>
> sda6: __________________________________________________________________________
>
> File system: ext2
> Boot sector type: -
> Boot sector info:
> Operating System:
> Boot files: /grub2/grub.cfg /boot/grub2/grub.cfg /grub2/custom.cfg
> /boot/grub2/custom.cfg /grub2/i386-pc/core.img
> /boot/grub2/i386-pc/core.img
>
> sda7: __________________________________________________________________________
>
> File system: ext4
> Boot sector type: -
> Boot sector info:
> Operating System: openSUSE Leap 15.2
> Boot files: /boot/grub2/grub.cfg /boot/grub2/custom.cfg /etc/fstab
> /boot/grub2/i386-pc/core.img

Summary:

«=> Syslinux ALTMBR (4.06 and higher) with boot partition 0x04 is
installed in the MBR of /dev/sda.»

So, it jumps to partition 4.

What does sda4?

«Grub2 (v2.00) is installed in the boot sector of sda4
and looks at sector 396060737 of the same hard drive
for core.img. core.img is at this location and looks
for (,msdos7)/boot/grub2.»

So, it reads "sector 396060737", that's hardcoded. Where is that sector?
in sda7, if I read it correctly:

fdisk:
Partition Boot Start Sector End Sector # of Sectors Id System
/dev/sda6 345,863,448 346,265,009 401,562 83 Linux
/dev/sda7 346,265,073 409,175,549 62,910,477 83 Linux

which is an ext4 partition, "/". But then it says:

«core.img is at this location and looks for (,msdos7)/boot/grub2»

ie, the code inside core.img, which was loaded by sector number (it is
outside of the filesystem), reads /boot/grub2 by path name.

Notice that core.img is written outside of the partition filesystem, but
also as a file. The file is copied at grub install time to its hardcoded
location outside.

Seen also in
<https://en.wikipedia.org/wiki/GNU_GRUB#/media/File:GNU_GRUB_components.svg>

It is very instructive analyzing computers with this script.
Unfortunately, it breaks with some SSD disks. Those M.2, I think.

--
Cheers, Carlos.

On Fri, 07 Jul 2023 15:51:12 -0400, Carlos E.R. <robin_listas@es.invalid> wrote:

> On 2023-07-07 19:07, David W. Hodgins wrote:
>> On Fri, 07 Jul 2023 06:29:56 -0400, Carlos E.R.
>> <robin_listas@es.invalid> wrote:
>>> Just updating the kernel should not touch stages 1 & 1.5; just updating
>>> the menu text file(s) should be enough, because stage 2 is capable of
>>> reading filesystems, and access files like the kernel by its name.
>>>
>>> That's the beauty of grub vs lilo.
>>>
>>> Stages 1 & 1.5 get written when updating grub itself, and maybe some
>>> other operations.
>>>
>>> Of course, some distro might do things differently and actually write
>>> stages 1 & 1.5 when updating the kernel; unneeded but possible.
>>>
>>>
>>> For instance, the openSUSE tool YaST writes everything when you edit the
>>> timeout value, which is a useful feature to know.
>>
>> If stage 1 and 1.5 don't get overwritten, how does booting end up loading
>> the new grub.cfg file?
>
> Stage 1.5 can read the files it needs by name and path.

You missed the point of my question. You're saying installing a kernel does not
overwrite stage 1.5 on track 0. I'm saying it does.

If it didn't, installing a new kernel in a two linux install where both are
set to use the mbr, would not switch backgrounds, etc. It does in my
experience.

Regards, Dave Hodgins

On 2023-07-07 22:33, David W. Hodgins wrote:
> On Fri, 07 Jul 2023 15:51:12 -0400, Carlos E.R. <robin_listas@es.invalid> wrote:
>> On 2023-07-07 19:07, David W. Hodgins wrote:
>>> On Fri, 07 Jul 2023 06:29:56 -0400, Carlos E.R. <robin_listas@es.invalid> wrote:
>>>> Just updating the kernel should not touch stages 1 & 1.5; just updating
>>>> the menu text file(s) should be enough, because stage 2 is capable of
>>>> reading filesystems, and access files like the kernel by its name.
>>>>
>>>> That's the beauty of grub vs lilo.
>>>>
>>>> Stages 1 & 1.5 get written when updating grub itself, and maybe some
>>>> other operations.
>>>>
>>>> Of course, some distro might do things differently and actually write
>>>> stages 1 & 1.5 when updating the kernel; unneeded but possible.
>>>>
>>>>
>>>> For instance, the openSUSE tool YaST writes everything when you edit
>>>> the
>>>> timeout value, which is a useful feature to know.
>>>
>>> If stage 1 and 1.5 don't get overwritten, how does booting end up
>>> loading
>>> the new grub.cfg file?
>>
>> Stage 1.5 can read the files it needs by name and path.
>
> You missed the point of my question. You're saying installing a kernel
> does not overwrite stage 1.5 on track 0. I'm saying it does.

I'm positive on this.

> If it didn't, installing a new kernel in a two linux install where both are
> set to use the mbr, would not switch backgrounds, etc. It does in my
> experience.

That can happen if your distribution, for some reason, when updating a
kernel includes a call to update grub hardcoded sectors. Mine doesn't.

Do a test. Edit yourself, by hand, the grub menu minimally, just the
name of another boot entry. Then boot to see if the menu change is seen.
Or try in a virtual machine.

--
Cheers, Carlos.

On 06/07/23 17:10, Bit Twister wrote:
> On Thu, 6 Jul 2023 13:55:54 +0200, MarioCPPP wrote:
>> On 06/07/23 12:38, Carlos E.R. wrote:
>
>>>
SNIP

>
> To answer your next post, partitions mounted read/write can be
> shared between installs.
>
> You just need to make sure that Uid,Gid and group access are the same for same
> users .
>
> to check run
> id users_of_interest_here
> on each booted install.

I am not totally sure, but I think I use Uid / Gid 1000:1000
for both debian and MX ...

or at least I had to do a recursive chown using such, in MX,
and I can access the files in debian too. So it seems that
permissions work,

Before I wondered why numbers and not the login names were
used for permissions. Now I blessed such choice, since the
users in MX and Debian don't have the same name ! But
numbers seems the same and that's enough (apparently :D)

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

On 2023-07-09 17:17, MarioCPPP wrote:
> On 06/07/23 17:10, Bit Twister wrote:
>> On Thu, 6 Jul 2023 13:55:54 +0200, MarioCPPP wrote:
>>> On 06/07/23 12:38, Carlos E.R. wrote:
>>
>>>>
> SNIP
>
>>
>> To answer your next post, partitions mounted read/write can be
>> shared between installs.
>>
>> You just need to make sure that Uid,Gid and group access are the same
>> for same
>> users .
>>
>> to check run
>>      id users_of_interest_here
>> on each booted install.
>
> I am not totally sure, but I think I use Uid / Gid 1000:1000 for both
> debian and MX ...
>
> or at least I had to do a recursive chown using such, in MX, and I can
> access the files in debian too. So it seems that permissions work,
>
> Before I wondered why numbers and not the login names were used for
> permissions. Now I blessed such choice, since the users in MX and Debian
> don't have the same name ! But numbers seems the same and that's enough
> (apparently :D)

Sometimes it is an advantage, some times it is not.
It is an ancient design choice.

It is a problem when sharing files across computers that were installed
by different people, either on NFS, or movable disks.

--
Cheers, Carlos.