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.
