On Tue, 2010-07-27 at 15:28 +0000, Steve Langasek wrote: > As I wrote in comment #15, we don't have a viable workaround yet that > doesn't inroduce other hangs / failures in other scenarios.
I guess the question then is whether any effort is being spent towards such a solution. > A "fix" > that will break all ability to further upgrade the system is worse than > the status quo, because it means security fixes can't be applied. Fair enough. But leaving systems unbootable for a portion of the users surely cannot be an acceptable solution either, yes? > Until someone is able to identify a solution that doesn't have this > disadvantage, there's nothing that can be done here. Who would this "someone" be? It's sounding an awful lot like nobody is actually working on the real root cause (and solution) of this issue and everyone is just hoping that "somebody else" will come up with a solution. > "stable" does not mean "usable for all proposed uses". So having a /var on a separate filesystem is "fringe" enough that those users should not be able to experience a stable system? /var on it's own filesystem is the only "responsible" way to manage a system. You can glom any other crap you want onto / but leaving /var on / to grow until it fills up / is simply irresponsible for any use-case except single-user machines. Is this "single-user" use case all that Ubuntu is interested in satisfying? Multi-user/server (i.e. corporate users) installations are not a useful user-base for Canonical? -- mountall for /var races with rpc.statd https://bugs.launchpad.net/bugs/525154 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
