Re: Merging / and /usr (was: jessie release goals)
On Wed, May 08, 2013 at 08:14:32PM +0200, Marc Haber wrote:
> On Wed, 8 May 2013 17:32:13 +0200, Helmut Grohne <helmut@subdivi.de>
> wrote:
> >On Wed, May 08, 2013 at 12:19:25PM +0200, Philipp Kern wrote:
> >> Fedora updates are different. (And so are Ubuntu updates, if one considers
> >> that it's possible to provide fixup scripts to update-manager pre-upgrade.)
> >> As long as we're supporting upgrades through plain apt, that's going to
> >> be hard. Especially if you have non-distro packages installed that need
> >> to be migrated as well, with the tracking information updated.
> >
> >Maybe the issue here shouldn't be changing the default. After all there
> >is a quite vocal opposition to such a step. I fail to see consensus in
> >the recent mails without even contributing a personal opinion here.
> >
> >So really what does it take to e.g. move /bin and stuff to /usr? Did
> >anyone try that? Where is that documented? What problems did occur?
>
> If we force a much bigger /, the chance of a broken / filesystem
> increases. If / is fine, one has a chance to fix the system without
> booting to rescue. So, a small / both decreases the probability of a
> boot failure and makes fixing breakage easier.
The assumptions here are that a separate rootfs decreases the chance
of breakage, and that you'll need the rootfs to perform the rescue.
Does having two filesystems rather than one decrease the chances, or
increase them? Neither are written to much during normal system
operation, and they can both be mounted read-only. Do we have any
concrete evidence one way or the other here?
Regarding rescue, the initramfs has a rescue shell which I've found
to be just as useful as single user mode. Once it has mounted the
rootfs, you can chroot into that and do whatever you would normally
do to rescue /usr. [Assuming a separate /usr.] If it doesn't get as
far as mounting the rootfs, then you'll need some rescue disc in any
case. I find the busybox shell to be just as effective as a rescue
disc in most cases.
In the case where we're mounting /usr in the initramfs rather than
having it on the rootfs, there's no practical difference to the
current status quo (and this is intentional). The only change is
that we provide the guarantee that /usr is available before init
starts.
> If we change our software so that the system never gets beyond initrd
> stage if mount /usr fails, we increase the change of breaking boot
> because _two_ filesystems need to be fine and mounted before we leave
> initrd.
>
> Both changes are bad from a robustness point of view. Keeping the root
> fs small was a good idea 20 years ago, and it still is.
I think this is primarily just shifting the lines of where
responsibilities are divided. The initramfs is doing part of the job
of what the separate rootfs was doing. If there's a problem, then you
get the rescue shell in the initramfs rather than the rescue shell from
the initscripts/single user mode. In all these cases, the system is
unavailable for normal operations until the problem is fixed.
There was some mention of putting fsck in the initramfs. I'm not
sure whether I really like the idea or not, but from the point of
view of having the tools to fix and mount the rootfs (and /usr) there
when needed, it may well be useful, so long as we can avoid idiocy
such as #701936. We still need the fsck helpers to work for the
non-initramfs case and also not be utterly broken.
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
Reply to: