Re: Merging / and /usr (was: jessie release goals)
On Fri, May 10, 2013 at 10:07:18AM +0200, Marc Haber wrote:
> On Thu, 9 May 2013 18:17:29 +0200, md@Linux.IT (Marco d'Itri) wrote:
> >On May 09, "Bernhard R. Link" <brlink@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
Reply to: