On 04/17/2011 03:34 AM, Simon Geard wrote: > On Sun, 2011-04-17 at 00:26 -0500, DJ Lucas wrote: >> Ahh...lightbulb. This is why we currently have the udev-retry in our >> bootscripts. Are the ids files accessed directly by external programs or >> by the utility libraries/programs? Provide a common library to access >> the files (if not done already) and install into the root and place the >> ids files into the libexecdir, problem solved. > > I don't pretend to follow the details - I'm going mostly by the > statements made by systemd-developer Lennart Poettering on the subject, > in response to some of the more recent arguments on the subject: > > http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken > > Looking on my own system, examples of offending rules seem to be things > like 78-sound-card.rules, which uses the *descriptions* associated with > USB device IDs to classify whether a device is a headphone, microphone, > speaker, etc. A bit hacky, perhaps (and that file admits as much), but I > suppose it's the only way to deal with some hardware. > > As to why that's an issue at boot time, I *assume* that if the id files > aren't present when the hardware is detected on boot, the device won't > be correctly recognised. It won't break the boot, but it will cause > problems when the user tries using their USB speakers or whatever. > > Simon. >
FYI, I'm taking everything said in this thread at face value without really investigating it myself. I've been busy working on the DESTDIR LFS POC. dj [ sources ]$ ls /etc/rcS.d/ S00mountkernfs S03udev S06swap S09localnet S12console S01sysctl S04fuse S07checkfs S10udev_retry S02modules S05setclock S08mountfs S11cleanfs My setup above should be consistent with that of LFS's /etc/rc.d/rcsysinit,d. BTW, just noticed that the fuse devs got FHS broken too, that is their script, not mine. Anyway, udev starts 4th in the startup scripts, it runs across a uevent that uses a rule found in /usr, and it fails to create the device node. The boot process continues, and the rest of the filesystems are mounted, udev-retry replays all of the failed uevents for a second time once all of the required files/programs are in place and the devices are detected and setup as if it were the first time around. Once all uevents are handled, udevadm exits, and the boot process continues. With settle gone, there is no way to *wait* for all uevents to be processed. I would guess that 1 second wait would be way more time than necessary to wait for modern hardware, but how long do we spin for i486? Separate, but local /usr works as expected, now we are still broken WRT to a remote /usr. dj [ sources ]$ ls /etc/rc3.d/ S00sysklogd S02netfs S04haldaemon S06sshd S08samba S01network S03dbus S05cups S07avahi S09gpm In this case, /usr would not be available until 5 scripts later. What happens to those failed uevents? I don't know the answer to that, I would imagine that 'udevadm trigger' could be used again but I don't know for certain. Keep in mind that those devices would never work when booted to runlevel 2, but runlevel 2 is a broken config anyway if you have /usr remote. The upstream devs are certainly correct in saying that no /usr makes all of these problems go away, but I imagine these problems don't exist for the majority of users anyway. At any rate, I'd suggest that we make continue to make provisions for FHS for as long as we possibly can, and still remain compatible with major distros; or until a new major spec comes along that gives us a clear definition. -- DJ Lucas -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
