[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 Tue, Jul 16, 2013 at 08:06:27PM +0100, Roger Leigh wrote:
> On Tue, Jul 16, 2013 at 11:25:42AM -0700, Steve Langasek wrote:
> > On Tue, Jul 16, 2013 at 05:07:39PM +0100, Roger Leigh wrote:
> > > - 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.

> > This reflects poorly on the infrastructure in question.

> I'm merely referring to the generalisation of the local/nfs
> scripts to allow mounting of arbitrary filesystems.  There's
> nothing wrong with this this support code.

Yes.  This shouldn't be generalized.  There are only two filesystems that
should be handled from the initramfs: the rootfs, and (optionally) /usr.

> > Handling /etc as a
> > separate filesystem from /, aside from not being a feature anyone else
> > has asked for and not being a requirement for reducing deltas with upstreams
> > / other distros, implies that the initramfs has to have a copy of the
> > information from /etc/fstab.  This is *not* how this should be handled.

> I certainly didn't mean to imply this, because this is not what
> is being done here.  Nothing is stored in the initramfs.

For the /etc-as-separate-mount case, you must be storing this information
either in the kernel boot options or in the initramfs itself.  I don't think
either of these options is a reasonable course of action.  This same problem
is *already solved* by moving the static contents to /usr, making the
toplevel directories symlinks, and keeping /etc on the root filesystem so
that you are not duplicating information between /etc/fstab and the
initramfs (or kernel commandline).  Having /etc as a separate filesystem
adds complexity and introduces inconsistency, without actually expanding the
set of use cases.

> Note that this part was merely added as a proposal only as a
> demonstration of what could be done /if this was desirable to have/.
> If not, then it can be dropped.  It was included solely that it could
> be reviewed.

As you may be able to tell, I feel very strongly that this part should be
dropped.

Cheers,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

Attachment: signature.asc
Description: Digital signature


Reply to: