On Mon, Sep 12, 2011 at 1:17 PM, Alan Mackenzie <a...@muc.de> wrote: > On Mon, Sep 12, 2011 at 05:33:34PM +0200, Michael Schreckenbauer wrote: >> On Monday, 12. September 2011 15:02:48 Alan Mackenzie wrote: > >> > Hope nobody minds me starting a new thread with an accurate name. > >> > Which version of udev is it that has this nauseating feature of needing >> > /usr loaded to boot? > >> > Somewhere in that version's source will be several (or lots of) "/usr". >> > Just how difficult is it going to be to replace "/usr/bin" with "/bin" >> > throughout the source? > >> you misunderstood something. udev is able to run arbitrary scripts. Some of >> those scripts are located in /usr/* or need something there. I doubt you will >> find references to /usr in the udev-sources. > > Well, I'm a hacker. udev is free source, therefore fair game. I don't > intend to put up with this nonsense without a fight. As far as I can > make out, this is just one guy, Kay Sievers, who's on a power trip. Are > there any indications at all that he actually talked to anybody in the > wide world before making such a far reaching decision?
udev has always been able to run arbitrary scripts. The trouble is that the arbitrary scripts other packages provide sometimes call for things under /usr. If I've read messages over the last couple days correctly, I think the recent change is that some stuff udev *directly* depends on, as part of the udev package itself, is being moved into /usr. My best guess is that this allows udev to force the issue; it gets blamed for other packages not loading correctly (when those other packages put things in places which may or may not be available yet), so the udev developer chose to force systems to have all of /usr available before udev is run. The first step in a clean solution, IMO, is to revert that change. The second step is to fix the 'silent failure' problem for packages which depend on /usr before /usr is available. You might do it with a dependency tree which would control the order things are done, but some packages may not be able to know what they depend on. (take dhcpd, for example; it doesn't know what kind of weird magic someone else put in exit-hooks) Another solution would be to have a retry queue like what Schreckenbauer (sorry; too many Mikes) was suggesting. It might be difficult to discern a rulescript failure that stems from another rule needing to be run first versus a rulescript failure that stems from, e.g. a syntax error. -- :wq
