systemd and filesystems with noauto

Garrett Holmstrom gholms at fedoraproject.org
Mon Aug 23 17:00:53 UTC 2010


Lennart Poettering wrote:
> On Mon, 23.08.10 10:52, Garrett Holmstrom (gholms at fedoraproject.org) wrote:
>> * fstab(5) documents the "noauto" option
> 
> Well, what it says is that noauto results in "the -a option will not
> cause the filesystem to be mounted". And that's still the case. We
> execute either the real "mount -a" (or actually something equivalent) at
> bootup, and that by itself won't cause the fs to be mounted still.

mount(8):  noauto  Can only be mounted explicitly

Several other UNIX and UNIX-like systems are much more explicit about 
this, saying that noauto means that a filesystem will not be mounted at 
boot time.  If you are going to break decades of tradition you not only 
have to provide good reasons for it, but you also have to update all of 
the documentation that goes with it.

>> * I manually mount network shares that aren't always available with the 
>> "noauto" and "user" options
> 
> That's not the issue here. systemd will never mount non-device mount points
> automatically, unless listed as "auto".

That's useful to know, but inconsistent since some filesystems default 
to auto and others default to noauto.

>> * Removable media that appear in fstab are usually marked noauto
> 
> And?

Systemd should not try to mount them because the administrator 
explicitly asked for them to *not* be mounted.  There is no sense trying 
to mount a device with no media just because it appears in fstab.

>> * /boot doesn't always need to be mounted on every distro
> 
> And?

Systemd should not try to mount it because the administrator explicitly 
asked for it to *not* be mounted.  If I don't want /boot mounted then 
the init system must respect that until all of the relevant system 
documentation changes and a release note mentions the change.

>> * I mount large filesystems after the boot process finishes so fscking 
>> doesn't pause booting at $dayjob
> 
> And?

Systemd should not try to mount them because the administrator 
explicitly asked for them to *not* be mounted.  Doing otherwise while 
ignoring noauto semantics could delay booting for hours if long-running 
fscks are triggered.  Your new auto/noauto semantics aren't documented 
in important places like fstab(5) and mount(8), so rc scripts that, as 
per documentation, expect the filesystems they work with to be unmounted 
will fail.

I apologize; I thought my request was clear:  please implement 
auto/noauto in the traditional, documented way, use a different keyword 
for this new behavior, and document any new semantics or keywords in the 
relevant man pages and release notes.  I think Ubuntu uses "bootwait" 
and "nobootwait" if you need ideas.


More information about the devel mailing list