Control: retitle -1 Support 'nofail' option when mounting /usr Control: tag -1 moreinfo On Tue, 2016-09-27 at 20:31 +0200, Marc Haber wrote: > On Mon, Sep 26, 2016 at 02:58:58PM +0100, Ben Hutchings wrote: > > > > On Mon, 2016-09-26 at 07:02 +0200, Marc Haber wrote: > > > > > > Package: initramfs-tools > > > Severity: wishlist > > > > > > Hi, > > > > > > when I looked for the last time (a few months ago), fstab entries > > > parsed by initramfs-tools or in initramfs MUST NOT contain the > > > "nofail" option. > > > > All entries are parsed. But I suppose you mean the entries which are > > actually processed, which are: /usr > > And root, right? Yes, though options for root are ignored and 'nofail' wouldn't make any sense. > > And 'nofail' would make no sense for /usr, so I don't understand > > why you would want to use it there. > > I want to use it anywhere so that the system boots as far as it will > go, in the hope that it will come up so far that actual help is > possible. Unconditionally dropping to a rescue shell on the local > console is the least probable variant of "helpful". > > > > > [...] > > > > > > Please consider tweaking initramfs-tools so that "nofail" can be in > > > all lines, with it being ignored in initramfs. > > > > There's nothing we do that would reject 'nofail', and both busybox and > > klibc implementations of mount seem to ignore it. (However I don't > > currently have a test VM with separate /usr so I didn't test this > > completely.) > > You're right. "nofail" is ignored, at least in sid. > > I'm leaving this bug report open since I'd really love initramfs-tools > to continue to try booting even if mounting /usr fails. Currently, > this is what happens even if nofail is set on /usr: [...] I assume you mean that happens if the device is missing and 'nofail' is used (same as if 'nofail' wasn't used). I may implement this but it's going to be low priority as /usr will be an absolute requirement for most systems in future. I'm open to considering patches. Ben. -- Ben Hutchings If the facts do not conform to your theory, they must be disposed of.
Attachment:
signature.asc
Description: This is a digitally signed message part