[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#389881: RC-ness of this bug

On Mar 15, 2007, at 1:12 PM, Frans Pop wrote:

On Thursday 15 March 2007 17:44, Colin Watson wrote:
Personally I also feel that all possible solutions effectively make
/etc/fstab unreadable and unmaintainable.

The approach we took in Ubuntu was to put comments above each UUID
entry in /etc/fstab documenting which traditional device name they
corresponded to at the point of installation. Of course this can get
out of date, but I don't think there's really any sensible way around

My main point is not that the UUID itself is not readable, but rather that
the lines get way too long and, depending on your editor (settings),
either get wrapped or disappear off screen. You loose the easy overview
of what's in fstab.
/etc/fstab used to be fairly maintainable because the info could be kept in columns fairly easily for most cases and because the info would mostly
fit on one line [1].

IMO with a switch to UUIDs we are going to need an fstab editor (console
based) that:
- does the translation to the "normal" device names on the fly (and thus
  does always reflect the actual situation)
- provides different 'views' of what's in fstab
- allows to select what representation for the file system should be
  used in the fstab (traditional, path, uuid, id, ...)
- allows to set mount point, type, mount options, etc.
- sorts partitions into a logical order
- maybe knows about removable devices
- has a simple interface to add new entries for e.g. USB sticks
- ...

[1] Yeah, I know this is not true for NFS volumes and if a lot of options
are used, but in general it was true.

If you're going to all the trouble of a smart fstab editor, why not simply define a more modern format (e.g. like that of dhcpd.conf) for the information that can accommodate line breaks and nesting. Change the name to something else, don't call it fstab; if the new file doesn't exist the mount command (and the rest of them that currently read fstab) will default to /etc/fstab if present.

The biggest problem will be identifying all the places where fstab is currently *assumed* to be present and making them all use the new file. A library is probably needed that does the deciding of which format to use.

Are there POSIX/LSB/etc ramifications?

just a thought,


Reply to: