Lennart Poettering wrote: > On Mon, 23.08.10 10:52, Garrett Holmstrom (gholms@xxxxxxxxxxxxxxxxx) 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. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
