>>>>> unruh <un...@wormhole.physics.ubc.ca> writes:
>>>>> On 2011-10-12, Marco d'Itri <m...@linux.it> wrote:
[…]
>> So let's look at the reasons against merging /usr in / listed in my
>> final summary. All of them do not apply to merging / in /usr, and
>> actually become arguments in favour of doing it:
>> - NFS: sharing a read only system over NFS becomes much easier (I
>> would say that it actually becomes possible...)
> And if NFS happens for whatever reason, be down when you try to mount
> /usr, you have a useless system since you can do nothing with it.
One still would have an initramfs instance.
Also, this one is, AIUI, concerned primarily with system-on-NFS
setups. Typically, these aren't of much use without /usr
mounted anyway.
The point is that currently, if there's a system which relies on
/usr on NFS, the administrator has to somehow keep its / in sync
with /usr. One can't just # chroot /nfs apt-get upgrade on the
NFS server now, for that'd mean that (local) / is out of sync
with (NFS mounted) /usr. With all the system residing below
/usr, it suddenly becomes much a less hassle.
>> - junk hardware: while moving /usr to / may not be possible due to
>> the small size of the root partition, moving / to /usr will be easy
>> - read only system: more parts would be read only
> ? Surely you can make whatever you want read only now.
With all the sort of software continuously writing to /etc/?
Consider, e. g., /etc/blkid.tab, which is updated almost every
time a removable media is connected to the system. Or
/etc/mtab. Or /etc/lvm/cache/.
[…]
> It is completely unclear what is pushing this proposal.
The problem, AIUI, is that we start udev(7) before /usr is
mounted. As udev is prone to spawn all the sorts of software in
turn, we're either going to move more and more from /usr to /,
/or/ to invent more kluges so that udev scripts would actually
wait for /usr to be mounted. Both are indeed valid issues.
I don't know for sure /why/ udev(7) should precede /usr in the
boot order, though. Could someone clarify on that?
> Also initrd or initfsrd both make things far more obscure--it seems
> to me it becomes more difficult to figure out what your boot is
> doing, and how to fix it when things break. And sometimes things
> break.
Yes.
--
FSF associate member #7257
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/86botm25xy....@gray.siamics.net
