Re: drive names and UUIDs, was Re: Intresting dd fsck grub uuid fstab action
On Sat 03 Jun 2017 at 11:02:54 (-0400), Fungi4All wrote:
> Ι was waiting to see if anyone else found something like this significant and willing to contribute some wisdom
No wisdom here, I'm afraid.
> I suspect the experiment would be simple.
> Let's say we make a new partition on a disk with a debian installed system and use dd to clone that system in
> the new partition (I have no idea whether doing this in the same disk or a second one makes a difference),
> Let's say that dd copies uuid to the new partition so we have two partitions with the same uuid in the same system.
> Intentionally we make the mistake and log in to the original system and update-grub with the conflict.
AIUI there's a race condition here, perhaps even several. The correct
MBR should be read as normal by the BIOS, but grub then searches
by UUID for the kernel/ramdisk, and the kernel searches by UUID for
the root filesystem, and we don't know how it chooses between them.
Do they (a) take the UUID being searched for and look at each disk/
partition's UUID for a match, or (b) read all the available UUIDs into
a table (overwriting any duplicates by the new entry) and then take
the UUID being searched for and look it up in the table? These
strategies give opposite results.
> Then relogin and create new uuids for the clone, edit ftstab and check original, then update-grub.
> Will it boot having the first root or the clone root? Then look at grub.cfg of the original to see if the uuids for each
> entry are matching or there is a mismatch.
> I went through the grub manual and didn't come up with an answer. It smells like a tiny bug or room for improvement.
I think you'd have to study both grub and the kernel's code to
find an answer, and their developers would say "Just don't do it,
it's not defined, it may change tomorrow".
> Also, I believe that when dd is used to copy something from disk to disk it should provide an option of whether to
> produce a new uuid or retain the original (backup, not a concurrent system).
Here you're asking for the impossible. dd is blind to what it's
copying at that level. It can fiddle with something it calls "records"
(which stinks of IBM FB↔VB conversion) and that's about it.
For copying filesystems around, there are commands for doing that.
Years ago I used cpio -vdamp but I've seen better commands (cp -a ?)
in threads here more recently. These have the advantage that you
prepare the empty filesystem the way you want it before you copy
into it.
Cheers,
David.
Reply to: