I need a little crash course about fstab

[Davno]

I used to modified fstab to automount partitions, but this does not make sense to me anymore. This is a new install of Mandriva 2008.1
# Entry for /dev/sda5 :
UUID=6981100c-4cda-4d3e-ac99-a0565b9e6922 / ext3 defaults 1 1
none /proc proc defaults 0 0
# Entry for /dev/hdb7 :
UUID=0c715316-6cbd-4bec-b5ab-b03a39616dc5 swap swap defaults 0 0
# Entry for /dev/hdb1 :
UUID=1C90D11290D0F2EE /media/hd ntfs-3g defaults 0 0
# Entry for /dev/hdb5 :
UUID=ba5f69b2-5a44-43ce-b75e-202b15680608 /media/hd2 ext3 defaults 1 2
# Entry for /dev/hdb6 :
UUID=8b3590dd-5e71-469c-97e5-d698b1ab05ff /media/hd3 ext3 defaults 1 2
# Entry for /dev/sda1 :
UUID=945158b2-d08c-4b10-8f1e-898412037593 /media/hd4 ext3 defaults 1 2
# Entry for /dev/hda1 :
UUID=1D5A-14F4 /media/hd5 vfat defaults 0 0
The /mnt directory is empty except for a /install folder and /media is populated with all my old ext3 and win partition.
Should i still use (modify) fstab and /mnt or is it obsolete.
My usb drive now automount in /media and all seem to work nice but what if i install another drive formated in ext3 where and how would i mount it.

[michaelk]

uuid - Universally Unique Identifier, it gives each filesystem a unique identifier. With a unique identifier your system will still boot if the drive ID changes.

Most distributions have changed the default for removable media mountpoint from /mnt to /media. However, it really does not matter where it is mounted and you can use the drive's device ID (i.e /dev/hdb1), uuid or label=xxx in the fstab file.

[saikee]

Yes michaelk has said it all.

As an example your 1st entry
# # Entry for /dev/sda5 :
UUID=6981100c-4cda-4d3e-ac99-a0565b9e6922 / ext3 defaults 1 1
will work just the same if you change it back to the Linux traditional device name as suggested in the 1st line
# Entry for /dev/sda5 :
/dev/sda5 / ext3 defaults 1 1
I have been regularly changing the by-label method of the Red Hat family distros to the traditional device names without any bother. I don't normally do it with the by-uuid names now seem to be favoured by the new distros but have changed some of them to fit my own purpose.

One of the cases I need to change the by-uuid names is after I cloned a partition or hard disk I would end up with two sets of two identical by-uuid names and so one set must go if I run both of them. A by-uuid name is generated whenever the partition is formatted with a filing system.

Personally I don't think the by-uuid naming system is any better and nobody can remember the randomly generated name with some 36 alphanumeric characters. They may be necessary to be compatible with the trend in the MS systems. For example MS Vista is booting the partition with a similar 36 alphanumeric code. I suppose if Linux is intended to be PC based and therefore able to co-exist with the MS systems it may be forced to adopt changes to go with the trend.

As long as a Linux user checks the disk names of the sda, sdb, sdc, etc and aware how they are assigned then the traditional device names can still be used, at least that is what I have done with my systems.

As an example to show how it may benefit Linux I could think of a case when one installs Ubuntu on an external USB hard disk or a pen drive when there are 2 internal disks already in the PC. The internal disks get detected first and will be assigned as disk /dev/sda and /dev/sdb while the USB disk later will get assigned as dev/sdc. Had the Ubuntu been installed with the device name /dev/sdc then it will not boot if one of the internal disk is removed, forcing it to become /dev/sdb or another internal disk is added forcing it to become /dev/sde. However using the by-uuid naming system the changes in the hard disk would not matter at all.

The by-uuid relative to the traditional device names are all listed in the /dev directory of every Linux.

The change from /mnt to /media is widespread in the Linux distros but the older die hard distros like the Slackware and Slax are still sticking to only /mnt. I don't normally bother with the change as if I couldn't find a mounted partition in /mnt then it will be in the /media waiting for me. Personally I prefer /mnt myself and mount my own partition there.

[gamblor01]

Here's a great little article that breaks down the /etc/fstab file column by column. I just found it on google:

http://www.tuxfiles.org/linuxhelp/fstab.html

[bwkaz]

and nobody can remember the randomly generated name with some 36 alphanumeric characters. I will agree with that, but:

They may be necessary to be compatible with the trend in the MS systems. ... that's not it at all. :)

Filesystems have been assigned UUIDs for a really long time now (I believe that at least ext3 has had them ever since it existed). The recent trend isn't to create a UUID, it's to use that UUID to identify the filesystem to the rest of the machine.

(I've said this a lot before, so this is probably going to sound repetitive, but:) your disk names (sda, sdb, etc.) are explicitly not guaranteed to be stable from one boot to the next, let alone from one kernel version to the next. If you have config files that depend on the sdXY or hdXY names, then those files will break when the devices move. However, if you build config files that depend on some property of the partition or filesystem itself (either the UUID, or the label, or the path from the CPU to the partition), then since that information stays constant from one reboot to the next, your config files will always be able to find the right filesystem.

Now yes, it is true that UUIDs are hard to remember, but most of us don't have to edit that info very often. (Saikee, you're an exception. :p) Also, running /lib/udev/vol_id on a partition will print its UUID, assuming a recent udev and assuming the vol_id program knows how to find the UUID.

For example MS Vista is booting the partition with a similar 36 alphanumeric code. It's also a universally-unique ID, yes. But that ID has a different purpose (identifying the vista bootloader equivalent of a grub stanza, not identifying a filesystem). Linux already has better ways of identifying bootloader stanzas (i.e. the grub menu.lst file), so it doesn't need that. The trend in Linux toward using a UUID (or label, or path) to identify a filesystem is based on the fact that filesystems move around, not based on some kind of "let's act like vista" idea. :)

... then the traditional device names can still be used, at least that is what I have done with my systems. Which means you haven't been bitten by the moving-device problem either. Yet. ;)

(I will note that using a by-uuid path would sidestep the difference between libata and non-libata kernels for IDE controllers, too. At least as far as partition identification goes -- you still can't create more than 14 partitions under libata. But the hdXY->sdXY changeover wouldn't have affected anything. ;))

The internal disks get detected first and will be assigned as disk /dev/sda and /dev/sdb while the USB disk later will get assigned as dev/sdc. Not necessarily. It depends on how the PCI and USB buses are scanned: if the USB hosts are found, and then the hubs attached to those hosts enumerate the storage device, before the SATA or IDE device driving the disks is found, then the USB device will probably be sda, and the others will probably be sdb and sdc.

Maybe you've never seen that happen (and I'll be honest: I haven't either, though I rarely boot with USB storage devices plugged in), but there's nothing in the kernel preventing it from happening, either. Race conditions are "fun" that way. :)

[saikee]

I am quite comfortable with the USB and external devices are detected later than the internal hard disks, so far from the PCs I have been involved.

A by-uuid names is a randomly generated name and is impossible to identify which device it come from whereas the /dev/sdx can be traced back to the device if one pays attention to the detection order of the Bios.

I am probably an odd one out favouring the /dev/sdx names but this is because I normally add and withdraw hard disks frequently in the PC and like to know where each of the partitions comes from.

I think the best hard disk detection could be the one that include the controller number, as Internal Pata, Internal Sata, Internatl SCSI, firewire, eSata and USB are all handled by different controllers.