[Leaplist] fstab

Jim Hartley xjimh at cfl.rr.com
Thu May 29 15:13:40 EDT 2008


Because of the way I installed things, the LABELs in my Fedora 7 fstab 
are VERY confusing. I first installed some version of CentOS on 
/dev/sda3 (actually, at that point it was /dev/hda3!), with /home on 
/dev/sda8 and a spare partition (same size as /dev/sda3) on /dev/sda5. 
Then I put Fedora 6 on /dev/sda5 and used it for a while. Something get 
messed up and the easiest fix was to wipe that partition and put Fedora 
7 on it. Now the Fedora 7 partition (root) has LABEL=/tmp while the 
CentOS partition has LABEL=/. Yuck!

I suppose if I could figure out how to edit the LABELs (make them 
something like LABEL=/Fedora7 and LABEL=/CentOS) it wouldn't be too bad, 
but I don't know where they've hidden that info.

Jim Hartley

Bryan J. Smith wrote:
> While I can understand some of the UUID complaints, as it's hardly
> "descriptive," I can_not_ understand the LABEL complains.  And Red
> Hat is hardly the only distro doing that one (but we're one of the
> first for UUID AFAICT).
> 
> Jim Hartley wrote:  
>> OK, I see the value for large and/or complex installations.
>> But for the user who is NOT going to do this stuff, who is
>> never going to move disks around, and who always wants the
>> NEXT install to look like the previous one, it's a PITA.
> 
> Do you use USB storage?  If so, then understand the LABEL is what is
> used to mount under /media.  ;)
> 
> Why stop there?  Why don't we just use Drive Letters?  TLD like /c,
> /d, etc...?  I don't jest, I've seen that asked.  ;)
> 
>> Perhaps the solution is to keep the default using UUIDs,
> 
> Wait!
> 
> Are we complaining about UUIDs now?
> Or are we complaining about LABELs?
>   
>> but provide an option during the install process to select
>> "hard coded devices in fstab".
> 
> There are other dependencies in Anaconda that use LABELs, let alone
> UUIDs.  But yes, there could be a re-write to dump out /etc/fstab to
> be different when done.  Of course some consumer setups will still
> have issues post-install.
> 
> That's why LABELs, now UUIDs, became the default across-the-board. 
> The new GIO-GVFS also uses UUIDs, and then presents via LABELs.
> 
> I know, I had two (2) USB devices with the same label outside of my
> control.  I.e., bought two (2) external USB devices.  GIO-GVFS
> addresses that better now.  Back in the Fedora 8 days, I got all
> sorts of issues with gnome-vfs.
> 
> Even better was when Windows _toasted_ them because of it.  It made
> Drive Letter assumptions.  Sigh.
> 
>> For **MY** personal convenience, I am going to get rid of
>> the damn LABELs I have now, and when I get around to
>> installing Fedora 9 (fairly soon) I will just edit fstab
>> to get eid of the UUIDs.
> 
> Your choice.
> 
>> Some installs DO NOT NEED the extra security - the good ole
>> convenient way is jes' fine!
> 
> That's ironic, because the LABEL approach _is_ the most "convenient"
> way we know of.  I can understand some of the "views" on using UUID. 
> Unfortunately, for avoiding LABELs, that I don't understand.  It's
> what is used for USB.
> 
> I assume LABELs to not just Ext3 and XFS, but FAT and NTFS
> filesystems as well.  If you don't, then that's your decision.  I
> just wouldn't question why others do.
> 
> Just a consideration.  I mean, I don't tell people what they should
> do, I never do.  I just try to point out why it defaults for others. 
> And that includes for consumer reasons -- especially LABELs.
> 
> I'm very happy to see the new resolution with GIO-GVFS in Fedora 9,
> as well as the UUID switch.  Other distros will be following suit. 
> If you don't like Red Hat, or those other distros that do it, then
> use something else if you really feel strongly about it.
> 
> Of course, to support development, it's good to adhere to solid,
> enterprise approaches.  Canonical recently got smacked by Dell for
> not doing so with Ubuntu.  That's undercutting their funding. 
> History repeats itself *COUGH*Mandriva*COUGH*.  ;)
> 
> 

-- 
Teen Angel - a ghost story - http://teenangel.netfirms.com


More information about the Leaplist mailing list