[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: from / to /usr/: a summary

On Sat, 2011-12-17 at 20:42 +0000, Philip Hands wrote:
> On Fri, 16 Dec 2011 14:52:36 +0100, Josselin Mouette <joss@debian.org> wrote:
> > Le jeudi 08 décembre 2011 à 20:16 +0100, Marco d'Itri a écrit : 
> > > Let's try to summarize the possible configurations and what is needed to
> > > support them:
> > > 
> > > - / and /usr are in the same filesystem
> > >   * no changes are needed
> > > - / and /usr are in different filesystems
> > >   - an initramfs is or can be used and will mount /usr
> > >     * initramfs-tools will be updated, no operational changes are needed
> > >   - the platform does not support an initramfs
> > >     * I am still waiting for somebody to enumerate them, but I believe
> > >       that I can design a suitable workaround
> > >   - the administrator refuses to use an initramfs
> > >     * tough luck for them
> > 
> > After a big week of discussions, I don’t think there have been any valid
> > objections against the scheme you are proposing. It still allows to
> > split / and /usr for various reasons (the most useful one today being
> > encrypting / and not /usr). Once this is done I don’t think there are
> > valid reasons to not move back stuff from / to /usr, either.
> > 
> > The cost is not too high, the number of systems it breaks is extremely
> > small, and the long-term gain is significant.
> I've read all of these threads, but I'm afraid I'm still a little
> befuddled about the pros and cons.
> Pro seems to be saving some effort for packagers when RedHat as
> upstream, say, makes changes that assume /usr is always available,
> that's clear.

This isn't specific to 'Red Hat as upstream'.  It's simply very hard for
a general-purpose distribution to know all executables and libraries
that may be wanted by init scripts and daemons before all volumes are
mounted, and it can be disruptive to move executables between

Red Hat (or the Fedora part of it) has formally decided that it will now
ensure and assume that /usr is mounted before the 'real' init starts,
which removes a lot of the difficulty (and moves some of it into the
initramfs, but that is a much simpler environment).

We're now debating what, if any, effort we should make to continue to
support running init scripts without /usr mounted.  There is also
discussion of whether separate / and /usr partitions should be supported
or deprecated, but I think that's quite separate.

> I'm also wondering: Does this mean that this change compromises our
> ability to recover from a failure that renders a system unable to
> mount /usr for some reason?

Yes, any recovery tools would need to be included in the initramfs or an
alternate boot image (apparently grml is good for this; haven't tried it

> It would be really helpful if someone would spell out the packages that
> have had to be twisted into a funny shape to fit into the current
> scheme, so that the long-term gains we are expecting were then revealed.

nfs-common.  But it will probably end up with funny shaped bits in the
initramfs anyway.


Ben Hutchings
Computers are not intelligent.	They only think they are.

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: