Opened 15 years ago

Closed 15 years ago

#2525 closed enhancement (fixed)

Udev-149

Reported by: Matthew Burgess Owned by: Matthew Burgess
Priority: normal Milestone: 6.6
Component: Book Version: SVN
Severity: normal Keywords:
Cc:

Description

New version. Release announcement at http://marc.info/?l=linux-hotplug&m=125975590716511&w=2.

Change History (11)

comment:1 by Bryan Kadzban, 15 years ago

Note that this includes a couple of relevant changes...

First, the mode on the create_floppy_devices program call is now correct (it matches the MODE="..." set on the main /dev/fd0 device).

But second, all the rules that manage /dev/hd* (required if you use CONFIG_IDE* in your kernel configuration, or at least I think that's the right setting) have been yanked. See http://article.gmane.org/gmane.linux.ide/43151 for the rationale, and note that apparently "deprecated" means "we don't have to do *ANYTHING* correctly here anymore", not "this will disappear in a few kernel releases, once we get the users that *require* it moved". The latter is what was actually said; the former is what the udev maintainers did. Sigh.

Anyway, we can add those rules back into a compat file if we decide we need to. I know libata works quite well for me, but that doesn't count for much if you're one of the people that has one of the 2 unsupported-by-libata disk controllers...

comment:2 by Bryan Kadzban, 15 years ago

Wait, no, that's not all.

The DRI ("card*") and device-mapper ("dm-*") rules in 55-lfs.rules both specify OPTIONS+="ignore_device". That's gone now as well, so I suspect the rules won't parse. (Either that, or users will get nastygrams in their log files.) We need to kill those rules. Unfortunately I don't have a DRI setup (nvidia here), so I don't know what kinds of issues removing that rule will cause.

I do, however, have a device-mapper setup; removing that rule is one of the steps required to get the (very very recent) LVM package's udev rules to work properly. See http://www.linuxfromscratch.org/hints/downloads/files/Root_FS_on_RAID+encryption+LVM.txt for the steps required as of whatever LVM2 version I last tried. (2.02.53 it looks like.)

Last, I think it's about time to do another audit for duplicated rules. I believe a bunch of them (ALSA, specifically) are now available from upstream...

comment:3 by Matthew Burgess, 15 years ago

Thanks Bryan. I grepped through our rules files for the other changes mentioned in the announcement but missed the ignore_device one!

I don't think we should do anything immediately for the /dev/hd* issue. The chances are that our userbase is so small that noone has either of the 2 controllers that currently aren't supported by libata. Obviously, if someone reports a bug, so be it, we'll fix it then.

We're in a somewhat better position than most distributions here as our user's are expected to be able to configure /etc/fstab and friends correctly and move with the wishes of upstream developers on a much quicker timescale than most regular distros.

I'm giving udev-148 a try now so will know if it parses ignore_device at all shortly!

comment:4 by Matthew Burgess, 15 years ago

OK, signs aren't good so far. I've rebuilt udev-148 on top of my existing LFS and the bootscript just hangs starting Udev up. I put it in debug mode and it shows it is adding devices but then just hangs after adding them all.

If someone else could confirm please, that'd be great. I'll continue to look here and see if I can figure out what's going on.

comment:5 by Matthew Burgess, 15 years ago

Posted too early/too impatient:

udevadm settle - timeout of 180 seconds reached, the event queue contains:
  /sys/devices/virtual/input/mice (579)
udevd[536]: worker [554] unexpectedly returned with status 0x0100
udevd[536]: worker [554] failed while handling '/devices/virtual/input/mice'

in reply to:  5 comment:6 by Matthew Burgess, 15 years ago

Replying to matthew@…:

Posted too early/too impatient:

udevadm settle - timeout of 180 seconds reached, the event queue contains:
  /sys/devices/virtual/input/mice (579)
udevd[536]: worker [554] unexpectedly returned with status 0x0100
udevd[536]: worker [554] failed while handling '/devices/virtual/input/mice'

Reported upstream at http://marc.info/?l=linux-hotplug&m=125982017705268&w=2 and fixed by http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=22f9cb51c39a6fef1109bfd24e97d2fdda327a9e.

I'd imagine a new release will be out shortly. If not, I'll roll that commit into a sed for the book.

comment:7 by Matthew Burgess, 15 years ago

Scrap that; it's obviously not applicable to LFS as it's in the 'extras' directory. That's what I get for building on top of an existing LFS base, and thereby enabling the extras! That said, it's probably worth holding out for a new release anyway, as we don't want to trap users who decide to rebuild Udev post-LFS and therefore end up with a broken setup.

comment:8 by Steffen Pankratz, 15 years ago

Udev-149 is out now, which fixes the problem Matthew experienced:

http://marc.info/?l=linux-hotplug&m=125984922007603&w=2

in reply to:  7 comment:9 by Bryan Kadzban, 15 years ago

Summary: Udev-148Udev-149

Replying to matthew@…:

Scrap that; it's obviously not applicable to LFS as it's in the 'extras' directory.

I don't think that's entirely true. The path_id, ata_id, cdrom_id, scsi_id, usb_id, and maybe v4l_id programs, for instance, are all in extras as well, but are all normally built during LFS.

The --disable-extras udev configure flag only turns off extras that also have external dependencies (and as long as you provided that flag during your rebuild, you still turned off all of those: it's a static list). That's stuff like udev-acl, gudev, etc.

That said, it's probably worth holding out for a new release anyway,

Definitely. And since the new release is out, updating the summary. :-)

comment:10 by Matthew Burgess, 15 years ago

Owner: changed from lfs-book@… to Matthew Burgess
Status: newassigned

comment:11 by Matthew Burgess, 15 years ago

Resolution: fixed
Status: assignedclosed

Fixed in r9128. We still probably want to review the udev-config rules at some point, but LFS boots with the current configuration.

Note: See TracTickets for help on using tickets.