On Wed, May 08, 2013 at 08:14:32PM +0200, Marc Haber wrote: > On Wed, 8 May 2013 17:32:13 +0200, Helmut Grohne <hel...@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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130509113347.gr21...@codelibre.net
