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

Re: deprecating /usr as a standalone filesystem?

Manoj Srivastava <srivasta@debian.org> writes:

> 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.

I said should. :) Last I set one up it still needed some assembly but
that is being worked on. It is certainly within reach for Squeeze.

>> 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

The /etc/mtab problem is finaly solved for all cases (like quota
users) with kernel >2.6.26. There is a bug report about it and that is
hopefully soon to be made to work out of the box. No assembly required
then anymore.

Resolvconf uses /lib/init/rw so that isn't a stoper anymore.

ifup/down has some code for read-only / in it too.

>  I don't know if there are more blocker. Oh, and /root is a home
>  directory; unless we move that,  a read only / would affect root
>  negatively.

How so? Only thing I can think of is the bash history. But it is not
like we force a read-only /. That is a choice.

>         A read-only / would be nice, but unless you try it on a real
>  box, I don't think you assert it should be working out of the box.

I'm sure there are some packages out there that still don't work right
with read-only /. But none I use and thuse none I know about. As far
as I know the /etc/mtab issue is the last pending thing.

>         manoj


Reply to: