Prev: pen drive without format and can not find it
Next: Incredibly useful Firefox addon: Hyperwords
From: Stephen Powell on 13 Mar 2010 14:50
On Sat, 13 Mar 2010 00:26:58 -0500 (EST), Paul E Condon wrote:
>
> A bit worrisome to me. UUID must be persistent during normal life of a
> device, so it can be used as an identifier.

It is important to distinguish between a device and a partition.
/dev/hda is a device. /dev/hda1 is a partition. Partitions
can be created, deleted, moved, resized, reformatted, etc. many
times during the life of its containing device. The UUID of a
partition is assigned when the partition is formatted, either with
mkfs or mkswap. It retains this value until it is formatted again,
at which time a new UUID is calculated. I don't know what the
algorithm is for computing a UUID for a hard disk partition.
Of course, reformatting a partition destroys all data on it; so in
that sense it starts a new life with a new identity.

--
.''`. Stephen Powell <zlinuxman(a)wowway.com>
: :' :
`. `'`
`-


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/592907538.18899941268509580061.JavaMail.root(a)md01.wow.synacor.com
From: Freeman on 13 Mar 2010 16:40
On Sat, Mar 13, 2010 at 07:19:13PM +0000, Camale�n wrote:
> On Sat, 13 Mar 2010 00:53:35 -0800, Freeman wrote:
>
> > On Fri, Mar 12, 2010 at 08:16:48PM +0000, Camale�n wrote:
>

>
> > I typo-ed the label for my root partition on my last fstab update but it
> > mounted anyway as rootfs in mtab. So I put rootfs in fstab and it has
> > been working. :-/
>
> Strange behaviour, indeed. Maybe you could had find more information
> about that under /var/log/dmesg :-?
>

Not much in dmesg. Syslog gives me this both before and after I fixed the mistaken
lable for root in fstab:

|Mar 13 12:05:20 Europa laptop-mode: rootfs not found in PARTITIONS.
|Mar 13 12:05:20 Europa laptop-mode: / not found in PARTITIONS.
|Mar 13 12:05:20 Europa laptop-mode: Checking rootfs against HD because
|PARTITIONS contains "auto".
|Mar 13 12:05:20 Europa laptop-mode: Considering /dev/hda.
|Mar 13 12:05:20 Europa laptop-mode: Considering /dev/hdc.

So I'm moving on to trying to a problem with laptop-mode, which I may post
about soon enough.

--
Kind Regards,
Freeman

http://bugs.debian.org/release-critical/


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/20100313213300.GB4942(a)Europa.office
From: Paul E Condon on 13 Mar 2010 18:10
On 20100313_144620, Stephen Powell wrote:
> On Sat, 13 Mar 2010 00:26:58 -0500 (EST), Paul E Condon wrote:
> >
> > A bit worrisome to me. UUID must be persistent during normal life of a
> > device, so it can be used as an identifier.
>
> It is important to distinguish between a device and a partition.
> /dev/hda is a device. /dev/hda1 is a partition. Partitions
> can be created, deleted, moved, resized, reformatted, etc. many
> times during the life of its containing device. The UUID of a
> partition is assigned when the partition is formatted, either with
> mkfs or mkswap. It retains this value until it is formatted again,
> at which time a new UUID is calculated. I don't know what the
> algorithm is for computing a UUID for a hard disk partition.
> Of course, reformatting a partition destroys all data on it; so in
> that sense it starts a new life with a new identity.
>

I'm learning. One thing I discovered today is that in extN, a disk
label (i.e. what you see when you type ls /dev/disk/by-label ) can
have multiple values on a single disk. This label is stored in the
partition table data of the several partitions. I haven't yet
discovered what is done with the excess volume labels, or what, if
any, confusion results from having multiple values. So ... its not
quite true that there is a device and a partition. I know its a
'distinction without a difference', this sort of thing is confusing
when one is trying to figure stuff out from incomplete information.

Also, both mke2fs and tune2fs are capable of setting the UUID of a
partition, either to a software computed value or a user supplied
value. And dumpe2fs -h or tune2fs -l will display the UUID setting
along with other partition parameters.

Some things that I firmly believed a few hours ago, I now know are
absolutely not true. What I will firmly believe a few hours from now
remains to be seen.

Thanks.
--
Paul E Condon
pecondon(a)mesanetworks.net


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/20100313230422.GD2170(a)big.lan.gnu
From: thib on 13 Mar 2010 19:40
Stephen Powell wrote:
> On Sat, 13 Mar 2010 00:26:58 -0500 (EST), Paul E Condon wrote:
>> A bit worrisome to me. UUID must be persistent during normal life of a
>> device, so it can be used as an identifier.
>
> It is important to distinguish between a device and a partition.
> /dev/hda is a device. /dev/hda1 is a partition. Partitions
> can be created, deleted, moved, resized, reformatted, etc. many
> times during the life of its containing device. The UUID of a
> partition is assigned when the partition is formatted, either with
> mkfs or mkswap. It retains this value until it is formatted again,
> at which time a new UUID is calculated. I don't know what the
> algorithm is for computing a UUID for a hard disk partition.
> Of course, reformatting a partition destroys all data on it; so in
> that sense it starts a new life with a new identity.

Yes. Actually, there's even more to consider. GPTs are the future, and
will most probably replace PC/BIOS "DOS" partition tables as soon as it will
be common for the average system to use >2TiB drives (finally). As its name
implies, it introduces GUIDs (global, universal - same thing) for *devices*
and *partitions* (and partition types as well as many other necessary
things, but that's unrelated). Currently, there is no UUID for PC/BIOS
devices or partitions, not even labels.


On top of partitions, there is sometimes a logical volume manager, which
will split the partition (or the whole device if not partitioned) at a
higher level[1] and/or "aggregate" partitions/devices[2], effectively
abstracting the physical boundaries. Physical volumes have another UUID
assigned in their LVM superblock.

<OT>
[1] For extra features like flexible resizing by fragmentation, etc.
[2] To provide redundancy and/or extra performance, or simply to be able to
move the physical blocks (often "extents") from a location to another (live)
without affecting the logical volume as seen by the filesystem (makes the
replacement of a device trivial).

LVMs do *not* manage physical volumes (whole devices or partitions), only
logical volumes on top of them (they just *use* the PVs). Note that raid
managers can be considered as LVMs; they provide special features like
redundancy or performance at the expense of some flexibility (every physical
volume has to have the same size). It's possible to partition raid volumes
(rare) or stack up another (more flexible) logical manager on top of them
(like LVM2).
</OT>

Every logical volume created on top of these physical volumes also have a
UUID, also managed by the LVM. Sometimes there are even two layers
involved, for example a LV on top of a raid array which itself serves as a
base for more flexible LVs, as I just explained. Each layer have its own
superblock containing, among tech-specific metadata, its own UUID.

On top of these logical volumes, we can finally create filesystems.
Filesystems also have a UUID in their own superblock, and that's the one
we're talking about right now.

<OT>
This is *not* a mess, this is the way it should be; every layer is
independent, although filesystems typically fill the entire underlying
logical volume and are thus more tied to them (in terms of size only).
</OT>

So, filesystem UUIDs should NOT be persistent during the life of a device or
partition or physical volume or logical volume; only during their own
lifetime. As long as you don't wipe their superblock, nothing will happen
to their UUIDs - you can shrink and grow them, whatever. If you really need
to reformat them, you can still restore the UUID - there's no black magic
involved, just numbers logically identifying an object.

<OT>
Logical volume managers are currently very tied to the operating system; no
real standard solution exists (except for raid containers), and I'm not sure
if any is needed, although it would allow for pretty cool things. dm/md
raid[1] and/or LVM2 are the preferred implementations for Linux. Many
operating systems (Linux included, Windows excluded, of course) represent
each layer as a virtual device, which makes things really flexible (you can
stack things up any way you want, although many setups obviously won't make
any sense).

To wrap it all up, a quite complete stack looks like this on Linux:

filesystem (extfs, [very long list])
logical volume (LVM2 LV)
logical volume (Device Mapper [dm] RAID vol, Multi-Disk [md] RAID vol)
physical volume (PC/BIOS "DOS" partition, GUID partition, ...)
device (hard disk drive, solid-state drive)

For added confusion, add a loop device anywhere, maybe a little virtual
filesystem on top and a slice of networking. Note that software like EVMS
supposedly helps the management of these stacks, or at least part of them.

[1] One is for "fake-raid" controller management, the other is pure software.
</OT>


- The current situation:

As I already said, until we throw PC/BIOS partition tables away, there is no
standard way to uniquely identify a device. We can only rely on either
their path/location (port), serial number* (not always provided, also
depends on the interface) or contents (partition(s) or a unique filesystem).

*not the same thing as vendor/model ID, which is not unique.

Since we currently can't identify partitions either, we can only rely on
their order (partition number) or contents (filesystem).

Filesystems can be identified by their location (partition/device), UUID,
label or contents.

<debate>
Note that identifying by contents here means file analysis - yeah. Labels
are useful but not always reliable in certain cases:

* Considering you only rely on the filesystem label to determine your root
or boot filesystem, what happens if you boot with a removable device plugged
in containing a filesystem with a label conflicting with another filesystem
label on the device you actually want to boot from? Possible pwnage, I guess.)

UUIDs for filesystems were introduced partly to answer this "problem". This
is the only three-nines reliable way. Labels are just there for convenience
(and they are very useful at that), and as the hardware layer is beeing more
and more abstracted, identifying by path or basically any underlying layer
is less and less feasible. That's just a fact: filesystems can be
completely detached from the devices.

In the future, we should be able to reliably specify on which unique
device/partition/LV the filesystem is supposed to be, for extra fun (and more).

In fact, the future could be now, I'm just talking about general trends;
GPTs can be setup very cleanly even on non-EFI hardware - except on Windows*
and for no apparent reason, of course (sigh).

<OT>
*since GPTs are backward compatible, it's possible to setup a hybrid
configuration and thus still be able to dual-boot it. It's kludgy.
</OT>
</debate>


- The problem:

?


Sorry for the many off-topic blocks, I felt like it could clarify my words,
putting them in some context. Hopefully it's informative for someone.
Please correct me if you don't like my understanding of these things; but
really I see no problem.

-thib


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/4B9C2FBD.6070904(a)stammed.net
From: Tzafrir Cohen on 14 Mar 2010 10:30
On Sat, Mar 13, 2010 at 11:13:14AM -0500, Tom H wrote:
> > When I install a 2nd/3rd distrib on a HD, I have made it a practice
> > to set up fstab so the existing distrib are mounted automatically.
> > Repeated use leads to all functioning distrib to be crosslinked.
> > But when a distrib must be reinstalled because something drasticly
> > wrong happened, or whatever, access to that replacement distrib in
> > all the older distrib is broken because the UUID of the partition
> > is changed.
>
> You could make a note of the UUID before the re-install then re-apply
> it to the partition with
> tune2fs -U <uuid> /dev/sdaX

However you *must* take a note. This is not something you can remember.
As opposed to a partitioning scheme, that you can remember.

UUIDs are also a fine method for making your life interesting when you
want to recover a system backed up on a different hardware.

For instance, I had a digikam images database on a system whose
motherboard had some issues. No problems. I copied the whole thing to a
new home directory (of the same user, same UID, same path) on a
different system. However digikam fails to use the database. It insists
I have the incorrect UUID. Natually it does not allow me to fix things.

This is intended to protect against using the wrong DoK (but will
"protect" you from copying the database to a different DoK). And
couldn't have been disabled from the user interface at the time.

It took me a few hours of digging in the code and file format to figure
out how to fake a non-UUID database.


So make sure you don't have the UUID listed in a host of places on the
disk when recovering the system to a different media. {Or|And} just try
to avoid it, if you can.

--
Tzafrir Cohen | tzafrir(a)jabber.org | VIM is
http://tzafrir.org.il | | a Mutt's
tzafrir(a)cohens.org.il | | best
ICQ# 16849754 | | friend


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/20100314142054.GG16560(a)pear.tzafrir.org.il
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: pen drive without format and can not find it
Next: Incredibly useful Firefox addon: Hyperwords