On Tuesday, September 13, 2011 04:49:25 PM Neil Bothwick wrote: > On Tue, 13 Sep 2011 11:21:22 -0400, Walter Dnes wrote: > > > This is why the whole /usr issue is irrelevant and not a fix at all. > > > All it does is avoid the most common breakages caused by udev trying > > > to run all its rules too early in the boot process. Putting /var on > > > / > > > would "fix" your example, but what if a rule required access to an > > > NFS mount? > > > > > > Every time you fix one of these breakages, you are kludging around > > > the > > > real problem. > > > > > How many people really need to run *ARBITRARY* binaries that early > > in > > > > the boot process? The 1% who do shouldn't force the other 99% of us to > > go with initramfs or a Windows C:\ drive. > > There is no 1%. The problem is that udev is able to run arbitrary > binaries, which has its advantages, but it also has to be started early > in the boot process to fulfil its other duties. It is trying to combine > these two functions that leads to the need for more than / to be > available before filesystems are mounted.
And these 2 capabilities should be handled by different processes. Process 1: Populate the /dev-tree Process 2: Run scripts when necessary Process 2 should NOT be started untill after the local filesystems are mounted. I have not seen any realistic use-cases where process 2 should be started sooner. Any script/tool/program that is required to get to the stage where process 2 can run should be either in "/" or in an init*. Eg. for the use-case where fuse, ntfs-3g, nfs, crypt-setup,.... are needed to mount the local filesystems, go build an init* and let the rest build more sane environments. -- Joost
