Re: /usr (was: Re: Survey answers part 3: systemd is not portable and what this) means for our ports
On 16 July 2013 19:39, Roger Leigh <rleigh@codelibre.net> wrote:
> 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.
>
Thinking about it more, it's possibly not the encryption case which
might be most prominent here.
I have seen containers / images made readonly, with /etc mounted using
overlayfs to provide easily clonable machines (chroots,
lxc-containers, "cloud-images").
Not sure, but probably, capser was used to do the mounting there.
>> 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.
>
Ok, thanks for the heads up.
Regards,
Dmitrijs.
Reply to: