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.
Description: This is a digitally signed message part