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

Intresting dd fsck grub uuid fstab action

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

So I got it all fixed, not much to see in the experimental part for my interest except some kernels 4.10 and 4.11, but the puzzle is not solved.  Where exactly did I go wrong?   I'm just proud of myself for fixing it, but could there be a bug somewhere?  For a minute or two I thought maybe grub was falsely detecting some kind of raid action between the two drives and mirror partitions, but I have no raid (intentionally).

Feel free to replicate the mess and I learned to hate gparted for taking so damn long from each operation to the next.


Reply to: