Re: A Grub Boot Question about initrd
Martin McCormick composed on 2021-06-05 12:46 (UTC-0500):
> I have a plan but I need some more information. Is there any
> personalization done by the boot setup process? Do our UUID's
> or any other specific information pertaining to the installation
> make it in to the initrd files?
Dracut includes a root=UUID=<UUID> statement in the initrd. A root= statement on
the Grub linu* line overrides it. The override can be any of the accepted forms,
including root=LABEL= and root=<device name>.
> While reading about the boot process, it doesn't appear
> that the initrd files or initranfs are personalized with anything
> pertaining to this computer and this installation.
As already answered, it may be either modules specific to the hardware, or a more
global supply of modules, according to the machine's configuration files.
> 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.
Specific processor type isn't relevant among x86 or amd64 classes. It's the I/O
hardware that matters.
> 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.
The translation is easy. UUIDs are assigned to devices. The device names are
acceptable substitutes, just as they used to be the only option before libata made
device names capable of playing musical chairs. If devices also have labels,
labels can be used instead of device names.
> If the target system actually boots, it is probably a
> good idea to run update-grub to make sure that still produces a
> working boot but this would still more than likely produce the
> same results if this process works in the first place. It's also
> possible that the reconstructed grub setup is okay except for the
> drive designation which usually starts out as /dev/sda1. On my
> good Buster system, this is now /dev/sdc1 and on the sick one,
> the attempt is being made on /dev/sda1.
UUIDs were designed for computer scripts, not human brains. You'll need to make a
conversion, but instead of UUIDs, I highly recommend using labels when you know
device names will be different on the system migrated to. UUIDs are appropriate
too, just rather unwieldy unless scripted.
> The idea here is to copy the concept of what is happening
> rather than the literal configurations which definitely will
> never work unless one used dd to generate the clone drive and I
> have actually done that once and it worked but the cloned system
> was then adapted for other uses. Here, all I want to do is
> rescue the boot process so it lives on and not have to reinstall
> everything else.
Grub provides a shell. From the shell it's possible to boot using the information
you have. Instead of trying to figure it all out in advance, drop to the shell and
use the device names you know. It's really not hard if you have a copy of a grub
menu from the two PCs planted in your brain or on paper. Once you've booted, it's
easy to fix everything up by running grub-mkconfig, and if necessary,
/etc/default/grub.
> 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. The grub configurations of both are
> the same down to the serial console.
Don't let the massive volume of data in grub.cfg mislead you. Its primary job is
to find and load a kernel and initrd. If you know where they are and their names,
none of the menu components or apparent search and identification bloat are
necessary. Before Grub2 you could simply tell Grub's shell the root device, the
kernel name (with associated parameters, most of which aren't actually necessary),
and the initrd name, then boot. With Grub2 you may need to precede the root device
name with loading a module or two or three, which you see in your copy of a
grub.cfg, then proceed with the important three. I do a lot of cloning, so I've
done it often.
--
Evolution as taught in public schools is, like religion,
based on faith, not based on science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata
Reply to: