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. > 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 -- 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/20130716183945.ge4...@codelibre.net
