On Fri, May 10, 2013 at 10:07:18AM +0200, Marc Haber wrote: > On Thu, 9 May 2013 18:17:29 +0200, m...@linux.it (Marco d'Itri) wrote: > >On May 09, "Bernhard R. Link" <brl...@debian.org> wrote: > >> Or in other words: to make essential functionality not available if > >> /usr is broken. > >Again: this is not we are discussing. Essential functionality is moving > >to /usr anyway > > Which is a really really bad thing. Some anonymous upstream is forcing > us to decrease the reliability of our systems. I really hate that > idea.
Don't we all. But it has already hapened. > >> Having a seperate / means you have an instant rescue image that has > >> just the right kernel and tools you need to repair the rest of your > >> system. > >OK, so you could have an even *smaller* / with a *real* independent > >rescue image like grml in /boot. > > Having the rescue image _this_ independent is not really desireable > since one would probably have to deal with outdated or non-existing > rescue tools in the independent image while the correct software in > the correct version is on the system's own / file system. Or you would have a known working and good version of tools while the system (being unstable) might have any number of bugs in them. Note: The rescue image could be dynamically generated on updates or come as prebuild images. Or you could have both. And a stable and latest flavour on top. The rescue image will be no more out of date than any other package in debian. > >> You also have one small filesystem with all the important > >> stuff like /etc in it while the boring large distro stuff is in > >> another partition. You also have a partition border between > >> most of the random stuff and the important stuff. > >Indeed, if the content of /{bin,sbin,lib} is moved to /usr you can have > >a small filesystem with all the important stuff like /etc in it and the > >boring large distro stuff (like 100 MB of kernel modules for each > >kernel, currently in /lib) in another partition. > > But I'll have the fsck version that is guaranteed to fit my /usr file > system in the big /usr file system, so I'll be forced to use an fsck > from a rescue image which might not be the current one, possibly > causing even more damage. > > Greetings > Marc Fsck is in the initramfs (added combined with the mnount /usr patches) so you can fix your /usr and even your / from there already. Has anyone actualy compiled data about fsck problems respective to filesystem size? I can't remember EVER having a fsck problem with /usr ever since I switched to keeping it read-only. And that was somewhere in early 2.4.x times. MfG Goswin -- 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/20130513123820.GH8366@frosties