Re: drive names and UUIDs, was Re: Intresting dd fsck grub uuid fstab action
From: deblis@lionunicorn.co.uk
> Ι was waiting to see if anyone else found something like this significant and willing to contribute some wisdom
No wisdom here, I'm afraid.
just evolution of the unix-dna
> 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.
I think this bit of info gets one level deeper to source of problems.
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.
I suspect at some point, when 2 matching uuids come up for different
disks or parts of the same disk, the partition is left out as unmountable.
In my case it would mix and match the partitions of one system with
some from its clone. How do I know this? I had labeled the partitions
as their sda/sdb numbers and the system booted with 5 partitions
showing me the mix match as unmounted and when I'd attempt to mount
them it would say no no.
> 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".
if time=23:59 do yesterday :)
> 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.
I actually like dd the more I learn about it but what I was suggesting was to have
an option to change the uuid to a new random one after it is done copying.
I understand (think) that dd does not even care about the format of the fs it copies
or that of what it copies to, just blocks of space, where to start and where to finish.
So if a 10gb NTFS partition is copied to a 20gb EXT4 partition, the target will be an
ntfs 20gb partition. So I suspect it does formatting in there too, otherwise the
partition would have been left half ntfs half ext4.
The kernel I assume as soon as dd is done picks up the new set of uuids and
updates the table. So if dd does not do it it leaves the system in a mesh.
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.
I thought that dd is more accurate and quicker with the exception of little
data in a huge partition, where it copies a huge amount of empty space.
Cheers,
David.
cheers back
Reply to: