From: deb...@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
