Bug 364451 - Stop obfuscating labels
Stop obfuscating labels
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
9
All Linux
low Severity low
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
:
Depends On:
Blocks: F10Blocker/F10FinalBlocker
  Show dependency treegraph
 
Reported: 2007-11-02 15:01 EDT by David Zeuthen
Modified: 2013-03-05 22:53 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-08-06 15:07:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Comment 1 David Zeuthen 2008-02-15 17:00:53 EST
Are you guys going to fix this for F9?
Comment 2 David Cantrell 2008-02-15 19:17:46 EST
What is the actual proposal?
Comment 3 David Zeuthen 2008-02-15 19:46:41 EST
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 

 http://people.freedesktop.org/~david/Screenshot-cdda%20-%20File%20Browser.png

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.
Comment 4 Jesse Keating 2008-03-31 14:02:11 EDT
This is too late for 9 I do believe, moving to 10 target.
Comment 5 David Zeuthen 2008-03-31 14:27:01 EDT
(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...
Comment 6 Jeremy Katz 2008-03-31 14:51:28 EDT
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.
Comment 7 Karel Zak 2008-04-01 04:15:34 EDT
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 :-)
Comment 8 Bug Zapper 2008-05-13 23:50:07 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 9 Jeremy Katz 2008-05-29 17:50:19 EDT
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.

Thoughts, opinions?
Comment 10 Jeremy Katz 2008-06-05 13:31:57 EDT
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.
Comment 11 Jim Wright 2008-06-15 18:22:01 EDT
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
unique
- UUIDs - yuck!
Comment 12 Chris Lumens 2008-08-06 15:07:14 EDT
We're now doing exactly what Jeremy outlined in comment #9 as of the build of anaconda in today's rawhide.

Note You need to log in before you can comment on or make changes to this bug.