Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
On Sun, Dec 18, 2011 at 03:37:43AM +0100, Marco d'Itri wrote:
> On Dec 17, Roger Leigh <rleigh@codelibre.net> wrote:
>
> > So WRT mounting /usr (and potentially /etc and other filesystems),
> > I've pushed patches upstream for util-linux (initramfs mount option)
> > and initramfs-tools (generate /etc/fstab from host and mount after
> > rootfs).
(Merging this and the reply to #652459)
I'd just like to clear up a few points about the desired behaviour and
requirements for the initramfs. I have some ideas about other ways
to achieve this goal.
> > 1) Generation of /etc/fstab in the initramfs, including the rootfs
> > and all the filesystems desired to be mounted
> This is highly suboptimal, because it suddenly makes the initramfs not
> generic anymore.
> The initramfs should:
> - mount / as usual
> - look at the rootfs fstab
> - mount /usr using the information from the rootfs fstab
Regarding keeping the initramfs generic, we already permit hardcoding of
the rootfs into the image. This is overridden by root=xxx, but still
permitted. I'm not sure I see the difference between hardcoding the
root device rather than an fstab entry.
There is of course the addition of the mount options, which might be
incompatible if the fstype of the rootfs changes.
> > 2) In local mountroot(), rather than just mounting the rootfs, loop
> > over all mountpoints in /etc/fstab and mount them.
> If there is no need to mount file systems other than /usr, why do it?
It would permit additional flexibility for initramfs extensions by
users. I'm not sure if this is necessarily a good or bad thing. If
it's desirable not to permit this, I'm sure we can find a better way.
Mounting /usr is obviously the main goal here. Whether or not we
migrate stuff to or from /usr, we would still need to have the ability
to mount /usr in the initramfs for compatibility with systems with a
separately-mounted /usr, in order to privide the guarantee that /usr
is available in early boot.
Mounting /etc separately is not essential, but this would be a nice-to-
have feature for those who wish to encrypt it.
> > and other files to the root filesystem. It additionally permits
> > mounting of /etc separately, thereby permitting it to be
> > encrypted and/or writable while the root filesystem is
> > unencrypted and/or read-only.
> I do not believe that this is desireable, it is complex and would come
> for free anyway by a / -> /usr move.
Why would it come for free? You would still have files in places other
than /etc on the rootfs. And if we are deprecating a separate /usr, it
doesn't solve the problem at all, since everything would be on the rootfs,
and then everything would be encrypted. As mentioned earlier in the
thread, encrypting /etc is an entirely different problem than mounting
/usr separately--a separate mount would IMO be the best solution to this
problem, and mounting it in the initramfs is certainly technically
possible.
Regarding the objections above, which are primarily concerned with the
creation of a non-generic initramfs, how does this alternative suggestion
sound:
- The addition of usr= options analogous to the root= options which
permit the bootloader to specify the /usr filesystem to mount. By
default would do nothing, but grub could be updated to generate
such options on systems with a separate /usr.
- We could also add an additional etc= option with the same semantics.
I'll be happy to implement this if this sounds more acceptable than the
existing approach. It does, I think, address your primary criticisms.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
Reply to: