On Sat, 2011-12-17 at 20:42 +0000, Philip Hands wrote: > On Fri, 16 Dec 2011 14:52:36 +0100, Josselin Mouette <j...@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 directories. 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 myself). [...] > 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. -- Ben Hutchings Computers are not intelligent. They only think they are.
signature.asc
Description: This is a digitally signed message part
