On 16 July 2013 19:39, Roger Leigh <rle...@codelibre.net> wrote: > On Tue, Jul 16, 2013 at 06:38:18PM +0100, Dmitrijs Ledkovs wrote: >> On 16 July 2013 17:07, Roger Leigh <rle...@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. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANBHLUjRojxuo7FmnRrQ76VugG29bjFP31eF=bawbpum_pz...@mail.gmail.com
