drive names and UUIDs, was Re: Intresting dd fsck grub uuid fstab action
Fungi4All-san,
I'll try explaining what we don't know whether you understand or not.
First, about
/dev/sda
/dev/sdb
...
When you turn the machine on, these "names" do not exist. Well, at
least, the computer does not know which physical device is /dev/sda
and which is /dev/sdb, etc.
When the BIOS is finding hard disks and other disk-like persistent
storage devices right after you turn the computer on, it remembers them
in the order it finds them. That means that, if one device finishes
powering up before another, it is likely to have a lower device name.
But even that is a probability, not a guarantee, because BIOS is
generally not looking at each device at the exact moment it powers up.
Because of this, /dev/sda may be your boot drive one time, and may be
your backup drive another time. Or, if you have multiple boot drives, it
may be your MSWIndows boot drive one time and your debian boot
drive the next, etc.
You want to think it should be more simple, but it's not. And it's not your
fault, and it's not Debian's fault. (Who's fault? Microsoft, Intel, Apple,
Maxtor, Seagate, Commodore, Atari, Radio Shack, IBM, DEC,
Honeywell, ..., pretty much all the companies involved.)
Why can't the drive itself just say it's /dev/sda? Well, what happens
when you go to the store and need a /dev/sdc, but all the drives in stock
are named /dev/sdb?
Labels of various sorts were tried, but when labels tended to be too
simply done, like "accounting" instead of something like "ACTG20170601".
So UUIDs were invented as a new sort of label that would theoretically
never be duplicated. They are separate from the labels that the are
called labels in /etc/fstab and gparted's listing, etc.
This explanation is too simple, but close enough to what's happening
to explain what we thing has happened to your drives.
UUIDs or other kinds of labels, where are they stored?
In the storage area of the drive itself, along with the MBR, the partition
information, the file system information, and the program and data files.
That means that, when you use dd to duplicate your storage device,
even the UUID is duplicated.
Now, it turns out that it's convenient to label or name partitions/volumes
within the device, and UUIDs are now generally assigned to each
partition/volume. These are different UUIDs, and they are also stored
on the disk itself. So when you dd a parition/volume, you copy the
UUID for that partition/volume, too.
And when you dd the whole device, you copy all the UUIDs on every
partition/volume on the device.
In order to have both the duplicate and the original connected to the
computer at the same time, you have to figure out a way it can tell
them apart.
The easiest way is to first change the UUID for the new device, and
then the UUIDs for each partition/volume, as well. and then edit
/etc/fstab on the new device to point to the changed UUIDs. You can do
this with an install CD or a live OS on a USB, etc.
You can't do it easily by booting either the new or old device, even if
you boot a different OS on either the new or old device.
It can be done,by giving the necessary volumes and the device itself
labels (that are not UUIDs) and changing /etc/fstab on the device that
will be booted to use labels instead of UUIDs.
Anything you changed before you changed either the UUIDs or labels,
edited /etc/fstab to use the new ones, and rebooted, you really don't
know which drive you did it to.
Running fsck before you take care of that could be really dangerous.
If you read through this and understand it, and can tell us what you did
in a way that we can tell you understand this, we can continue to try to
help.
--
Joel Rees
delusions of being a novelist:
http://joel-rees-economics.blogspot.com/2017/01/soc500-00-00-toc.html
Reply to: