On Thursday, 20 de November de 2014 20:44:17 Simon McVittie escribió: > On 20/11/14 19:06, Noel Torres wrote: > > On Thursday, 20 de November de 2014 17:53:27 Marco d'Itri escribió: > >> On Nov 20, Sam Hartman <hartm...@debian.org> wrote: > >>> The first issue (fstab now fatally blocks boot) is something the > >>> systemd maintainers have considered (as I understand it) and rejected. > >> > >> The behaviour of systemd will not be changed, but I have plans to add > >> a fstab sanity check to preinst. > > > > Just for my sanity of mind. Is this referring to entries in fstab that > > have the auto option (either directly or via defaults)? > > Yes, I'm pretty sure this is referring to entries in fstab that do not > have the noauto and/or nofail options. > > systemd tries to mount each filesystem listed in fstab that does not > have noauto. If one of them fails, it checks for the nofail option; if > given, it carries on regardless and hopes for the best. If nofail was > not given, it considers the failure-to-mount to be potentially serious > breakage, and drops into an emergency shell. > > noauto is appropriate for detachable/removable media that are not > normally present. The other option for such media is to leave them out > of fstab altogether, and use something like udisks to mount them > on-demand: that's what you'd typically do in GNOME or KDE or whatever. > > nofail is appropriate for media that are normally present, but not > important enough to make the boot fail entirely; if you mount > non-essential data directories via NFS then maybe that should be nofail? > > S
Many thanks I do not understand, then, how this is different from what sysvinit's mountall.sh does (or at least what I understand it does). Thanks Noel er Envite
signature.asc
Description: This is a digitally signed message part.
