See also bug 364441.
Are you guys going to fix this for F9?
What is the actual proposal?
Naming is always difficult. Assuming bug 364441 gets resolved the only use of
the label would be display in the UI so I'd go with something like "Fedora9",
"Fedora 9 /usr", "Fedora 9 /boot" and so forth.
(People upgrading to e.g. Fedora 10 can easily just change the fs label; in fact
the installer (in upgrade mode) could do this automatically. In some future
people will be able to rename volumes from the UI but we don't have that yet.)
This bug is somewhat important to resolve as the current labels are inadequate
for e.g. dual-boot systems. Consider this screenshot
where the two drives /1 and /home refers to partitions from a Fedora 8 install
on the same disk (system is running Rawhide from another partition). With this
proposal I'd instead see "Fedora 8" and "Fedora 8 /home"
Keep in mind there's a 16 character limit on fs labels on ext3 + friends.
Hope this clarifies.
This is too late for 9 I do believe, moving to 10 target.
(In reply to comment #4)
> This is too late for 9 I do believe, moving to 10 target.
Fair enough, 9 is close.
However it's pretty annoying the anaconda folks didn't respond to this. I
thought I've already explained, in great detail even, why the current labels are
bogus and how it hurts usability...
I did say to come by and talk to me last week when I was in the office most
days... especially as we're actually considering dropping the labels. They
cause a lot of pain to maintain uniqueness and also some of the things that you
want here (which then get confusing/screw other things on the disk after an
upgrade) such that UUID is *really* what we end up wanting to use for everything.
Do you know that UUID sucks from user's point of view? At least I have a problem
to remember arbitrary UUID string. LABELs are more sexy :-)
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
Peter had a good point. Since we're just always using the UUIDs in fstab, etc
there's not that much of a reason *not* to just write the mountpoint as the
label (truncated as necessary). Yes, it could lead to duplicate labels, but
that won't matter for the general case. And for the special case, it already
*has* to be somewhat handled due to people with SANs and all kinds of other things.
I really don't see how trying to encode a distribution in there helps for the
reasons previously mentioned. Changing it on upgrade would break things if
someone has set the device up to auto-mount by label, not changing it leads to
just as much confusion as not having it to begin with.
Okay, talked with davidz in person and we agreed that this seems like a
reasonable course forward. Sticking on the F10 blocker list and also putting in
the general anaconda-maint pool.
Some thoughts/opinions if it is not too late...
If the proposal now is something like "Fedora 9 /" then that is cool. Better
than UUIDs. I'm not sure about "Fedora 9 /boot" though. Maybe "Grub 0.97 /boot"
because a label should not be changed unless the purpose of the filesystem is
changed and it may boot more than one OS.
But labels do suffer from one of the same drawbacks as UUIDs. Filesystems are
sometimes copied, for backup purposes etc. Since bug 364441 users such as myself
are learning the hard way to use "tune2fs -U random".
In my case I create a snapshot of my F8 partition and hoped to upgrade it to F9,
but anaconda did not list the snapshot and I did not understand why.
For logical volumes I would actually prefer to see the device. The only reason
for not using devices that I am aware of is that partition numbers can change
(similarly "hda" has been known to change to "sda"). But logical volume devices
are fixed, aren't they?
BTW I had to change the UUID to LV device in my grub.conf before F9 would boot
for the first time - I don't know exactly why.
To summarise IMHO:
- Unless the device path is likely to change, use it because it is by nature unique
- Otherwise use a label fully describing the filesystems purpose and hope it is
- UUIDs - yuck!
We're now doing exactly what Jeremy outlined in comment #9 as of the build of anaconda in today's rawhide.