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

Re: Move all to /usr

>>>>> unruh  <unruh@wormhole.physics.ubc.ca> writes:
>>>>> On 2011-10-12, Marco d'Itri <md@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.


FSF associate member #7257

Reply to: