On Fri, Nov 21, 2014 at 05:51:47PM -0800, Russ Allbery wrote: > As I understand it, sysvinit didn't care whether mountall.sh succeeded or > failed.
This doesn't come from ignorance. What can you do in this situation? * throw your hands up, abort booting. Hope the admin enjoys a drive to the datacenter (iDrac present and working? ha ha). * continue booting, starting daemons in a best-effort attempt, hopefully letting at least part of the system's functionality work. And most important, the sysadmin can ssh in and fix the problem. > So even if a bunch of mounts failed, it went on to boot the > system, including everything that wasn't supposed to start until after all > file systems were mounted. There's currently no way to express which mounts are needed for which functionality. Assuming all are needed works only for servers with a single purpose. And even on a desktop -- if you got as far as mountall.sh, this means most of the system works, and assuming no separate /usr, the user gets his comfortable GUI with a running browser where he can google what the hell the failure means. > That meant that some folks have systems that they think are happily > booting with sysvinit with a bunch of failing mounts, and, when they > switch to systemd, things that declare a dependency on mounted file > systems never start because the file systems aren't successfully mounted. This sounds like a failure to provide a _non-fatal_ error message. Solutions I'd propose: * sysvinit: in mountall.sh, if a mount fails, store the failed fstab line in a temp file. In a new init script that comes very late in the boot, check if that file exists, if it does, mail it to root (mail-hating GUIs like gnome have alternate messaging utilities, which I do not know). * systemd: in preinst, check if any fstab lines without noauto or nofail are not currently mounted -- if so, abort the installation as it would result in an unbootable system. -- // If you believe in so-called "intellectual property", please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable and Non-Discriminatory prices. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141122130417.ga14...@angband.pl
