On Tue, 12 Aug 2014 14:07:36 +0200 Sven Hartge <s...@svenhartge.de> wrote:
> Andrei POPESCU <andreimpope...@gmail.com> wrote: > > On Du, 10 aug 14, 22:22:20, Sven Hartge wrote: > > >> All other were mostly misconfigrations which kinda worked before, > >> because sysvinit was more forgiving or just papered over the error, > >> for example unavailable volumes during boot without "nofail" or > >> "_netdev". > > > It's also very unforgiving of wrong fstab entries (see #756103). > > Right. > > >From a desktop users perspective, this behavior is quite astonishing. > More so if it has been working with sysvinit for the last umpteen > years. > > With my server admin hat on, I like this strictness. I _want_ a boot > to fail if not all filesystems are available. > All files required to *boot* must be available in / and/or /boot. I believe it is not trivial to require an additional filesystem to be available to grub2, hence the need to merge /usr into / at some point for those who have them separate at the moment. Additional filesystems may be mounted 'at boot', meaning automatically when the computer is started rather than manually later, while not being required for the boot process itself. I think the boot should not fail if such filesystems are unavailable, but that suitable error messages should be issued allowing the problems to be fixed. There seems to be a bluetooth issue in sid at the moment, but this doesn't halt the boot process, nor should it. I have a number of network filesystems mounted 'at boot', but I'd be very annoyed if a computer wouldn't boot because of network issues. Clearly, network-mounted filesystems are not considered essential for the boot process to complete, but local filesystems which are not mounted on well-known *nix system directories are. > Maybe some configurable option is in order here, to allow the admin to > set the level of strictness he wants. > I believe there is, though I have not yet tried to use it. The point is that, going back two of your paragraphs, it is a *change*, and if not manually corrected will therefore break existing systems on upgrade. I would have preferred to see it done the other way around, i.e. that unfamiliar mount points listed in fstab would need some sort of 'abort the boot if this doesn't mount' flag to be added. By the way, if the boot is aborted, it would be nice to have some sort of shell access available. When this fstab issue bit me, there was no control available at all other than the Big Red Switch. Even grub2 drops you into a rescue shell when it's unhappy, as I know well. -- Joe -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140812143129.3d882...@jresid.jretrading.com
