Re: Intresting dd fsck grub uuid fstab action
From: deblis@lionunicorn.co.uk
I'm not going to wade through all these imaginings again; sorry.
Just some points.
Your use of the term imaginings emphasizes clearly how you do not
reas but "assume" that this all mighty perfect system can't be at fault
and it all lies in my mistakes, without ever referring on what should
have been done and didn't.
>> 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.
You are focusing on grub out of context. You ask one clarification,
you get it and you keep IMAGINING things because you did not read.
And you waste my time repeating everything again and again.
If you read previous posts I have stated clearly three times at least,
that I did not edit fstab from "the live" kernel of the systems mentioned
but by "another" system. You want me to be specific? I used a debian
system installed on a usb-stick. to edit the fstab on both debian
installations. Does it matter? Even if dos5.0 would give access to
an ext4 disk I could edit fstab and grub.cfg from there. Why bother
with a live kernel on a system that wouldn't boot.
Whatever system started and booted the system its live identification
of partitions and UUIDs were very accurate at any given time. Those
transferred to fstab and a reboot was an attempt for them to boot correctly.
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.
I have described the process in extemely boring detail, you both
fail to read and try to force situations that never existed.
I DID NOT TRY TO COPY A LIVE SYSTEM, it was DEAD! This was
very clear to anyone who bothers and can read basic english.
I did not expect a system that is functional and running well, it is then
shutdown then a "different" system is used to copy it and then
edit the fstab of the COPY to match the uuids on the system.
> 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).
Does it duplicate uuids or doesn't it? Does it do it consistently or does
it sometimes it leaves the uuid as it was and sometimes it duplicated one?
WHY???? Because not all changed, or were duplicated, it was a mismatch.
I understand swap because it wasn't copied, but the other 4 3 had new ids
and one had a duplicate. I say I understand that dd made all duplicates and
fsck only assigned new uuids to partitions that were realigned, covering
the 1MB gap that was left by gparted.
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.
You are trying to draw pictures and I have no clue what your intentions are.
Are you offended because you wrote the code for dd and grub? I have been
doing this long enough to recognize an irregular behavior. If you are trying
to figure out what the problem is don't refer to me anymore because I
said over and over again I fixed the unreasonably complex mess that was
created especially by having to edit grub.cfg as automatically it kept configuring
itsled WRONG!!!! Both installations were perfect, 10 unique UUIDs and
responding fstabs. Grub would update and mix two systems. All I changed was
the second like of the entry to the correct ID and both systems worked
flawlessly (eventually).
David.
Over and out!
Reply to: