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
mounted?
--
FSF associate member #7257
Reply to: