On Fri, 2016-07-01 at 23:05 +0100, Steve McIntyre wrote:
> On Fri, Jul 01, 2016 at 11:41:58PM +0200, Ben Hutchings wrote:
> > On Fri, 2016-07-01 at 21:56 +0100, Steve McIntyre wrote:
> > > On Tue, Jun 28, 2016 at 09:13:25PM +0200, Ben Hutchings wrote:
> > > >
> > > > I wonder why we offer to mount /boot but not /usr (more and more
> > > > programs live there), /var (some of them might need state there) or
> > > > /tmp (don't want to create files there that will never be cleaned
> > > > up).
> > >
> > > Maybe, yes. For now I've made the code here much more generic to make
> > > it easier to ask about other filesystems, and added a check for
> > > /boot/efi too.
> > >
> > > > Also, does the question about mounting /boot really merit critical
> > > > priority? Is 'yes' not a good default?
> > >
> > > *If* the /boot fs is broken, attempting to auto-mount is probably not
> > > a good plan.
> >
> > That's true. Perhaps the sensible thing is perhaps to mount /usr and
> > the virtual filesystems unconditionally, and then ask whether to mount
> > all the other local filesystem ('mount -a -O no_network').
>
> How are /usr and any other disk-based filesystems likely to be any
> different to /boot here?
/usr should be mounted unconditionally because binaries on the root
filesystem may in practice depend on it or there may not even be any
binaries on the root filesystem (https://wiki.debian.org/UsrMerge).
For the other local filesystems, I'm proposing that we ask a single
question whether to mount them rather than asking separately about
/boot, /boot/efi, etc.
> I'd agree about the virtual fsen...
And the essential virtual filesystems do already get mounted
unconditionally.
Ben.
--
Ben Hutchings
Never attribute to conspiracy what can adequately be explained by
stupidity.
Attachment:
signature.asc
Description: This is a digitally signed message part