[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 16 July 2013 17:07, Roger Leigh <rleigh@codelibre.net> wrote:
> On Tue, Jul 16, 2013 at 05:37:09PM +0200, Paul Wise wrote:
>> On Sun, Jul 14, 2013 at 10:38 PM, Roger Leigh wrote:
>> > I don't think that we agreed on merging /usr at all.  I have written
>> > some patches for initramfs-tools to permit fsck and mount of /usr
>> > in the initramfs in addition to the rootfs, but that's as far as this
>> > has gone.  There's no merging here, just changing where /usr is
>> > mounted in the boot process.
>> Is this implemented by just mounting /usr, by discovering which
>> partitions need mounting for each binary that is to be run from the
>> initramfs or by copying stuff from /usr into the initramfs too?
> 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.

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?



[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652459

Reply to: