Reco <recovery...@enotuniq.net> writes:
> On Sat, Jun 05, 2021 at 12:46:13PM -0500, Martin McCormick wrote:
> > I have a plan but I need some more information. Is there any
> > personalization done by the boot setup process?
>
> Yes. One of the GRUB's tasks is to supply kernel which is about to boot
> with root=... cmdline parameter. Root filesystem UUID can be used for
> this.
>
>
> > Do our UUID's or any other specific information pertaining to the
> > installation make it in to the initrd files?
>
> In Debian - no, unless you include it there for some bizarre reason.
> It's not needed for the things initrd usually does.
>
>
> > If that is so, then two computers using the same
> > processor type should be able to use copies of the same initrd files
> > and the only thing that is personalized on an individual computer
> > is all the grub configuration in which the UUID's of at least /
> > and /swap partitions are sprinkled throughout grub.cfg and
> > /etc/default/grub.
>
> It's not the CPU difference you need to worry about.
> Different SATA controllers, video cards, NICs - i.e. what they call
> periphery devices - those things require different kernel modules that
> should be (or could be) used in early boot process, and therefore need
> to be included in initrd.
>
> Luckily, Debian uses initramfs-tools for building initrd, and
> initramfs-tools should build initrd with everything and a kitchen sink
> included (MODULES=most in /etc/initramfs-tools/initramfs.conf).
>
>
> > One should be able to write a program to get the
> > appropriate UUID's out of fstab on the working system
> > and translate them in to corresponding UUID's for the system on
> > the operating table.
>
> Er, they've invented filesystem labels for exactly this many decades
> ago.
>
>
> > As an aside, one ought to be able to do something like
> > this. It makes life a lot simpler. Both systems are using the
> > same kernel and versions of the same processor the only real
> > differences are the UUID's.
>
> Perfectly possible for the last 15 years or so. Assuming Debian and
> MODULES=most, of course.
>
> Reco
>
>
It sounds like I haven't missed anything obvious so I will see if
I can write a perl script or some other text-muncher that will
recreate the grub configuration of the working system but with
the UUID's of the non-working system plus a grub.cfg file exactly
like the grub.cfg file on the system that refuses to boot but
with the correct UUID labels describing the boot partition on
that system plus a copy of the kernel and it's module directory.
As for partition labels, I have always thought the name
was much easier to deal with than the 36 randomly-selected
characters that make up the UUID on a unix partition but UUID
labels are supposed to be unique and are what you encounter today
so I will see if I can make the script modern compatible.
Thanks to you and delop...@gmail.com.
