On Sep 13, 2011 3:16 AM, "Michael Mol" <mike...@gmail.com> wrote: > > On Mon, Sep 12, 2011 at 3:41 PM, Michael Schreckenbauer <grim...@gmx.de> wrote: > > On Monday, 12. September 2011 15:18:53 Michael Mol wrote: > >> On Mon, Sep 12, 2011 at 3:07 PM, Michael Schreckenbauer <grim...@gmx.de > > > wrote: > >> > On Monday, 12. September 2011 14:37:24 Canek Peláez Valdés wrote: > >> >> No fixable, in reality. The flexibility of udev is in part in that the > >> >> userspace can (and actually do) run arbitrary scripts and binaries > >> >> from udev rules. You can "fix" the ones that require binaries in /usr > >> >> *NOW*, but not forever, unless you forbid the use of arbitrary > >> >> binaries from udev rules. > >> > > >> > Why do you need to run arbitrary scripts to mount /usr? > >> > >> It's not specifically that you need to run arbitrary scripts to mount > >> /usr. It's that it's unknown that /usr must be mounted before some > >> hotplug events are handled. > > > > Claiming "this is not fixable... unless you forbid the use of arbitrary > > binaries from udev rules" implies, that you need to run arbitrary scripts to > > mount /usr. > > No, it states that it's not solveable for the broadest set of cases (I > hesitate to say 'universally') unless you can run arbitrary scripts > which may be in /usr. > > Consider it possible that nfsd is needed to mount /usr. The > credentials needed for NFS to connect to the server are on an > encrypted partition. The key for decrypting that partition is stored > on a USB flash drive. The USB flash drive is formatted using a very > recent version of NTFS. FUSE is necessary to read that flash drive's > filesystem. > > In this scenario, the NFS binaries and FUSE binaries are located under /usr. > > It's this kind of scenario that falls under the general class that > udev's trying to solve. If I understand it properly, the mentality is, > "I can't forsee what distros and sysadmins will want to do, I get bug > reports when peoples' configurations fail because they were trying to > load things from unmounted filesystems, so if I say the filesystem > *must* be mounted (or they must use an initramfs) in order to use > udev, those bug reports will solve themselves." > > > Otherwise a fix would be to mount /usr with whatever is needed to > > do this and then run the arbitrary scripts. Sadly udev does not support this. > > Which requires some kind of dependency or retry scheme, which adds > complexity to udev that the Fedora dev decided he didn't want to spend > the time on. > > -- > :wq >
Hmmm... after reading Michael (non_grimlog)'s explanation, I'm starting to understand udev's dev's thoughts. It seems too many people (mis)use udev to execute something in /usr while at the same time using a separated /usr that needs to be mounted first. Too many people are perhaps too lazy to RTFM, and blame the resulting boot failure to udev. Understandable, but his way out is instead by forcing a 'way of life' that's incompatible with what many sysadmins (especially Gentoo sysadmins) are familiar with. So the solution IMO should be: * Keep udev as it was before (i.e., living in / instead of in /usr) and somehow make sure that everyone RTFM/RTFFAQ, or * Make two versions of udev, one which lives in / for those who've done their homework, and another version in /usr for the ignoramuses Users of 'Technical Distros' like Gentoo can choose between root-udev or usr-udev, while 'Less Technical Distros' can just use usr-udev out-of-the-box. Rgds,
