Investigation brought us to believe that there might be a circular call of the function udev_device_read_uevent_file() because this function tests at the beginning the value of udev_device->uevent_loaded and afterwards sets it to true even though all the other functions calling udev_device_read_uevent_file() are testing the value of info_loaded. As far as I can see, uevent_loaded is not used anywhere in udev outside udev_device_read_uevent_file() function. The issue presented in this bug repost is fixed if in udev_device_read_uevent_file() we replace the 2 occurrences of uevent_loaded with info_loaded. If not, then udev_device_get_devnum will eventually get called before we have the valid dev_t devnum in case we have a property with an empty value (in our case it was PARTITION). On Thu, Sep 22, 2011 at 4:48 PM, Foinel <flocirel@xxxxxxxxx> wrote: > Hello, > I am having some issues related to getting the udev env var ID_FS_UUID > of a plugged usb stick using udev version 173 (same happens on udev > 166, but not on 163) and kernel 2.6.36 > > So here it goes: plug a usb stick and issue: > > "udevadm --debug info --query=all --name=sdb1" (in my case sdb is the > newly inserted usb stick) > > this only prints the following: > > > custom logging function 0x54ad2008 registered > main: runtime dir '/run/udev' > run_command: calling: info > udev_device_new_from_syspath: device 0x54ad2090 has devpath [MY_DEVPATH] > P: [MY_DEVPATH] > udev_device_read_db: no db file to read /run/udev/data/+block:sdb1: No > such file or directory > N: sdb1 > E: UDEV_LOG=7 > E: DEVPATH=[MY_DEVPATH] > E: MAJOR=8 > E: MINOR=17 > E: DEVNAME=/dev/sdb1 > E: DEVTYPE=partition > E: PARTN=1 > E: SUBSYSTEM=block > > > As you can see, udevamd --debug complains that the file > /run/udev/data/+block:sdb1 does not exist. Version 163 uses devpath > instead of the runpath used by version 173. Does the introduction of > the runpath need something specific in the kernel which may not be > present/stable in kernel 2.6.36 ? > > One more thing to mention. If I create a symlink such as: > > > ln -sf /run/udev/data/b8:17 /run/udev/data/+block:sdb1 (where 8:17 > is the major:minor pair of the block device - usb stick inserted) > > then, I can get the ID_FS_UUID using udevadm. Any idea why > udev_device_get_id_filename() returns +block:sdb1 instead of b8:17 ? > > Doing a little debugging in the udev code, it seems that the major and > minor numbers are correct in the udev_device_read_uevent_file() > function, however upon return in udev_device_get_devnum() major and > minor numbers are 0 so in turn in udev_device_get_id_filename() it > goes through the else branch hence the +block:sdb1 filename that does > not exist and that brings up the error listed above. > Any ideas? > > Thanks you in advance. > -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
