Bug 163438
Summary: | Updated udev package required to create symlinks | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Robert Nichols <rnichols42> | ||||
Component: | kernel | Assignee: | Harald Hoyer <harald> | ||||
Status: | CLOSED ERRATA | QA Contact: | Brian Brock <bbrock> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | 3 | CC: | davej, jheiss-bugzilla, notting, stern, wtogami | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | i686 | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2005-10-25 07:46:18 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | 158570 | ||||||
Bug Blocks: | |||||||
Attachments: |
|
Description
Robert Nichols
2005-07-16 16:43:55 UTC
Harald, let me know the version of the fixed package, and I'll add this to the dependancies in the next update (which should be sometime next week). well, Dave, udev-058 would require hotplug from FC4, which would require initscripts from FC4, which would require SysVinit from FC4... I thought it was the FC5 devel udev that is the one dragging in the world; the FC4 udev at least doesn't have obvious requires for newer stuff. without the hotplug from FC4, I do not get symlinks with udev... How would hotplug affect symlinks with udev? I'm not sure where it would even get in the way. The problem is that udev-039 isn't following the chain of parent directories when looking for sysfs attributes. It reads the directories corresponding to the class device and the actual device but doesn't go up. Probably because (as noted in the release notes for udev-058) sysfs no longer supplies the useless "detach_state" file. Here's an example from my system: $ udevinfo -a -p /sys/block/sr0 udevinfo starts with the device the node belongs to and then walks up the device chain, to print for every device found, all possibly useful attributes in the udev key format. Only attributes within one device section may be used together in one rule, to match the device for which the node will be created. looking at class device '/sys/block/sr0': SYSFS{dev}="11:0" SYSFS{range}="1" SYSFS{removable}="1" SYSFS{size}="2097151" SYSFS{stat}=" 0 0 0 0 0 0 0 0 0 0 0" follow the class device's "device" looking at the device chain at '/sys/devices/pci0000:00/0000:00:1d.7/usb1/1-2/1-2:2.0/host0/target0:0:0/0:0:0:0': BUS="scsi" ID="0:0:0:0" SYSFS{device_blocked}="0" SYSFS{iocounterbits}="32" SYSFS{iodone_cnt}="0x3" SYSFS{ioerr_cnt}="0x0" SYSFS{iorequest_cnt}="0x4" SYSFS{max_sectors}="256" SYSFS{model}="CD-RW GCE-8160B " SYSFS{queue_depth}="1" SYSFS{queue_type}="none" SYSFS{rev}="1.02" SYSFS{scsi_level}="3" SYSFS{state}="running" SYSFS{timeout}="0" SYSFS{type}="5" SYSFS{vendor}="HL-DT-ST" It stops there, without going on to examine directories like /sys/devices/pci0000:00/0000:00:1d.7/usb1/1-2. That's the reason the symlinks are getting set up -- the rules never match because they don't find the attributes they're supposed to match against. Created attachment 117973 [details]
Patch for udev-039-10.FC3.7.src.rp
This patch for the source RPM fixes the problem. It replaces code in the
udev-039 source with the corresponding code from udev-068.
Why hasn't there been any progress on this bug? Considering that I posted a fix over a month ago, it's surprising that nothing at all has happened. From User-Agent: XML-RPC udev-039-10.FC3.8 has been pushed for FC3, which should resolve this issue. If these problems are still present in this version, then please make note of it in this bug report. That update to udev seems to have fixed things for me. Thanks. Jason (In reply to comment #10) > From User-Agent: XML-RPC > > udev-039-10.FC3.8 has been pushed for FC3, which should resolve this issue. If these problems are still present in this version, then please make note of it in this bug report. |