On Thu 25 May 2017 at 16:41:37 (-0400), Fungi4All wrote: > 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.
… and I get the impression that that's exactly what you did: 1 dd 2a "log in sda5" (is that mount, or boot?) 2b edit an fstab file (to what purpose, at this point?) 3 run update-grub Assuming that your copies are good, and that the apparent "alterations" to sda… arise from misunderstanding or misinterpreting UUIDs (or that they actually post-date your running update-grub), then your problems arise from one or both of: Booting into sda5 with both devices sda and sdb connected, Running update-grub with both devices sda and sdb connected. > > 1 - Does dd leave uuid targets as they are, does it create new ones, or > > does it copy uuid from source to target? I assume that's your reporting of step 1. > > 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. Is that "log in"? What did you correct in fstab? What was wrong? Is sda the same disk as it was when you ran dd? There's no reason why it should be if the kernel races to label them sda and sdb. How did you check? Why does a system suddenly run an fsck? > > 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 .... Yes. I would expect grub to be completely confused about what to write in …wherever/grub/grub.cfg and possibly have no idea which MBR it related to, with two disks present. > 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. This makes me wonder whether you've taken on board Pascal's comments re different types of UUIDs. And when did fsck start handing out UUIDs to filesystems, let alone devices. > > 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. And we're left guessing what the contents are. Do remind me, what is msdos3 here? > > 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? No idea. Again, we don't know what you've written where, when you say "switched to all new uuids to clear up the mess". And what's the "second installation"? What are you calling an entry, and a menu entry? > 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. Well, that depends on whether you install it or just configure it. When you generate a new grub.cfg file, grub collects bits and pieces from the grub.cfg files it finds on the various partitions it guesses are linux systems. This new grub.cfg will normally be written in whatever filesystem contains /boot/grub/. However, that's not necessarily the grub.cfg that was read and acted upon when you just booted, nor necessarily the grub.cfg that will be active when you next boot. You can demonstrate this to yourself by adding a word, say, to one of the id strings. A grub-install, the one that writes typically to the MBR, will make future boots read the new configuration file. Thus, if you maintain a backup linux installation on your machine, and the kernel is updated on the backup, the new grub.cfg that is then configured will have no direct effect on booting. However, if your backup system gets an update of its grub package, that will write a new boot image, and now the backup's grub.cfg will be the active one on next booting. > [various complaints] I think this is grub's fault. I'm not sure blaming grub will help you straighten out your system. I only hope that one of your disks still carries a suitable clone of the other. Cheers, David.
