[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: deprecating /usr as a standalone filesystem?

On Mon, May 11, 2009 at 09:20:44AM -0500, Manoj Srivastava wrote:
> On Mon, May 11 2009, Goswin von Brederlow wrote:
> > Henrique de Moraes Holschuh <hmh@debian.org> writes:
> >
> >> On Mon, 11 May 2009, Goswin von Brederlow wrote:
> >>> > A separate /usr *is* the way to go if you don't want any writes in
> >>> > that filesystem 99.9% of the time (i.e. when you're not doing an
> >>> > upgrade).
> >>> 
> >>> A read-only / does the trick just as well. And if you don't want
> >>> writes to /usr you probably don't want writes to /bin or /sbin
> >>> either. So read-only / is really the way to go. Not a strong argument
> >>> for a seperate /usr.
> >>
> >> No, RO / is a lot more difficult to pull off (remember: some of us don't
> >> want initrds), while RO /usr is really just a three-char change on fstab
> >> (and if you want apt to remount things automatically, two lines in a config
> >> file).
> >
> > Why would you need an initrd for a read-only /?
> >
> > A read-only / should work out of the box just like a read-only /usr. I
>         Except it does not.
> > haven't installed a fresh one in a long while though so if you know of
> > problems speak up so bugs can be filed and packages can be fixed.
>         There is the /etc/mtab issue, and then there are things like
>  resolvconf that try to scribble in /etc.  I have not tried recently, so
>  I don't know if there are more blocker.

resolvconf uses /lib/init/rw nowadays, so no /etc writing is needed.

There's a patch for /etc/mtab elimination; it's totally unneeded nowadays.

There may be a few other minor issues, but a read-only root is well in
reach for Squeeze if people try it out and report any remaining cases.

  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.

Reply to: