>>>>> Tollef Fog Heen <tfh...@err.no> writes:
>>>>> ]] Ivan Shmakov 
>>>>> Tollef Fog Heen <tfh...@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: news:20111012005824.gc11...@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: news:20111012005824.gc11...@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


-- 
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/864nzdzixm....@gray.siamics.net

Reply via email to