Re: [Fwd: Can you help with a problem posting to lfs-dev & a patch for 6.2?]
Hi Bryan, Yup - got my email addresses tied in a knot again On the udev patch I'm suggesting changing the standard definitions, since the patch has the same functionality on a standard system, but also works within an initramdisk/initrd so when somebody like me comes along and wants to modify LFS to use an initramdisk/initrd they can avoid a lot of grief getting confused by udev . Cheers, Tony. Bryan Kadzban wrote: Bruce Dubbs wrote: Original Message I've checked my mail server logs and everything seems to be being sent successfully, but I don't see a copy of the email (I've requested copies in my options), my posts don't appear in the archives and nobody responds to me!!! Could you forward this to somebody who could help, or tell me who I should contact? I've seen this happen when the From: address in the email that I send is not the address that I've subscribed with. Regarding the udev change -- Since you're getting the same result, it shouldn't matter. I don't think, anyway -- if you want to be really sure, then adopt your change inside the initramfs (since nothing in there uses libusb), and leave the LFS system rule the way it is. Yes, that's a bit of a pain, but it'll definitely work. ;-) -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [Fwd: Can you help with a problem posting to lfs-dev & a patch for 6.2?]
Hi Dan,
Spent some time looking at this more closely, and it looks like it's a
little more subtle than I originally thought. The problem is that the
busybox shell evaluates the environmental variables slightly differently
than the normal shell. The result is that for %k = usbdev1.2
X=%k X=${X#usbdev} B=${X%%.*} D=${X#*.}; echo bus/usb/$B/$D
produces
bus/usb//
X=%k; X=${X#usbdev} B=${X%%.*} D=${X#*.}; echo bus/usb/$B/$D
produces
bus/usb/usbdev1/2
X=%k; X=${X#usbdev}; B=${X%%.*} D=${X#*.}; echo bus/usb/$B/$D
produces
bus/usb/1/2
Thus the smallest change is the third version adding the two ;'s. This
behaviour seems fairly consistant across a number of versions of busybox
including the most recent stable version and the current development
version. I'm tempted to say this is a bug in busybox's shell so I'll
post there, but I'd still suggest making the change to the udev rules to
cover all the angles.
Cheers,
Tony.
Dan Nicholson wrote:
On 7/13/06, Bruce Dubbs <[EMAIL PROTECTED]> wrote:
From: Anthony Wright <[EMAIL PROTECTED]>
The udev-config rules do not work with the busybox /bin/sh, the patch
below corrects this.
[snip]
diff --new-file -urp udev-config-20060515.orig/25-lfs.rules
udev-config-20060515/25-lfs.rules
--- udev-config-20060515.orig/25-lfs.rules2006-05-03
06:19:59.0 +0100
+++ udev-config-20060515/25-lfs.rules2006-07-11
14:28:11.0 +0100
@@ -84,7 +84,7 @@ KERNEL=="djs",MODE="0644"
# USB devices go in their own subdirectory
-SUBSYSTEM=="usb_device", PROGRAM="/bin/sh -c 'X=%k X=$${X#usbdev}
B=$${X.*} D=$${X#*.}; echo bus/usb/$$B/$$D'", NAME="%c"
+SUBSYSTEM=="usb_device", PROGRAM="/bin/sh -c 'echo %k | /bin/sed
s-usbdev-bus/usb/- | /bin/sed s-\\.-/-'", NAME="%c"
KERNEL=="hiddev*",NAME="usb/%k"
KERNEL=="auer*",NAME="usb/%k"
KERNEL=="legousbtower*",NAME="usb/%k"
Tony (if you get this), do you know why that command fails with
busybox /bin/sh? Seems one thing that's kind of shady is that X is
setting and referencing itself in the same command. The command right
now is (in shell)
X=%k X=${X#usbdev} B=${X%%.*} D=${X#*.}; echo bus/usb/$B/$D
It seems safer to me if it was
X=%k; X=${X#usbdev} B=${X%%.*} D=${X#*.}; echo bus/usb/$B/$D
Notice the semicolon after the first X=. In fact, that's consistent in
the other distros if they're using the rules distributed in the udev
tarball (RedHat does).
Actually, it seems that all the distros are also using printf instead
of echo, but that's probably not important here.
Would you try out the above fix on busybox? Even the horrid /bin/sh on
our HP-UX server at work could handle that. I'm curious what part of
the commands busybox /bin/sh can't handle.
--
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [Fwd: Can you help with a problem posting to lfs-dev & a patch for 6.2?]
Sounds good to me... Yeah! I've successfully contributed a whole
semi-colon to LFS :-)
Alexander E. Patrakov wrote:
Anthony Wright wrote:
X=%k; X=${X#usbdev}; B=${X%%.*} D=${X#*.}; echo bus/usb/$B/$D
produces
bus/usb/1/2
Let's go with it then.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Udev incorrectly generating entries in /dev/.udev/failed
When udev tries to create entries in some cases it uses modprobe, and if this fails it causes an entry to be created in /dev/.udev/failed/ However, this only works correctly if your device drivers are installed as modules, if the device driver is compiled into the kernel rather than being a module, the modprobe fails and udev thinks there's a problem when there isn't. As a result I have 35 entries in /dev/.udev/failed/ a large number of which I believe are falsely generated, and since I want to use a monolithic style kernel it's going to be very difficult spotting the devices that are really failing from the falsely reported ones. The example I used was the usb/host/uhci-hcd.ko driver. If I have this compiled into the kernel I have 35 entries in /dev/.udev/failed/, if I compile this as a module I have 31 entries in /dev/.udev/failed/, the four entries which no longer exist are all handled by uhci-hcd (I have 4 USB hubs in the machine). I know that in both cases the uhci-hcd driver is working correctly because without it, all the other usb entries dissappear - I did an rmmod when it was compiled as a module, and my entry count went down to 21. I'm sorry I don't have a fix for this as I'm still trying to work out how the device driver selection and loading system works If I work out a fix I'll post it but don't hold your breath. Tony Wright. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Udev incorrectly generating entries in /dev/.udev/failed
Alexander E. Patrakov wrote:
Anthony Wright wrote:
When udev tries to create entries in some cases it uses modprobe, and if
this fails it causes an entry to be created in /dev/.udev/failed/
Ignore the issue. It is prsent in all distros. Of course, this is
fixable by replacing the current modprobe rule with the following:
ACTION=="add", ENV{MODALIAS}=="?*", RUN+="/bin/sh -c '/sbin/modprobe
$env{MODALIAS} || true'"
(and similar changes to other rules) but I consider calling /bin/sh a
bloat.
The problem with the change you're suggesting is that it will always
return true, so no entries will be created in /dev/.udev/failed/, even
if an entry should exist because the device doesn't have a driver either
in the kernel or a module.
Can I suggest changing the modalias.rules file to replace the first
modprobe entry with the entry below, and with similar changes to the
SCSI modprobes in the same file. It performs the modprobe as before, but
then returns success or failure based on whether, after the modprobe,
the device has a driver according to the /sys filesystem. This means it
works with drivers built into the kernel as well as with modules.
ACTION=="add", ENV{MODALIAS}=="?*", RUN+="/bin/sh -c '/sbin/modprobe
$$MODALIAS ; [ -e /sys$$DEVPATH/driver -o -e /sys$$DEVPATH/device/driver
] '"
I appreciate this is somewhat more complex than the original, but the
additional complexity is relatively minor and the result is a
/dev/.udev/failed/ that is correct. This change removed more than half
the entries in my /dev/.udev/failed/.
Please note the replacement of $env(MODALIAS) with $$MODALIAS, this is
because the udev program_run buffer is only 255 bytes long, and some of
the modalias strings for serio devices are very long causing the buffer
to overflow.
Tony Wright.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Udev incorrectly generating entries in /dev/.udev/failed
Alexander E. Patrakov wrote:
Anthony Wright wrote:
ACTION=="add", ENV{MODALIAS}=="?*", RUN+="/bin/sh -c '/sbin/modprobe
$$MODALIAS ; [ -e /sys$$DEVPATH/driver -o -e
/sys$$DEVPATH/device/driver ] '"
This is indeed too long. Maybe (untested, relies on obsolete
PHYSDEVDRIVER variable, will certainly break with linux-2.6.18):
ENV{PHYSDEVDRIVER}=="?*", GOTO="driver_already_loaded"
ACTION=="add", ENV{MODALIAS}=="?*", RUN+="/sbin/modprobe $env{MODALIAS}"
#
LABEL="driver_already_loaded"
Hi Alex,
I tried this out, and it gives the same results as my modification which
I verified as the results I would expect. So from that perspective it
does the job and it's a simpler change, but if it's an obsolete
environmental variable that's going to dissappear in the near future it
seems a little pointless to start using it. Having said that, I did
notice that it's still used in the udev-096 (current version) examples.
I therefore had a wander through udev, and found a 'DRIVER' rules
keyword which looked hopeful, however when I tried to use it I got
different results from what I believe should be the 'correct' contents
of my /dev/.udev.failed/ directory. I wandered through the code of udev
and isolated this down to the way the DRIVER keyword seems to work
(couldn't find any documentation). The keywords seems to ignore the
driver of the device it's actually being applied to, and instead tries
to match against the device's parent devices' drivers (parent,
grandparent, great-grandparent etc).
For example I have an integrated usb hub to which an integrated usb
bluetooth card is attached. The usb hub uses the uhci_hcd driver while
the bluetooth card doesn't have a driver. However the DRIVER keyword
will match true for uhci_hcd on the bluetooth card, but won't match
anything on the usb hub, so that if I use a rule DRIVER=="?*" in place
of the PHYSDEVDRIVER the usb hub ends up in /dev/.udev/failed/ while the
bluetooth card doesn't.
I would have gone as far as to say this is a bug in udev, but udevinfo
seems to suggest this is desired functionality as it won't report a
driver for the device you request information on, but it will supply the
driver for it's parent devices. However, this now means I simply don't
understand what the purpose of the DRIVER keyword is, even though I see
a few people using it.
I'm not quite sure what the best way to progress from here is. Using my
original approach works, but it's ugly. You're approach is more elegant,
but it going to obselete very shortly. Using the DRIVER keyword instead
would be nicer, but it's either buggy and needs to be fixed or is
intended for another purpose. Maybe it's a request for a change in udev
to supply a new keyword. Finally we just forget about the whole thing
because it's not a big enough problem.
I'd appreciate your thoughts on this (and anybody else who feels like
chipping it :)
Sorry if I'm being stupid here, I'm trying to get to grips with linux's
device management system, and at the same time fix something in LFS
which is annoying me.
Cheers,
Tony.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
udev.rules - /dev/cdrom is not longer created
In LFS 6.1.1 the device /dev/cdrom is created during boot. In the
current version it is no longer created. It's not a required device, but
it is fairly useful as it avoids programs having to hunt around the
block devices trying to work out which is the cdrom, and it's a simple
change to put it back.
In the 81-cdrom.rules file change:
ACTION=="add", SUBSYSTEM=="block", ENV{ID_TYPE}=="cd", GROUP="cdrom"
to
ACTION=="add", SUBSYSTEM=="block", ENV{ID_TYPE}=="cd", GROUP="cdrom",
SYMLINK="cdrom"
Cheers,
Tony.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: udev.rules - /dev/cdrom is not longer created
Alex Merry wrote: On Fri, Jul 28, 2006 at 01:02:51AM +0100, Anthony Wright wrote: In LFS 6.1.1 the device /dev/cdrom is created during boot. In the current version it is no longer created. It's not a required device, but it is fairly useful as it avoids programs having to hunt around the block devices trying to work out which is the cdrom, and it's a simple change to put it back. Heh - there was a lot of discussion about cd symlinks (among other things) several weeks back. The end result is the following page: Oops missed that one, thanks. Tony. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Udev incorrectly generating entries in /dev/.udev/failed
Anthony Wright wrote:
Alexander E. Patrakov wrote:
Anthony Wright wrote:
ACTION=="add", ENV{MODALIAS}=="?*", RUN+="/bin/sh -c '/sbin/modprobe
$$MODALIAS ; [ -e /sys$$DEVPATH/driver -o -e
/sys$$DEVPATH/device/driver ] '"
This is indeed too long. Maybe (untested, relies on obsolete
PHYSDEVDRIVER variable, will certainly break with linux-2.6.18):
ENV{PHYSDEVDRIVER}=="?*", GOTO="driver_already_loaded"
ACTION=="add", ENV{MODALIAS}=="?*", RUN+="/sbin/modprobe $env{MODALIAS}"
#
LABEL="driver_already_loaded"
Having given this some more thought, below is a modified version of my
original suggestion. It's based on Alexander's suggestion so has a lot
less impact on the 26-modprobe.rules file (it adds two lines), but
rather than using the potentially obselete ENV(PHYSDEVDRIVER), it tests
for a link from the device to a driver in the /sys filesystem. It's a
bit ugly, but it's the closest I can get without adding a new directive
to udev. It does the job correctly and the test are similar to how udev
would implement an internal directive.
ACTION=="add", PROGRAM="/bin/sh -c '[ -e /sys$$DEVPATH/driver -o -e
/sys$$DEVPATH/device/driver ]'", GOTO="driver_already_loaded"
ACTION=="add", ENV{MODALIAS}=="?*", RUN+="/sbin/modprobe $env{MODALIAS}"
#
LABEL="driver_already_loaded"
Cheers,
Tony.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
