Re: deprecating /usr as a standalone filesystem?
"Giacomo A. Catenazzi" <email@example.com> writes:
> Gabor Gombas wrote:
>> On Thu, May 14, 2009 at 03:53:23PM +0200, Giacomo A. Catenazzi wrote:
>>> No, /root cannot be a separate filesystem.
>>> /root is part of very basic system, and it is required for super user
>>> when he/she is restoring the systems or doing some kind of administration
>>> (e.g. moving filesystems, etc.).
>> Obviously not. If fscking "/" fails then "/" _will_ be read-only and you
>> _must_ be able to fix it without being able to write under /root, so any
>> system restoration task must work without /root being writeable.
>> If you want to write to /root, then _make_ it writable! That's why you
>> are the system administrator after all. If you want "/" to be read-only,
>> then move /root to some other filesystem. If you want /root to be on the
>> same filesystem as "/", then do not make "/" read-only. Really, this is a
>> "Doctor, it hurts if I shoot myself in the foot - Don't do it, then"
>> kind of situation...
> I totally agree that / (thus /root) could be read-only.
> I pointed out to you that /root is required to be in the same
> filesystem as / (FHS) and I gave you the rationale.
> I really prefer to allow / and /root read-only than to allow
> /root in a different filesystem (user could do also this choice,
> but outside debian support cases).
There is absolutely no reason why you can not mount a filesystem over
/root later in the boot process. I agree that /root should/must exist
at all time so one can login when for example fsck fails. But that
works perfectly fine with /root being an empty directory on / and
later having a filesystem mounted there.
So I would be against /home/root, as one would have to create that on
/ before /home gets mounted so it is always available. That kind of
shadowed directory is harder to create for DI and wouldn't show up in
a backup and be missing after a restore. I would rather bind mount
/home/root to /root to make /root read-write.