-------- Original Message -------- Subject: Re: Intresting dd fsck grub uuid fstab action UTC Time: May 25, 2017 8:57 AM From: pas...@plouf.fr.eu.org
Your lines are too long. I didn't know that was a problem, I've learned to write and only hit return on --> a paragraph. Le 25/05/2017 à 05:11, Fungi4All a écrit : > I experimented in switching a clone of my sid installation to an > experimental, that was the plan. > Since I was doing other things I thought I'll let the cloning take place > unattended. > Let's say sda5/6/7/8/9 were to be cloned to sdb5-9 (5 / 6 var 7 sw 8 tmp 9 > home) all b partitions were slightly larger. > I used dd bs=1M for each one and though all I had to do is log in sda5 edit > the sdb5 fstab and then update-grub. > > 1 - Does dd leave uuid targets as they are, does it create new ones, or does > it copy uuid from source to target? dd does not care about UUID or any other metadata. It just copies every bit of data. Filesystem UUIDs and labels are part of the data, so are cloned verbatim if you clone the partition. Partition UUIDs and labels (mostly used on GPT partition tables) are part of the whole disk data, so if you clone the whole disk, you also clone the partition UUIDs and labels. I didn't know this, I thought uuids are only created during partition creation and are not part of the partition's contents. I've used dd for backup several times but in temporaty mediums, not within the system. I rarely have two drives in one box. I didn't copy the whole disk, just specific partitions of the one disk into similar ones on the 2nd. > 2 - When I rebooted sda5 was not booting up properly. Eventually I checked its fstab and corrected it but at this poing the system run an fsck and I got some errors and hit y,y,y,y, for fixing. I don't know if the errors came from uuids existing in the system twice. Did you clone the partition while it was mounted and used ? Then you cloned a filesystem in a dirty state, no wonder why fsck found errors. No, I'd never do that, but I did once trying to clone a live copy of a system on top of a mininmal debian installation. That tought me not to copy dev and media while they are alive, becuase that may incoprporate all the mounted disks :) No I used a different system on a different partition to copy a parked debian sid. > 3 - Updating grub seemed to have made a bigger mess as now I could boot up but the partitions were mixed up between sda and sdb parts. It would boot-up on root / of sda and have a home in sdb9 .... If the cloned disk is intended to be used in the same machine as the original one, you should change all identifiers, UUIDs and labels, otherwise GRUB and libblkid will be confused with duplicates. One "U" in UUID stands for "unique". I know, it is in trillions or more a chance of creating two of the same in a life time. The first thing I did after dd was done, was to make a txt table of all the sda* sdb* in order with uuids and rewrote the fstab on sdb, I thought the sda would be as it was. But wasn't. It wasn't all uuids that transfered but seem enough for me not to notice they were the same and for sda5 to boot up and discover the discrepancy. I speculate that fsck then instead of giving sdb a new uuid it altered sda. By the time the check was done and I run grub-upd some of the uuid in grub belonged to sda partitions and some on sdb. By copying from sda to sdb I never thought the original would be affected, only the target needed fixing. That threw me off. But on the new grub.cfg both entried would boot from the sda but with remaining partitions being a mismatch. > 4 - Eventually to stay safe I booted from live usb and edited all the partitions, gave them separate labels to avoid any confusion (as "Deb on Sda6 var..."_) and switched to all new uuids to clear up the mess. Re-edited fstab on bot sda and sdb (hd0 and hd1 dos5) and rebooted sda and updated-grub again. By default update-grub uses only filesystem UUIDs, not labels. So even if you change labels, if multiple filesystem have the same UUID, any of them may be selected. You missed the point. Here are some lines as an example if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos3 --hint-efi=hd0,msdos3 --hint-baremetal=ahci0,msdos3 --hint='hd0,msdos3' UUID on sda3 XXX else search --no-floppy --fs-uuid --set=root UUID on sda3 YYY fi insmod png On a correct grub both of those uuids are the same. I ended up with two different ones without editing grub.cfg I discovered this after I had made sure that all UUIDs are unique and both fstab files were correct. I updated grub and it would still only boot sda on the sdb entry. The entry label itself would say Debian on sdb5 and it would boot on sda5. That made me think of looking at grub. I replaced the mismatched uuids manually and it booted like A1 > 5 - Here is the unexplained part: My sda5 system booted up fine and normal, > when I would try sdb5 the second line would say debian clean on sda5!!! > So I went into grub.cfg to see what is going on. On the menu entry of the > second installation the first line of each entry would have the proper sdb5 > uuid, the following line - which I believe is the actual command - had the > uuid from sda5. So, am I to assume that grub when it updates only replaces > the first line of each entry expecting the next uuid will be the same, even > if it is not? When creating menu entries for another Linux system, update-grub copies the contents from grub.cfg of the other Linux system, if it exists. So check that grub.cfg on sdb has beed updated properly. I don't use grub on sdb, I only use it on sda (not sda5) but sda5 is managing grub for all partitions. As far as I understand bios reads the MBR and the MBR tells it to go and read the cfg. from /sda5/boot/grub/grub.cfg in what to do. I know if I boot up something on sda12 and install or reconfigure grub in there then 12 will take control of booting all other bootable partitions in the system. I can rename I think the boot/grub copy in sdb5 into deadgrub and it will not affect anything. Now, why on an everything fixed system update grub will end up having on the same 1 entry the above first line with uuid from sdb5 and a second line the uuid from sda5 I think this is grub's fault. When I edited manually all the correct uuids both systems booted up and had the other's partitions as mountable but not mounted. On each system I only have the system and home partitions in the fstab, everything else is mounted optionally with sudo priviledges. Unless I use the mounted volumes I unmount them. That is my routine practice. (AK)
