Alexander E. Patrakov wrote:
Below is the incomplete list of things done wrong or incompletely in the
udev_update branch. Here "wrong" doesn't include upstream faults.
Thanks very much for the report Alexander.
1) Udev bootscript doesn't wait for uevents to be fully processed.
OK, I'll add the suggested change to the bootscript, thanks.
2) There is no "udev_retry" initscript. The idea is that, if a program
specified in the "RUN" rule exits with nonzero status (presumably
because it needs /usr), udev places a symlink into /dev/.udev/failed.
The udev_retry initscript should run after mountfs and re-trigger the
failed uevents in hope that they won't fail again.
I really don't think this is necessary. Folks should be knowledgable
enough to realise that calling out to anything on a non / partition may
fail before the mountfs script has run, if /usr is on a separate
partition of course. Obviously, if there are other cases where a rule
may initially fail, then somehow get itself into a working state later
on then I'll reconsider the udev_retry approach. I'm having difficulty
thinking of such a use case though. Only Windows tends to magically fix
itself, and then only after a reboot!
3) Linux-2.6.15 is used, which means that some deices (e.g., IDE CD-ROMs
and input devices) won't get modaliases or won't generate uevents
properly.
There is already a note in the book concerning how to handle devices
whose drivers don't work correctly under udev (i.e.
/etc/sysconfig/modules, etc.).
4) [IRC] The "cdrom" rule in udev-config-5.rules used SYMLINK="cdrom"
instead of SYMLINK+="cdrom", thus killing all other symlinks to the same
device that users may have created.
OK, I'll fix that up, thanks.
Issue with "more than one CD-ROM"
also exists, but has no clear upstream solution (they say: dynamically
generate rules for persistent CD-ROM naming, but provide no
implementation).
Ewww, how does one dynamically generate udev's rules file so early on in
the boot process (no, I don't want an initramfs!).
5) There is no (and will never be) ataraid in 2.6 kernels, please remove
the rule.
OK, will do, thanks.
6) The "mouse" symlink points to the random mouse, it should point to
/dev/input/mice
OK, I'll fix that up too, thanks.
7) The "SUBSYSTEM" in the module-loading rule should be omitted at all.
OK, consider it fixed.
8) Additional rules are needed for loading SCSI cdrom and tape modules.
Yep, Bryan mentioned the mappings of SYSFS types to SCSI modules that
should help out here, right?
Also, there is no firmware loading rule.
Ah, just a minor oversight! Ticket #1672 has the following rule, which
I'll just add to our current `cat` command.
ACTION=="add", SUBSYSTEM=="firmware", RUN+="/sbin/firmware_helper"
9) The text about modules that cannot be loaded by udev is incomplete.
Wrapper modules like snd-pcm-oss and old third-party odules are
mentioned. Modules that don't correspond to any hardware (e.g., loop,
tun, ppp_generic) aren't.
10) "s/hotplug event/uevent/g" due to official renaming of those things.
Thanks, I knew that text would need editing!
11) The deprecated udev_run_hotplugd helper is needed for compatibility
with BLFS (look at HAL).
Why? I thought Kay was actively helping the HAL guys out? Why has he
caused it to break by deprecating the udev_run_hotplugd helper?
make EXTRAS="`echo extras/*/`"
instead of explicitly listing extras.
I'd rather not, as it'll install at least the dasd helper which is
useless on anything other than s390 boxes as far as I can tell.
12) Some other method has to be used instead of /sbin/udevstart to make
nodes needed for the bot loader.
Yep, I think most are in favour of bind-mounting /dev so that BLFS
packages can be built from within chroot too.
13) The need for persistent device naming is not explained (Ticket #1672)
OK, if you could come up with some suggested text it may get fixed
quicker :-)
My personal wish to Matthew Burgess: please patch your kernel with
Suspend2 and try to get it fully working, in order to have a real
motivation to build everything as modules. If done properly, this will
allow you to hibernate your computer as in Win2K/XP.
Well, I'm going to build an 'allmodconfig' kernel once the above changes
are made and see how far through the boot process I get and how much
hardware still works. That should at least expose me to the major problems.
Regards,
Matt.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
