Re: Intresting dd fsck grub uuid fstab action
I'm not going to wade through all these imaginings again; sorry.
Just some points.
On Mon 29 May 2017 at 15:56:52 (-0400), Fungi4All wrote:
>> How would I know which fstab you edited? […]
>> IOW how did you decide which disk the kernel had decided to call sda?
>> How did you tell which was the original and which was the identical copy?
>
> Because the source was on hd0 (physical unit) to target hd1,
> I suspect grub does not worry much about sda/sdb label
> but according to bios knows the master and slave.
What does grub have to do with it. By the time you edited fstab,
the linux kernel was running, sda and sdb are indeterminate, and
choices have been made between duplicate UUIDs.
> Well, that was my initial question. I could understand something
> going bad with the copy but not the source. The only logic is that
> the fsck asked to replace the uuids and I said "y" and it did.
You see, you've decided on what to blame and make up anything to
justify it.
> OK, since you blame every single bit of it in what I did
I'm trying to explain what may have happened under the circumstances
that you have presented us with. You are the one trying to apportion
blame, and you've decided on fsck and grub.
> why don't you
> tell me what are the correct steps for doing exactly what I wanted to
> do, copy an installation on an other hard disk and having it boot by
> the same original grub that handled all other systems.
> Because I am clueless at this point on what I exactly I did wrong and
> why such a simple procedure becomes so enormous source of problems.
Assuming you want to avoid the issues involved with cloning an
active root filesystem, close down your A system and boot up a
system on a stick.
Copy the partitions from A to B.
Check for errors. /var/log/kern/log is worth inspecting.
Use tune2fs -U random /dev/sdbN to assign new UUIDs to the
copied filesystems.
If you've copied a swap partition, mkswap /dev/sdbN will create
a new UUID by default.
You can now reboot into your A system as per usual.
Assuming you want to make the copied partitions available when
the A system is running, edit A's fstab to add mountpoints for
your new partitions, then mount -a.
> Also please explain the logic of the developer of dd in "copying and transfering"
> a UUID that is supposedly meant to be unique. Why not always asign a new
> one every time? Because it is meant for backup work and not for copying?
dd doesn't know what a filesystem is, or what a UUID is. It just
copies what you tell it to (or converts it in specific ways).
A dollar bill has a unique serial number. If you make a perfect copy,
it is no longer unique. The copyist doesn't change the number.
Neither does dd.
> I am telling you over and over again, I had no clue and never in my
> experience had I realise that dd "sometimes" does this. Not consistent!
> I discovered this in practice and "fixed it", by using gparted and making
> new uuids for anything duplicate (which I believe only happened in 2
> out of 5 partitions). That is when I fixed the fstabs and then booted
> sda5 and asked it update its grub. Then the problem became one of
> grub alone. I don't know how else can I explain it. If I say I do this
> in step 4 you tell me I shouldn't because there was a problem in step2
> I tell you what I did to fix it to get to 4 you tell me what I did in 2
> caused 4.
The steps you described as doing in the order given were effectively
like trying to make a poached egg out of an egg you'd already scrambled.
> It shouldn't take 5hours of guessing to copy a 5gb system from one
> disk to the next and expect to be able to run both in the next hour
> or so. This is rediculusly complex and inconsistent. Why so much
> redundancy? And this Uuid thing has got me thinking in ways that
> I didn't before. Why within a single system (not a WAN) does uniqueness
> has to be in the order of trillions and trillions?
You obviously don't understand the purpose of using UUIDs.
They solve the problem of creating a label for something (a
partition or a filesystem in your case) which is unique¹, but
without needing reference to anything else; no looking anything
up or checking anywhere.
Imagine you wanted to open an account with a bank, and they said
"Fine, give us the account number." You could run
$ dbus-uuidgen
7df4b93e13b8374cd491b440592cf5d8
$
and give them that. Nobody else will have this number for
their bank account, anywhere. If several banks merge, their
customers' account numbers will all remain distinct.
¹to all intents and purposes.
Cheers,
David.
Reply to: