[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Intresting dd fsck grub uuid fstab action

Your lines are too long.

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.

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.

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".

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.

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.

Reply to: