Re: /usr (was: Re: Survey answers part 3: systemd is not portable and what this) means for our ports
On Tue, Jul 16, 2013 at 06:38:18PM +0100, Dmitrijs Ledkovs wrote:
> On 16 July 2013 17:07, Roger Leigh <rleigh@codelibre.net> wrote:
> > Once the rootfs is mounted, we parse $root/etc/fstab and mount /usr
> > using that information. When init starts, /usr is therefore
> > available from the beginning. Note that the objective here isn't
> > to allow the initramfs to run binaries from /usr, but to ensure
> > that /usr is available at all times when the system is running--
> > this means that all programs, libraries, modules, datafiles etc.
> > are available before init starts.
> >
> > There are some complicating details:
> > - we need to ensure that the modules needed to mount /usr are
> > available in the initramfs (copy the needed modules and
> > mount helpers into the initramfs)
> > - we can't fsck /usr when mounted, so this needs doing in the
> > initramfs (/ and /usr are fscked, with the appropriate
> > helpers copied into the initramfs)
> > - fsck's -R option updated to skip /usr as well as root.
> > - /etc/init.d/checkroot.sh updated to handle /usr as well
> > as root (e.g. remounting r/w).
>
> Up to here, all sounds good.
>
> Making the $mountpoints which above are treated / mounted in
> initramfs, makes sense.
> To be able to default to "/" only and change to "/ and /usr" if one desires.
> And even plugin in the feature below.
>
> > - using the same infrastructure, it's also possible to
> > mount /etc in the initramfs so that you can have e.g. a
> > separately encrypted /etc filesystem. This is a separate
> > feature though and can be split out.
> >
>
> Imho the overhead between having just "/etc" vs "/" encrypted is
> small, if "/var", "/usr", "/home", "/opt" are separate mountpoints.
> Thus to me, treating "/etc" separately is a misfeature, considering a
> mounted "/" assumes /etc must be present.
> At least, it would go against my expectation.
This is certainly the case at present. The rationale for doing this
is that if you have / and /usr on a single filesystem, but you want
to encrypt the content of /etc, you can now encrypt just /etc. It
also means you can have the rootfs read-only with a writable /etc,
have /etc as a writable overlay or separate fs on a common image for
cluster environments, etc. For encrypting stuff, it's moving the
boundary from one of simple convienience (/usr) to where it's actually
needed. But I can accept that this won't have universal appeal.
> I haven't yet reviewed the 17 patches log patch series on [1]. But is
> "/etc" handling clearly separated in it already, or some
> rebasing/reshuffling needed?
It's just patch number 11/17 with some minor documentation comments in
patch 12/17, so it can be easily dropped without problems (intentionally).
However, even if applied, it's a strictly optional feature that won't be
used by default unless you provide etc= options to match the root=
options on the kernel command-line.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
Reply to: