On Monday, September 12, 2011 04:07:46 PM Michael Mol 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.
Since when does NFS need credentials to connect to the server? :) also, why use NTFS on a flash-drive storing the keys, this is simply an example of someone trying to be clever and being far too lazy to properly implement it. It should fail and the error message should read: "PEBKAC" (Problem Exists Between Keyboard And Chair) > 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." In other words, this dev has a god-complex and feels he should fix all that is wrong in this world. He should do his job and fix his error-reporting and documentation to specify that EITHER the people demanding this ensure the scripts run by udev will work with only "/" mounted or ensure all other required partitions are mounted by init*. Not force all partitions to be available when "init" starts. > > 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. Fixing the docs and error-reporting is the logical and least invasive option. -- Joost
