From: Tom H on
>> I believe a UUID is generated when the partition is "formatted", either
>> with
>> mkfs or mkswap.

> I confirm - just tried shrinking and growing back an extfs. UUID is left
> untouched (as expected); that Mint article is BS or just obsolete.

I have never come across the problem described by the Mint link.

The closest is having swap's UUID change when installing a 2nd/3rd
distrib on the same HD.

Someone said earlier

"I can't imagine any case where an filesystem UUID change "by the
face", I think this is not possible if you didn't execute any
filesystem command to do it."

and cannot but +1 the comment because the UUID is held in a
partition's superblock.


--
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/6d4219cc1003130653j51248695h184ee5aa14cf01b(a)mail.gmail.com
From: Paul E Condon on
On 20100313_095320, Tom H wrote:
> >> I believe a UUID is generated when the partition is "formatted", either
> >> with
> >> mkfs or mkswap.
>
> > I confirm - just tried shrinking and growing back an extfs. UUID is left
> > untouched (as expected); that Mint article is BS or just obsolete.
>
> I have never come across the problem described by the Mint link.

I have seen a UUID change in a way that disrupts my work:

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.

This is not a killer objection for me. But it is a use case expample
that belies some broad claims about UUIDs.

If there were a place on every partition where a UUID of the partition
could be recorded, and if the partitioning software could be trained
to preserve that record whenever the partition is simply wiped in
preparation for a reinstall, then ... maybe this use case would behave
more to my liking. But I am aware that there are a lot of individual
requirements for partition identifiers, so I hesitate to advocate
this proposal in this most simple form. As I say, I understand enough
about the scheme that I think I can live with it in its current form.

Also. There seems not to be a standard algorithm for computing UUID
bit strings. Different developer/users of UUID ideas seem to be free
to choose what algorithm and what input data they use to get their
UUIDs. So, the actual behavior of UUID technology in Debian may change
over time. Future versions of Debian may silently change to address
old problems (and to introduce new problems).

>
> The closest is having swap's UUID change when installing a 2nd/3rd
> distrib on the same HD.
>
> Someone said earlier
>
> "I can't imagine any case where an filesystem UUID change "by the
> face", I think this is not possible if you didn't execute any
> filesystem command to do it."
>
> and cannot but +1 the comment because the UUID is held in a
> partition's superblock.
>

My original post has generated a lot of very interesting discussion.
UUIDs are no longer so mysterious. I think that there is more work to
be done, but I have no good ideas to pursue and I have reached my
attention span limit. I don't want to post with a subject line
"Solved", but it is true that I want to stop discussing this.

Thanks to all.

--
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/20100313160128.GB2170(a)big.lan.gnu
From: Tom H on
> 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


--
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/6d4219cc1003130813w71928edchaf1c308015fd9928(a)mail.gmail.com
From: Paul E Condon on
On 20100313_111314, 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

I keep learning stuff. I think this, which is verifiably true, contradicts
some other things that I remember (and had thought were verifiably true).
Thanks for this knowledge which is definitely new to me. It will take me
sometime to integrate it into my belief system, but 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/20100313183152.GC2170(a)big.lan.gnu
From: Camaleón on
On Sat, 13 Mar 2010 00:53:35 -0800, Freeman wrote:

> On Fri, Mar 12, 2010 at 08:16:48PM +0000, Camaleón wrote:

(...)

>> Well, that said I like Lenny still uses the old scheme "/dev/sdx". At
>> least if it changes, I still understand it better than the new udev
>> naming :-)
>>
>>
> I've been changing to labels with squeeze. The up side: it is a hard
> designation and can be made unique.
>
> The collisions part is unclear to me. If one plugs into USB a drive from
> another machine, won't that just be listed in /dev by sdx, at which
> point it can have its fstab edited?

USB devices usually auto-fall under /media and do not need to be added
in /etc/fstab, unless you want to use them as permanent mount points.

But if the USB hard drive already has a label, and that label shares its
name with another mounted device, it will generate a "collision". Nothing
serious, I guess that when you plugged the USB drive it would have told
you something like "mount point '/media/mylabel' already exists" and
aborts.

I mean, the success of mounting a device "by label" will depend on
whether the user knows before hand if the device:

a) Already has a label defined
b) What is that label to prevent collisions with other devices

So, in order to avoid that, distribution installers defaults to either
UUID and/or ID for use it in /etc/fstab which tends to be a more secure
approach.

> 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 :-?

Greetings,

--
Camaleón


--
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/pan.2010.03.13.19.19.12(a)gmail.com