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

Re: Move all to /usr

>>>>> Tollef Fog Heen <tfheen@err.no> writes:
>>>>> ]] Ivan Shmakov 
>>>>> Tollef Fog Heen <tfheen@err.no> writes:

 >>> (With the assumption that /usr is on a separate fs from /): You
 >>> might very well need to load some drivers (be it network, FC, USB,
 >>> SATA or something else) and probe some bits (iSCSI auth?) to
 >>> actually get to the right block device.

 >> Yes.  But should the system be moved to /usr, the above would still
 >> have to be done before it's mounted.  The only difference is that
 >> instead of having all the software necessary to perform such
 >> initialization on /, we'd have to have them on initramfs — simply
 >> because no software is going to suddenly appear after mounting /,
 >> but before /usr is also available.  (Assuming that /usr is still to
 >> be pointed to from an fstab(5) entry.)

 > Sure, and / might come from FC, USB, SATA, iSCSI or similar too.  A
 > difference is that the initramfs isn't available once you start init
 > in your real /.  The logical conclusion is then to start udev from
 > the initramfs, something we already do.

	Thanks, I wasn't aware of this.

	But it makes the whole idea of moving “everything” below /usr
	even less sensible.  Consider, e. g.:

--cut: [🔎] 20111012005824.GC11988@bongo.bofh.it">news:[🔎] 20111012005824.GC11988@bongo.bofh.it --
And then there is the big argument in favour of it: booting without /usr
is becoming more and more difficult. The two current solutions for this
adopted by udev and the related tools are both suboptimal: waiting in a
loop for /usr to appear can fail due to the timeout (and I wonder when
we will hit the first deadlock), and moving even more stuff from /usr to
/ can work only up to a point.
--cut: [🔎] 20111012005824.GC11988@bongo.bofh.it">news:[🔎] 20111012005824.GC11988@bongo.bofh.it --

	Now, if udev(7) starts to start its scripts while neither of /
	or /usr is mounted, how can moving anything to or from /usr help
	us avoid udev(7) scripts waiting for /some/ «real» FS is

FSF associate member #7257

Reply to: