[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.


  .''`.  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: