11:35 p.m.
Has anybody noticed that F9-pre installer creates an /etc/fstab file
based on UUIDs instead of LABELs? I seem to remember everybody all
worked up about LABELs instead of the traditional /dev/sda2 type
identifiers, in order to simplify changes to hard drive configuration.
But now, all of a sudden I've got this 32-character long UUID that makes
everything complicated again.
Granted, I understand that a UUID is just as good as a LABEL, as far as
functionality goes, but LABELs are so much easier to read, compare, and
type. Why would the F9 installer choose to create UUIDs instead of
readable LABELs? I have no idea.
Rainman
11:45 p.m.
On Wed, Apr 30, 2008 at 12:35:41AM -0400, Christopher L Tubbs II wrote:
Granted, I understand that a UUID is just as good as a LABEL, as far
as
functionality goes, but LABELs are so much easier to read, compare, and
type. Why would the F9 installer choose to create UUIDs instead of readable
LABELs? I have no idea.
UUIDs are unique. LABELs may not be.
11:58 p.m.
On Wed, Apr 30, 2008 at 12:35:41AM -0400, Christopher L Tubbs II wrote:
Has anybody noticed that F9-pre installer creates an /etc/fstab file
based on
UUIDs instead of LABELs? I seem to remember everybody all worked up about
LABELs instead of the traditional /dev/sda2 type identifiers, in order to
simplify changes to hard drive configuration. But now, all of a sudden I've got
this 32-character long UUID that makes everything complicated again.
This was discussed awhile back on the list. Take a quick look through
the archives--probably last month.
There are reasons for it. Whether they're really good reasons or not is
beyond my knowledge, so I made no comments.
--
Scott Robbins
PGP keyID EB3467D6
( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 )
gpg --keyserver pgp.mit.edu --recv-keys EB3467D6
Maggie Walsh: We use the latest in scientific technology
and state-of-the-art weaponry, and you, if I understand correctly,
poke them with a sharp stick.
12:40 a.m.
Chuck Anderson wrote:
On Wed, Apr 30, 2008 at 12:35:41AM -0400, Christopher L Tubbs II
wrote:
> Granted, I understand that a UUID is just as good as a LABEL, as far as
> functionality goes, but LABELs are so much easier to read, compare, and
> type. Why would the F9 installer choose to create UUIDs instead of readable
> LABELs? I have no idea.
UUIDs are unique. LABELs may not be.
This is precisely the reason, because the realization has hit people that a
system may have many linux distros installed on it, so labels made by other
distros for '/' are not unique; at the same time the device names are no longer
guaranteed to be in any particular ordering when some devices come and go
(hotswapped drives especially). UUIDs are the identifier that won't get mixed
up or changed.
--
Andrew Farris <lordmorgul(a)gmail.com> www.lordmorgul.net
gpg 0x8300BF29 fingerprint 071D FFE0 4CBC 13FC 7DEB 5BD5 5F89 8E1B 8300 BF29
1:39 a.m.
Andrew Farris wrote:
Chuck Anderson wrote:
> On Wed, Apr 30, 2008 at 12:35:41AM -0400, Christopher L Tubbs II wrote:
>> Granted, I understand that a UUID is just as good as a LABEL, as far
>> as functionality goes, but LABELs are so much easier to read,
>> compare, and type. Why would the F9 installer choose to create UUIDs
>> instead of readable LABELs? I have no idea.
>
> UUIDs are unique. LABELs may not be.
This is precisely the reason, because the realization has hit people
that a system may have many linux distros installed on it, so labels
made by other distros for '/' are not unique; at the same time the
device names are no longer guaranteed to be in any particular ordering
when some devices come and go (hotswapped drives especially). UUIDs are
the identifier that won't get mixed up or changed.
I suppose the rare situation with many linux distros on one computer may
cause issue, but personally, I'd have preferred the partitioning utility
in the installer to offer the option to set/view labels instead (perhaps
next to the option to generate a UUID for the partition?)...
After all, the partitioning tool in the installer needs more features
anyway: such as being able to set boot flags (useful for dual boot
systems that don't put grub in MBR). It could also support explicitly
positioned partitions: currently, it orders you're partitions for you,
but who says I want boot partition placed before root partition or free
space? (This issue came up for me recently, when I found I was unable to
reserve space at the beginning of the drive for a Dell utility
partition: I don't remember the specifics but I ended up booting Knoppix
and used gparted before running F9 installer).
Rainman
3:07 a.m.
Scott Robbins wrote:
On Wed, Apr 30, 2008 at 12:35:41AM -0400, Christopher L Tubbs II
wrote:
> Has anybody noticed that F9-pre installer creates an /etc/fstab file based on
> UUIDs instead of LABELs? I seem to remember everybody all worked up about
> LABELs instead of the traditional /dev/sda2 type identifiers, in order to
> simplify changes to hard drive configuration. But now, all of a sudden I've got
> this 32-character long UUID that makes everything complicated again.
>
This was discussed awhile back on the list. Take a quick look through
the archives--probably last month.
I think there's been discussion on the anaconda list too.
There are reasons for it. Whether they're really good reasons or not is
beyond my knowledge, so I made no comments.
Labels are inherently broken, as others have noted. At one time, on one
system, I was multibooting two RHEL betas, opensuse 10, sles10 and
Fedora Core 6.
SCSI disks tend to change their names too, depending on the order
they're recognised and (maybe) whether they're hotplugged.
I discovered my HP DC7700 got thoroughly confused about its disks when I
added a second SATA drive; the BIOS tried to boot the wrong drive. I
don't know whether it was me, the BIOS or the documents, I just shuffled
cables to positions that worked.
I don't much liked UUIDs either (I had problems duplicating disks when
RH introduced labels) and UUIDs don't solve the problems I had. And they
may introduce new problems: try cloning a disk thus:
fdisk -l /dev/sda
fdisk /dev/sdb # create a suitable new partition layout
mke2fs /dev/sdb1 # etc
mount ...
tar clC <source mount> . | tar xpC <target mount>
etc
If the intent is to clone the system on sda, then the partitions on sdb
have different UUIDs (as they should) and the fstab needs to be updated.
If, as is possible with a little fiddling, one copies with dd, then the
UUIDs are duplicated, and if one then reboots _I_ don't know which gets
mounted, but it's likely it's the wrong one!
--
Cheers
John
-- spambait
1aaaaaaa(a)coco.merseine.nu Z1aaaaaaa(a)coco.merseine.nu
-- Advice
http://webfoot.com/advice/email.top.php
http://www.catb.org/~esr/faqs/smart-questions.html
http://support.microsoft.com/kb/555375
You cannot reply off-list:-)
5:47 a.m.
On Wed, Apr 30, 2008 at 04:07:16PM +0800, John Summerfield wrote:
Scott Robbins wrote:
>There are reasons for it. Whether they're really good reasons or not is
>beyond my knowledge, so I made no comments.
I don't much liked UUIDs either (I had problems duplicating disks when RH
introduced labels) and UUIDs don't solve the problems I had. And they may
introduce new problems: try cloning a disk thus:
Usually what I do is just use fdisk in advance, then redo fstab after
installation, going back to using /dev/sda etc.
One reason I began doing this is because at one point, I was playing
with Ubuntu. It was already using UUID, and to make it worse, insisted
upon formatting swap during installation. So, next time I booted into
Fedora, swap wasn't seen. I would then have do swapoff -a; mkswap -L
and whatever was there, SWAP=/dev/sdc or whatever I had in fstab, swapon
-a. (The sequence might be wrong, this was awhile ago. ) After
rebooting Ubuntu, *it* no longer had swap.
On the other hand, sharing multiple distros in the old days, when
everyone used the simple naming system, never gave me a problem. It's
one of those choices that more user friendly systems are gradually
taking away. My own preference has always been for the very simple
cfdisk, which unfortunately, isn't included with Fedora. fdisk is also
good, but cfdisk has the added advantage of being able to toggle size
units, and for me at least, it's far simpler to figure out gigs or megs
than it is to figure out block sizes.
--
Scott Robbins
PGP keyID EB3467D6
( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 )
gpg --keyserver pgp.mit.edu --recv-keys EB3467D6
Anya: I have witnessed a millennium of treachery and oppression
from the males of the species, and I have nothing but contempt
for the whole libidinous lot of them.
Xander: Then why are you talking to me?
Anya: I don't have a date for the prom.
Xander: Well, gosh, I wonder why not? It couldn't possibly have
anything to do with your sales pitch.
Anya: Men are evil. Will you go with me?
6:26 a.m.
On Tue, 2008-04-29 at 22:40 -0700, Andrew Farris wrote:
Chuck Anderson wrote:
> On Wed, Apr 30, 2008 at 12:35:41AM -0400, Christopher L Tubbs II wrote:
>> Granted, I understand that a UUID is just as good as a LABEL, as far as
>> functionality goes, but LABELs are so much easier to read, compare, and
>> type. Why would the F9 installer choose to create UUIDs instead of readable
>> LABELs? I have no idea.
>
> UUIDs are unique. LABELs may not be.
This is precisely the reason, because the realization has hit people that a
system may have many linux distros installed on it, so labels made by other
distros for '/' are not unique; at the same time the device names are no longer
guaranteed to be in any particular ordering when some devices come and go
(hotswapped drives especially). UUIDs are the identifier that won't get mixed
up or changed.
It seems to me that there are two issues here:
1) How do I identify my disks/partitions so I know what's going on?
2) How do I tell the system what to mount where in a consistent manner.
Labels solve 1 but may fail at 2. UUIDS solve 2 but are awkward for 1.
So, off the top of my head, why not use both? It's trivial for the
system to notice when two partitions have the same label, so at install
time (or mount time, or whatever) it could simply offer to change one of
them, e.g. if I have LABEL=foo on two partitions, relabel them foo-1 and
foo-2. Keep the UUIDs but make the labels work for the humans among us.
poc
10:28 a.m.
On Wed, Apr 30, 2008 at 04:07:16PM +0800, John Summerfield wrote:
Labels are inherently broken, as others have noted.
Actually UUIDs are hopelessly broken too for any tool which would
try to easily indentify by itself to which installation a given
partition may belong. Anaconda is in a position to mount everything
in sight and it tries to identify only very specific installations.
In general this does not work too well. So the argument above is
very, very weak.
OTOH I do not care that much what an installer happens to dump
here on my disk. There are things like editors. Changing labels
is also not a complicated operation.
At one time, on one
system, I was multibooting two RHEL betas, opensuse 10, sles10 and
Fedora Core 6.
So? Quite far from high installation numbers. OTOH this is a
clearly a situation when identifying every file system by UUID
only makes for a big unreadable mess.
Michal
2:30 p.m.
Patrick O'Callaghan wrote:
On Tue, 2008-04-29 at 22:40 -0700, Andrew Farris wrote:
> Chuck Anderson wrote:
>> On Wed, Apr 30, 2008 at 12:35:41AM -0400, Christopher L Tubbs II wrote:
>>> Granted, I understand that a UUID is just as good as a LABEL, as far as
>>> functionality goes, but LABELs are so much easier to read, compare, and
>>> type. Why would the F9 installer choose to create UUIDs instead of readable
>>> LABELs? I have no idea.
>> UUIDs are unique. LABELs may not be.
> This is precisely the reason, because the realization has hit people that a
> system may have many linux distros installed on it, so labels made by other
> distros for '/' are not unique; at the same time the device names are no
longer
> guaranteed to be in any particular ordering when some devices come and go
> (hotswapped drives especially). UUIDs are the identifier that won't get mixed
> up or changed.
It seems to me that there are two issues here:
1) How do I identify my disks/partitions so I know what's going on?
2) How do I tell the system what to mount where in a consistent manner.
Labels solve 1 but may fail at 2. UUIDS solve 2 but are awkward for 1.
So, off the top of my head, why not use both? It's trivial for the
system to notice when two partitions have the same label, so at install
time (or mount time, or whatever) it could simply offer to change one of
them, e.g. if I have LABEL=foo on two partitions, relabel them foo-1 and
foo-2. Keep the UUIDs but make the labels work for the humans among us.
The problem does not only arise at install time. In fact, thats the simple
case. If you move a disk from system to system you could get it booting the
wrong system because labels conflict, when during install it was fine. So you
need to make sure when two systems are installed their labels will be
sufficiently unique... foo-UUID might work fine for that but anything short of
it fails.
--
Andrew Farris <lordmorgul(a)gmail.com> www.lordmorgul.net
gpg 0x8300BF29 fingerprint 071D FFE0 4CBC 13FC 7DEB 5BD5 5F89 8E1B 8300 BF29
2:38 p.m.
On Wed, Apr 30, 2008 at 12:30:38PM -0700, Andrew Farris wrote:
The problem does not only arise at install time. In fact, thats the
simple case. If you move a disk from system to system you could get
it booting the wrong system because labels conflict, when during
install it was fine. So you need to make sure when two systems are
installed their labels will be sufficiently unique... foo-UUID might
work fine for that but anything short of it fails.
We still need to solve this problem with VolGroup00 (LVM Volume Group
names in general).
3:04 p.m.
On Wed, 2008-04-30 at 12:30 -0700, Andrew Farris wrote:
Patrick O'Callaghan wrote:
> On Tue, 2008-04-29 at 22:40 -0700, Andrew Farris wrote:
>> Chuck Anderson wrote:
>>> On Wed, Apr 30, 2008 at 12:35:41AM -0400, Christopher L Tubbs II wrote:
>>>> Granted, I understand that a UUID is just as good as a LABEL, as far as
>>>> functionality goes, but LABELs are so much easier to read, compare, and
>>>> type. Why would the F9 installer choose to create UUIDs instead of
readable
>>>> LABELs? I have no idea.
>>> UUIDs are unique. LABELs may not be.
>> This is precisely the reason, because the realization has hit people that a
>> system may have many linux distros installed on it, so labels made by other
>> distros for '/' are not unique; at the same time the device names are no
longer
>> guaranteed to be in any particular ordering when some devices come and go
>> (hotswapped drives especially). UUIDs are the identifier that won't get
mixed
>> up or changed.
>
> It seems to me that there are two issues here:
>
> 1) How do I identify my disks/partitions so I know what's going on?
> 2) How do I tell the system what to mount where in a consistent manner.
>
> Labels solve 1 but may fail at 2. UUIDS solve 2 but are awkward for 1.
>
> So, off the top of my head, why not use both? It's trivial for the
> system to notice when two partitions have the same label, so at install
> time (or mount time, or whatever) it could simply offer to change one of
> them, e.g. if I have LABEL=foo on two partitions, relabel them foo-1 and
> foo-2. Keep the UUIDs but make the labels work for the humans among us.
The problem does not only arise at install time. In fact, thats the simple
case. If you move a disk from system to system you could get it booting the
wrong system because labels conflict, when during install it was fine. So you
need to make sure when two systems are installed their labels will be
sufficiently unique... foo-UUID might work fine for that but anything short of
it fails.
Again, this can be dealt with by an error message or dialogue. The
system notices the conflict and reports it: "Partitions x and y have the
same label. Please relabel one of them to proceed." The corner case is
if I remove one hd and replace it with another one with the same label,
but IMHO if I do that it's because I *want* to do it, e.g. replace a
failing drive with a new one, something which is currently hard (or at
least messy) to do using UUIDs.
poc
5848
days inactive
5848
days old
11 comments
7 participants
participants (7)
-
Andrew Farris -
Christopher L Tubbs II -
Chuck Anderson -
John Summerfield -
Michal Jaegermann -
Patrick O'Callaghan -
Scott Robbins