Mailing List Archive

On Friday, 8 March 2024 23:24:02 GMT Grant Edwards wrote:
> On 2024-02-22, Grant Edwards <grant.b.edwards@gmail.com> wrote:
> > For many years, I've used a hard drive on which I have 8-10 Linux
> > distros installed -- each in a separate (single) partition.
> >
> > [...]
> >
> > Is there an easier way to do this?
>
> After some additional studying of UEFI and boot managers like rEFInd,
> I decided that my current approach was still the easiest method. I did
> switch from DOS to GPT disklabel (I bricked my old drive tring to
> update the firmware, so I had to start over anyway).
>
> In case anybody is interested in the gory details, I documented my
> scheme and the helper shell scripts at
>
> https://github.com/GrantEdwards/Linux-Multiboot


Thank you Grant for taking time to share your clear and well structured write
up, what with helpful scripts and all! Its easy to follow and should help
others, hopefully before they discover belatedly many distro installers can
mess up a multiboot scheme, if they don't step in to keep things in check.

Perhaps I'm picking up on semantics, but shouldn't this sentence:

"... The gap between the DOS disklabel and the first partition"

read:

"The gap between the MBR and the first partition"?

I'm saying this because the MBR in sector 0 contains the bootstrap code (446
bytes), the partition table (a.k.a. DOS disklabel 4x16 bytes) and the boot
sector signature (2 bytes). On MBR partitioned disks the core.img is stored
after the MBR, in sector 1 onward.

Your next paragraph pointed out something which I hadn't considered at any
length. Namely, the installation of GRUB's boot.img in a MBR or VBR also
hardcodes in a block list format the location of the first sector where the
core.img is stored and more importantly, the physical position of this sector
can be altered both by COW fs (and by the wear levelling firmware of flash
storage devices).

I had assumed both the COW fs and/or the flash controller will in both cases
translate any physical data position to the logical layer and presented this
to inquiring software. Have you actually tried using btrfs as a distro's root
fs to see if the VBR installed GRUB boot.img will ever lose access to the
core.img?

On 2024-03-10, Michael <confabulate@kintzios.com> wrote:

> Perhaps I'm picking up on semantics, but shouldn't this sentence:
>
> "... The gap between the DOS disklabel and the first partition"
>
> read:
>
> "The gap between the MBR and the first partition"?

Yes, thanks -- MBR is more accurate, I've changed that sentence.

> Your next paragraph pointed out something which I hadn't considered at any
> length. Namely, the installation of GRUB's boot.img in a MBR or VBR also
> hardcodes in a block list format the location of the first sector where the
> core.img is stored and more importantly, the physical position of this sector
> can be altered both by COW fs (and by the wear levelling firmware of flash
> storage devices).
>
> I had assumed both the COW fs and/or the flash controller will in
> both cases translate any physical data position to the logical layer
> and presented this to inquiring software. Have you actually tried
> using btrfs as a distro's root fs to see if the VBR installed GRUB
> boot.img will ever lose access to the core.img?

No, I haven't. I agree that the flash controller can't change the
logical address of a filesystem data block without the knowledge of the
filesystem, so I don't think controller layer wear-leveling would be
a problem. But, the filesystem layer is allowed to move data blocks
around, so flash-aware filesystems that attempt to do wear-leveling
or defragmentation could move data blocks.

Some of the descriptions I've read of "fancier" filesystem internals
have also implied implied that does happen under certain conditions,
but I may have misunderstood or the descriptions may have been wrong.

My use of these multi-boot installs have no need for anything beyond
exnN, so I've never tried using block lists with anything other than
extN filesystems. Since I am confident extN filesystems won't cause
problems, I've always stuck with that.

--
Grant