Hi Redhat, I hate you

[n0cmonkey]

WTF did these people do to /etc/fstab? :|

 

[statik213]

it's still there on fedora

 

[n0cmonkey]

Originally posted by: statik213
it's still there on fedora

Not really. Some bastardization of the fstab format is there, but it isn't:

1. Documented.
2. Standards compliant (to the standards that have been around loonger than I've been alive).
3. Documented.
4. Edittable.
5. Documented.
6. Intuitive.
7. Documented.

 

[LuckyTaxi]

thats why we love *BSD

 

[n0cmonkey]

Originally posted by: lilcam
thats why we love *BSD

I'm afraid Net/Free may sometimes switch to this "freedesktop" type solution... Then again, it'd be documented if they did. 😛

 

[TonyRic]

n0c, are you talking about the strange lines that dynamically get added to fstab by udev and automount?

 

[n0cmonkey]

Originally posted by: TonyRic
n0c, are you talking about the strange lines that dynamically get added to fstab by udev and automount?

The man pages say something about freedesktop.org's HAL or something. I'm not sure if they get added by udev/automount or not.

 

[LuckyTaxi]

I really hope freebsd doesnt. I dont even need a GUI anymore since I've played around with PICO (I hate VI).

 

[Nothinman]

Why don't you paste what you're talking about? They've been using the LABEL= stuff for a while, but other than that I don't know what you're talking about.

 

[n0cmonkey]

Originally posted by: Nothinman
Why don't you paste what you're talking about? They've been using the LABEL= stuff for a while, but other than that I don't know what you're talking about.

That's basically what I'm talking about.

Here's part of the fubarred /etc/fstab file (if it was my machine I'd paste it all 😉):

more /etc/fstab
# This file is edited by fstab-sync - see 'man fstab-sync' for details
LABEL=/ / ext3 defaults 1 1
none /dev/pts devpts gid=5,mode=620 0 0
none /dev/shm tmpfs defaults 0 0
LABEL=/home /home ext3 defaults 1 2
none /proc proc defaults 0 0
none /sys sysfs defaults 0 0
LABEL=/tmp /tmp ext3 defaults 1 2
LABEL=/usr /usr ext3 defaults 1 2

None of that makes enough sense to be editted manually, and the documentation does not match up to the configuration.

EDIT: I guess it is documented (poorly), but it's hard to tell since man pages on RHES[34] don't ever display correctly for me. Still, it doesn't apply in this situation since I'm using ext3, and e2label appears to be for ext2. 😕

 

[Nothinman]

I know back in the RH9 days they started using UTF-8 as the default locale, I thought they fixed all of the issues from that but they might display properly if you do change that. Try something like 'LANG=C man blah' or 'LC_ALL=C man blah' and see if that fixes it.

And the label stuff is pretty straight forward, each filesystem has a label in the superblock and the system uses those to find the device instead of straight device names. This means if disk order changes it won't affect anything. And of course each filesystem has their own labeling tools, e2label is used to label ext2 and ext3 filesystems since they're 90% the same on disk format.

$man e2label
Reformatting e2label(8), please wait...



E2LABEL(8) E2LABEL(8)

NAME
e2label - Change the label on an ext2/ext3 filesystem

 

[n0cmonkey]

Originally posted by: Nothinman
I know back in the RH9 days they started using UTF-8 as the default locale, I thought they fixed all of the issues from that but they might display properly if you do change that. Try something like 'LANG=C man blah' or 'LC_ALL=C man blah' and see if that fixes it.

I'll wait for them to fix it.

And the label stuff is pretty straight forward, each filesystem has a label in the superblock and the system uses those to find the device instead of straight device names. This means if disk order changes it won't affect anything. And of course each filesystem has their own labeling tools, e2label is used to label ext2 and ext3 filesystems since they're 90% the same on disk format.

How often do disks change on your servers? They don't generally change here. Sounds a bit complicated to me.

Using a non-standard fstab is just silly.

 

[Nothinman]

I'll wait for them to fix it.

Might not happen, since you didn't explain how they're misdisplaying it might not be something that anyone else has seen. It might be the font in your terminal emulator or something.

How often do disks change on your servers? They don't generally change here. Sounds a bit complicated to me.

Using a non-standard fstab is just silly.

I thought the syntax was pretty self-explanatory myself. And how often do you edit fstab for devices you setup during install? Probably slightly less often than you change disks in those servers. Complaining about something that simple that has such clear advantages is just silly.

And actually, I'm not a huge fan of the LABEL= method. But the new udev will populate /dev/disk/by-label/ with symlinks to the devices named by their label, so you can still use the labels and have slightly more obvious syntax.

 

[M00T]

RedHat... confusing us, one RPM at a time.

 

[TonyRic]

The LABEL=/ at the beginning of the line just refers to the partition label. you cen remove that by hand and replace it with the appropriate /dev/*d** without any issues at all.

It is documented, but only on redhats site. And even then you have to dig for it.

 

[n0cmonkey]

Originally posted by: Nothinman
I thought the syntax was pretty self-explanatory myself. And how often do you edit fstab for devices you setup during install? Probably slightly less often than you change disks in those servers. Complaining about something that simple that has such clear advantages is just silly.

I don't do either very often, but today I did one of them.

The syntax isn't self-explanatory at all. No devices are mentioned, as they are in just about every unix or unix-like system I've used.

And actually, I'm not a huge fan of the LABEL= method. But the new udev will populate /dev/disk/by-label/ with symlinks to the devices named by their label, so you can still use the labels and have slightly more obvious syntax.

Still too confusing. There is no advantage to this stupid CF, it's just different enough to make experienced people go 😕.

 

[n0cmonkey]

Originally posted by: TonyRic
The LABEL=/ at the beginning of the line just refers to the partition label. you cen remove that by hand and replace it with the appropriate /dev/*d** without any issues at all.

I shouldn't have to. It should be setup correctly the first time.

It is documented, but only on redhats site. And even then you have to dig for it.

Unacceptable.

 

[TonyRic]

Originally posted by: Nothinman
And actually, I'm not a huge fan of the LABEL= method. But the new udev will populate /dev/disk/by-label/ with symlinks to the devices named by their label, so you can still use the labels and have slightly more obvious syntax.

I am not a fan of the LABEL syntax either, I always change it. As for the new hal labelling however, I do like it. It will help with device swapping such as USB disks retaining their proper mountpoint and /dev id so nothing screwy happens as it has in the past.

 

[n0cmonkey]

Originally posted by: TonyRic

Originally posted by: Nothinman
And actually, I'm not a huge fan of the LABEL= method. But the new udev will populate /dev/disk/by-label/ with symlinks to the devices named by their label, so you can still use the labels and have slightly more obvious syntax.

I am not a fan of the LABEL syntax either, I always change it. As for the new hal labelling however, I do like it. It will help with device swapping such as USB disks retaining their proper mountpoint and /dev id so nothing screwy happens as it has in the past.

That's the one place crap like this might be useful, removable disks.

 

[Nothinman]

The syntax isn't self-explanatory at all. No devices are mentioned, as they are in just about every unix or unix-like system I've used.

Sure it is, if you know that the filesystems support labels it all should fall into place when you see the line. Just because it's different doesn't necessarily mean it's bad.

Still too confusing. There is no advantage to this stupid CF, it's just different enough to make experienced people go .

Sure there are advantages, moving disks between machines and adding/removing/replacing hardware won't affect the boot process. I can take a local disk and move it to the SAN and it'll still mount just fine.

I shouldn't have to. It should be setup correctly the first time.

It is correct. The machine booted, right?

Unacceptable.

Then file a bug report, I really doubt RH has people trolling all the forums around the world looking for complaints.

 

[n0cmonkey]

Originally posted by: Nothinman

The syntax isn't self-explanatory at all. No devices are mentioned, as they are in just about every unix or unix-like system I've used.

Sure it is, if you know that the filesystems support labels it all should fall into place when you see the line. Just because it's different doesn't necessarily mean it's bad.

But how would I know that? Having only worked with systems that use a standard fstab, how am I supposed to know this?

Still too confusing. There is no advantage to this stupid CF, it's just different enough to make experienced people go .

Sure there are advantages, moving disks between machines and adding/removing/replacing hardware won't affect the boot process. I can take a local disk and move it to the SAN and it'll still mount just fine.

Like I said, removable disks make sense. If I'm replacing a disk, chances are I'm bringing the machine into single user mode to fix things before trying to bring it up all the way.

I shouldn't have to. It should be setup correctly the first time.

It is correct. The machine booted, right?

It doesn't follow fstab standards, aka it's incorrect.

Unacceptable.

Then file a bug report, I really doubt RH has people trolling all the forums around the world looking for complaints.

I doubt they care about one little paying customer not being able to find documentation.

 

[Nothinman]

But how would I know that? Having only worked with systems that use a standard fstab, how am I supposed to know this?

One would assume that you have some knowledge of the system's your administering. The change is not much bigger than the unique use of device names that each unix has, hell have you ever logged into a Tru64 cluster and seen what it's mount points look like?

It doesn't follow fstab standards, aka it's incorrect.

And where are those independent standards documented? Do you have problems with the way that cifs, smbfs, ncpfs, etc are used within fstab as well?

I doubt they care about one little paying customer not being able to find documentation.

RH's on-system documentation is pretty bad, the only way that'll change is if people complain. I take it you don't vote either, because the vote of one little citizen won't matter?

 

[n0cmonkey]

Originally posted by: Nothinman

But how would I know that? Having only worked with systems that use a standard fstab, how am I supposed to know this?

One would assume that you have some knowledge of the system's your administering. The change is not much bigger than the unique use of device names that each unix has, hell have you ever logged into a Tru64 cluster and seen what it's mount points look like?

I don't have access to a Tru64 cluster. We don't use it, so I don't have to know anything about it.

I may not know a whole lot about Linux, but I've used it occassionally. I'm pretty good with Windows. 😛

Seriously though, I'm not stupid, I've just never had to look at the fstab on recent Linuxes. I didn't know they mucked with things like that. I figured they would be fixing some of the issues, instead of creating new ones.

It doesn't follow fstab standards, aka it's incorrect.

And where are those independent standards documented?

Look at the fstab on Solaris (vfstab I guess), OpenBSD, NetBSD, FreeBSD, previous iterations of Linux. They're all relatively the same. They all work fine. All of a sudden, Linux developers are fixing things that aren't broken.

From the conversation going on here, I realize that the system isn't as bad as I originally thought it was. It should be quite useful for removable media. But it doesn't make as much sense for large SCSI arrays on a server.

If a disk goes down, I'll probably be rebuilding the array and nothing will change for the OS. If something does change for the OS, I'll be booting into single user mode anyways so I can edit the fstab as needed then.

Do you have problems with the way that cifs, smbfs, ncpfs, etc are used within fstab as well?

I don't use them, so I wouldn't know. Hell, has smbfs even found a daddy yet? Last I heard the maintainer went AWOL and no one picked it up. 😛

What's ncpfs?

I doubt they care about one little paying customer not being able to find documentation.

RH's on-system documentation is pretty bad, the only way that'll change is if people complain. I take it you don't vote either, because the vote of one little citizen won't matter?

My vote doesn't matter. It's a fact. My state consistantly votes Republican in Presidential elections. The number of votes for Republicans over the number of others is greater than 1. My vote doesn't matter.

BTW, changing my terminal to use UTF-8 fixed the manpage issue. Thanks. :beer:

 

[Nothinman]

I don't have access to a Tru64 cluster. We don't use it, so I don't have to know anything about it.

And that's my point, there's no standard for device naming out there so everyone's fstab looks different. And out of the ones that I've seen, LABEL=blah is the most obvious even though it doesn't directly point you to the physical device being mounted. But if you're using LVM or hardware RAID it won't do that either.

Look at the fstab on Solaris (vfstab I guess), OpenBSD, NetBSD, FreeBSD, previous iterations of Linux. They're all relatively the same. They all work fine. All of a sudden, Linux developers are fixing things that aren't broken.

See, Solaris doesn't even use the same filename so how can you count them?

From the conversation going on here, I realize that the system isn't as bad as I originally thought it was. It should be quite useful for removable media. But it doesn't make as much sense for large SCSI arrays on a server.

For internal arrays, no it's not a big win. But for devices exported via SAN or AOE, it would make things a lot simpler since the administrator of the device could move disks around without breaking the systems using the disks.

I don't use them, so I wouldn't know. Hell, has smbfs even found a daddy yet? Last I heard the maintainer went AWOL and no one picked it up.

What's ncpfs?

AFAIK smbfs is deprecated in favor of cifs, but both are supposedly supported by the Samba people.

ncpfs is the NetWare Core Protocol filesystem.

My vote doesn't matter. It's a fact. My state consistantly votes Republican in Presidential elections. The number of votes for Republicans over the number of others is greater than 1. My vote doesn't matter.

So maybe there's just a lot of self-loathing democrats out there saying the same thing and if you had all voted the outcome would be different? Of course you could always just move to another state =)

BTW, changing my terminal to use UTF-8 fixed the manpage issue. Thanks.

No problem, what terminal were you using?

 

[n0cmonkey]

Originally posted by: Nothinman
And that's my point, there's no standard for device naming out there so everyone's fstab looks different. And out of the ones that I've seen, LABEL=blah is the most obvious even though it doesn't directly point you to the physical device being mounted. But if you're using LVM or hardware RAID it won't do that either.

Ok, maybe standard is the wrong word. Maybe I have to specify it as a historical standard. Tru64 is a fringe case anyhow.

See, Solaris doesn't even use the same filename so how can you count them?

😛

AFAIK smbfs is deprecated in favor of cifs, but both are supposedly supported by the Samba people.

Last I heard (recently, but in a dead tree formatted magazine) cifs wasn't done, and didn't cover all of the cases smbfs did so they were hesitant to consider smbfs as deprecated.

So maybe there's just a lot of self-loathing democrats out there saying the same thing and if you had all voted the outcome would be different? Of course you could always just move to another state =)

What if I'm a republican? Then my vote still doesn't count. Or an independant. Then it's totally worthless.

I haven't found a decent state yet.

No problem, what terminal were you using?

Just putty in this case. It was set to one of the MANY ISO standards (I can find the one it was set to previously, if you're curious).