* Re: How to coordinate a DVD burn program with udev ?
From: Thomas Schmitt @ 2011-09-12 10:17 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <98658457621000@192.168.2.69>
Hi,
me:
> > Is there a better place than this mailing list where i could ask for
> > advise ?
Tom Gundersen wrote:
> you could file a bug report with your distro
Anybody here who knows where to get the attention of the Debian people
who would be in charge ?
(I already have a Debian bug open for problems with U3 memory sticks
which confuse the system by pretending to be a USB hub with CD-ROM and
memory stick. Might well be udev related. No reply. Possibly filed
towards the wrong package.)
Have a nice day :)
Thomas
^ permalink raw reply
* Re: How to coordinate a DVD burn program with udev ?
From: Thomas Schmitt @ 2011-09-12 11:33 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <98658457621000@192.168.2.69>
Hi,
> I believe Marco d'Itry is your guy.
> [...]
> Good luck,
Thanks a lot for your advise.
Have a nice day :)
Thomas
^ permalink raw reply
* Re: questions about udev...beginner
From: William Hubbs @ 2011-09-12 13:56 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1315811223.32738.YahooMailClassic@web132513.mail.ird.yahoo.com>
[-- Attachment #1: Type: text/plain, Size: 971 bytes --]
Hi Tom and all,
On Mon, Sep 12, 2011 at 09:27:50AM +0200, Tom Gundersen wrote:
> On Mon, Sep 12, 2011 at 9:07 AM, linuxcbon <linuxcbon@yahoo.fr> wrote:
> > I am not familiar with udev and didn't find a good enough howto.
> > So I ask you questions, thank you for your kind help in advance.
>
> This is how we do it in Arch:
> <http://projects.archlinux.org/initscripts.git/tree/functions#n311>.
>
> > I have put this in rc.sysinit :
> > /sbin/udevd --daemon
> > /sbin/udevadm trigger
>
> You probably want
> /sbin/udevadm trigger --action=add --type=subsystems
> /sbin/udevadm trigger --action=add --type=devices
> instead (the default is only --type=devices, and not --type=subsystems).
Now I need clarification. The README shipped with udev does not mention
"--action=add". According to that file, you just want
/sbin/udevadm trigger --type=subsystems
/sbin/udevadm trigger --type=devices
Which is correct?
Thanks,
William
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: questions about udev...beginner
From: Allin Cottrell @ 2011-09-12 14:06 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1315811223.32738.YahooMailClassic@web132513.mail.ird.yahoo.com>
On Mon, 12 Sep 2011, William Hubbs wrote:
> Hi Tom and all,
>
> On Mon, Sep 12, 2011 at 09:27:50AM +0200, Tom Gundersen wrote:
>> On Mon, Sep 12, 2011 at 9:07 AM, linuxcbon <linuxcbon@yahoo.fr> wrote:
>>> I am not familiar with udev and didn't find a good enough howto.
>>> So I ask you questions, thank you for your kind help in advance.
>>
>> This is how we do it in Arch:
>> <http://projects.archlinux.org/initscripts.git/tree/functions#n311>.
>>
>>> I have put this in rc.sysinit :
>>> /sbin/udevd --daemon
>>> /sbin/udevadm trigger
>>
>> You probably want
>> /sbin/udevadm trigger --actiond --type=subsystems
>> /sbin/udevadm trigger --actiond --typeÞvices
>> instead (the default is only --typeÞvices, and not --type=subsystems).
>
> Now I need clarification. The README shipped with udev does not mention
> "--actiond". According to that file, you just want
>
> /sbin/udevadm trigger --type=subsystems
> /sbin/udevadm trigger --typeÞvices
>
> Which is correct?
Well the latter works fine here, with udev 173.
Allin Cottrell
^ permalink raw reply
* udevadm test /sys/bus/hid
From: linuxcbon @ 2011-09-12 15:35 UTC (permalink / raw)
To: linux-hotplug
Hi,
I now only have one config file /lib/udev/rules.d/50-udev-default.rules
I tried udevadm test /sys/bus/hid
It complains :
udev_device_read_db: no db file to read /dev/.udev/data/+subsystem:hid: No such file or directory
Is it a bug ?
It needs default groups. Are all needed ? I seem to have the minimal groups list.
root:x:0:
bin:x:1:
kmem:x:3:
tty:x:4:
tape:x:5:
daemon:x:6:
floppy:x:7:
disk:x:8:
lp:x:9:
dialout:x:10:
audio:x:11:
video:x:12:
cdrom:x:15:
Thanks in advance.
^ permalink raw reply
* Re: questions about udev...beginner
From: Tom Gundersen @ 2011-09-12 16:23 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1315811223.32738.YahooMailClassic@web132513.mail.ird.yahoo.com>
On Mon, Sep 12, 2011 at 3:56 PM, William Hubbs <w.d.hubbs@gmail.com> wrote:
> Now I need clarification. The README shipped with udev does not mention
> "--actiond". According to that file, you just want
>
> /sbin/udevadm trigger --type=subsystems
> /sbin/udevadm trigger --typeÞvices
>
> Which is correct?
I guess Kay could answer this with more authority. But I'm pretty
certain --typed is correct.
Have a look in init/udev-trigger.service.in to see how udev behaves
when used with systemd (it uses "add").
Also, when that section of the README was written, --typed was the
default, but that later changed to --type=change, so it looks like it
is just out of date.
Cheers,
Tom
^ permalink raw reply
* Re: questions about udev...beginner
From: linuxcbon @ 2011-09-12 16:57 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1315811223.32738.YahooMailClassic@web132513.mail.ird.yahoo.com>
Hi,
> I guess Kay could answer this with more authority. But I'm
> pretty
> certain --type≠d is correct.
You mean --action≠d
> Also, when that section of the README was written,
> --type≠d was the
> default, but that later changed to --type=change, so it
> looks like it
> is just out of date.
udevadm trigger --help says : default for action is "change"
So you mean ?
udevadm trigger --typefivices --action≠d
udevadm trigger --type=subsystems --action≠d
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: questions about udev...beginner
From: Tom Gundersen @ 2011-09-12 17:09 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1315811223.32738.YahooMailClassic@web132513.mail.ird.yahoo.com>
On Mon, Sep 12, 2011 at 6:57 PM, linuxcbon <linuxcbon@yahoo.fr> wrote:
>> I guess Kay could answer this with more authority. But I'm
>> pretty
>> certain --typed is correct.
>
> You mean --actiond
Yes, sorry.
>> Also, when that section of the README was written,
>> --typed was the
>> default, but that later changed to --type=change, so it
>> looks like it
>> is just out of date.
>
> udevadm trigger --help says : default for action is "change"
Exactly. It used to be "add".
> So you mean ?
> udevadm trigger --typeÞvices --actiond
> udevadm trigger --type=subsystems --actiond
Indeed (as in my original email).
-t
^ permalink raw reply
* question on hot plug removal and addition of a USB disk
From: Sampathkumar, Kishore @ 2011-09-14 20:35 UTC (permalink / raw)
To: linux-hotplug
I sent the below query to linux-scsi. Thought it would be better to check on the linux-hotplug mailing list.
Can you please provide the details of the expected behavior, and where in the code should I look for details?
Thanks and Regards,
- Kishore
-----Original Message-----
From: Sampathkumar, Kishore
Sent: Wednesday, September 14, 2011 7:47 PM
To: 'linux-scsi@vger.kernel.org'
Subject: question on hot plug removal and addition of a USB disk
Scenario: I have a file system on a USB SCSI disk /dev/sdb mounted on /mnt.
I perform Action 1 below, and after some time, perform Action 2 below.
Action 1: removal (unplug) of a USB disk
At the time of removal of the USB disk, since the file system was mounted, is the reference to kobject corresponding (now orphaned) sdb still maintained in the kernel, although /dev/sdb is gone due to disk removal?
Is it that the old scsi_disk (sdb) still persists, but, the underlying scsi_dev is removed? Where should I start to trace the hotplug removal of the USB disk? What are the specific processing steps involved in the kernel to handle this (in terms of main routines handling this)?
Action 2: (hot) plug addition of the same USB SCSI disk
On plugging in the same USB SCSI disk, does the sd layer in scsi subsystem grab the first available 'free' sdX device (say sdp), given that sdb is still being referenced by the mounted file system?
Again, in terms of code, does this correspond to:
- a new scsi_dev being allocated
- a corresponding scsi_disk for sdp being allocated by the sd layer in scsi subsystem as part of 'probe' for the added SCSI device
Does the hot plugging work the same way for SAS disks attached behind a FC switch?
Thanks,
- Kishore
^ permalink raw reply
* Re: question on hot plug removal and addition of a USB disk
From: Greg KH @ 2011-09-15 4:26 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <E4D7778E36CF944ABD2F7E18D2DB96660CA26D8EEE@inbmail02.lsi.com>
On Thu, Sep 15, 2011 at 01:53:43AM +0530, Sampathkumar, Kishore wrote:
> I sent the below query to linux-scsi. Thought it would be better to check on the linux-hotplug mailing list.
> Can you please provide the details of the expected behavior, and where in the code should I look for details?
The code for all of this is in the scsi layer today, have you not looked
there already?
If so, and you have specific questions about specific portions of the
code, please ask them. But to ask for developers to provide a full
walk-through of existing, working, and readable code, is a bit of a
stretch as I'm sure you can imagine.
greg k-h
^ permalink raw reply
* Re: questions about udev...beginner
From: Kay Sievers @ 2011-09-18 15:51 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1315811223.32738.YahooMailClassic@web132513.mail.ird.yahoo.com>
On Mon, Sep 12, 2011 at 19:09, Tom Gundersen <teg@jklm.no> wrote:
> On Mon, Sep 12, 2011 at 6:57 PM, linuxcbon <linuxcbon@yahoo.fr> wrote:
>>> I guess Kay could answer this with more authority. But I'm
>>> pretty
>>> certain --typed is correct.
>>
>> You mean --actiond
>
> Yes, sorry.
>
>>> Also, when that section of the README was written,
>>> --typed was the
>>> default, but that later changed to --type=change, so it
>>> looks like it
>>> is just out of date.
>>
>> udevadm trigger --help says : default for action is "change"
>
> Exactly. It used to be "add".
>
>> So you mean ?
>> udevadm trigger --typeÞvices --actiond
>> udevadm trigger --type=subsystems --actiond
Classic system 'coldplug' replays the missing events which happened
before userspace was ready to receive them. We usually use 'add' here
because that is what the original event, which we missed, was.
No other other use case, should ever use 'add', only 'change' is
appropriate when the system is already running.
The systemd service files in the udev source tree always reflect the
current way of doing coldplug.
Kay
^ permalink raw reply
* Re: udevadm test /sys/bus/hid
From: Kay Sievers @ 2011-09-18 16:31 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1315841708.12498.YahooMailClassic@web132513.mail.ird.yahoo.com>
On Mon, Sep 12, 2011 at 17:35, linuxcbon <linuxcbon@yahoo.fr> wrote:
> I now only have one config file /lib/udev/rules.d/50-udev-default.rules
>
> I tried udevadm test /sys/bus/hid
> It complains :
> udev_device_read_db: no db file to read /dev/.udev/data/+subsystem:hid: No such file or directory
> Is it a bug ?
Not an error, just an info() message.
> It needs default groups. Are all needed ? I seem to have the minimal groups list.
> root:x:0:
> bin:x:1:
> kmem:x:3:
> tty:x:4:
> tape:x:5:
> daemon:x:6:
> floppy:x:7:
> disk:x:8:
> lp:x:9:
> dialout:x:10:
> audio:x:11:
> video:x:12:
> cdrom:x:15:
The only rule is that all groups used in any of the rules files should
be available.
Kay
^ permalink raw reply
* udev and ID_FS_UUID
From: Foinel @ 2011-09-22 13:48 UTC (permalink / raw)
To: linux-hotplug
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\x17
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.
^ permalink raw reply
* Re: udev and ID_FS_UUID
From: Simionescu Daniel @ 2011-09-23 9:26 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CANdftmNEBd8ZgyY+BQYnngnLk+eDcjbPwNKQ87YG5p5d=nLbQg@mail.gmail.com>
2011/9/22 Foinel <flocirel@gmail.com>:
> 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\x17
> 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@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: udev and ID_FS_UUID
From: Kay Sievers @ 2011-09-23 9:43 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CANdftmNEBd8ZgyY+BQYnngnLk+eDcjbPwNKQ87YG5p5d=nLbQg@mail.gmail.com>
On Thu, Sep 22, 2011 at 15:48, Foinel <flocirel@gmail.com> wrote:
> 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]
Please provide unmangled logs, and do not edit them.
Also please try:
udevadm test <devpath>
Kay
^ permalink raw reply
* Re: udev and ID_FS_UUID
From: Foinel @ 2011-09-23 9:53 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CANdftmNEBd8ZgyY+BQYnngnLk+eDcjbPwNKQ87YG5p5d=nLbQg@mail.gmail.com>
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@gmail.com> 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\x17
> 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.
>
^ permalink raw reply
* Re: hot plug stable pci name or active pci name detection from /sys
From: Alan Stern @ 2011-09-28 15:14 UTC (permalink / raw)
To: Sudarshan Jagadale
Cc: linux-pci, linux-kernel, linux-hotplug, linux-usb, Kay Sievers
In-Reply-To: <CAEYgNqL8eceFdX_2FSk6oXg2J-7QmijD6oWwQMBS-kn8BwZfPg@mail.gmail.com>
On Tue, 27 Sep 2011, Sudarshan Jagadale wrote:
> Hi ,
>
> I want to create "dev->bus->bus_name" without using usb.h file/writting
> kenel module. is there any way to do this or read the active pci name from
> /sys/ diectory on linux os?
>
> i need to generate the bus info field as follows created by usb_make_path().
>
> please help to resolve this?
There's probably a way to do it using libudev, but I don't know
anything about it.
Another way to do it is to read the "serial" file in the sysfs
directory for the device's root hub. For example, suppose your USB
device has a sysfs name like 7-1.2. The bus number is the part before
the '-' character, in this example, 7. Then the file you should read
would be /sys/bus/usb/devices/usb7/serial. Replace the '7' with the
appropriate bus number for whatever device you're working on.
Alan Stern
^ permalink raw reply
* udevd messages lost on exit?
From: James Hunt @ 2011-09-30 8:29 UTC (permalink / raw)
To: linux-hotplug
Hi All,
I'm investigating a problem in Ubuntu Oneiric where we think udev messages maybe be getting lost due
to the way that we're stopping udevd:
https://bugs.launchpad.net/ubuntu/+source/udev/+bug/818177
In summary, at the end of our initramfs, we are doing this:
# Stop udevd, we'll miss a few events while we run init, but we catch up
udevadm control --exit
# Move /dev to the real filesystem
mount -n -o move /dev ${rootmnt}/dev
The problem is that most notably when using lvm2 the "--exit" call seems to be causing udev messages
relating to the *rootfs* to be lost so that the system fails to boot.
Looking at udevd.c, it does the following when requested to exit:
/* discard queued events and kill workers */
event_queue_cleanup(udev, EVENT_QUEUED);
worker_kill(udev, 0);
I'm currently trying to debug what is left in the queue to get a better handle on this, but I am
wondering if "udevadm control --exit" should request that udevd drain the queues rather than
discarding the messages for our case. Is the reason the messages are discarded to avoid slowing down
the boot coupled with the expectation that the caller will use "udevadm trigger" to catch up later?
Kind regards,
James.
^ permalink raw reply
* Is ASCII the expected udev character encoding?
From: James Hunt @ 2011-09-30 8:30 UTC (permalink / raw)
To: linux-hotplug
Hi All,
Working on the Ubuntu bug below where a battery unit is exposing non-printable characters via udev
made me wonder: is the expected character encoding for all udev messages ASCII? Or is the
expectation that the kernel simply acts as a pass-through (such that it is the responsibility of
userspace to determine the exact meaning of such messages)? If ASCII is expected, should this be
made manifest somewhere?
https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/829980
I'm happy to provide a kernel patch for the bug above, but need to understand whether the kernel
should be sanitizing udev message content, or leaving that up to userspace.
Kind regards,
James.
^ permalink raw reply
* Re: udevd messages lost on exit?
From: Kay Sievers @ 2011-09-30 9:03 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4E857DFD.2060709@ubuntu.com>
On Fri, Sep 30, 2011 at 10:29, James Hunt <james.hunt@ubuntu.com> wrote:
> I'm investigating a problem in Ubuntu Oneiric where we think udev messages maybe be getting lost due
> to the way that we're stopping udevd:
>
> https://bugs.launchpad.net/ubuntu/+source/udev/+bug/818177
>
> In summary, at the end of our initramfs, we are doing this:
>
> # Stop udevd, we'll miss a few events while we run init, but we catch up
> udevadm control --exit
>
> # Move /dev to the real filesystem
> mount -n -o move /dev ${rootmnt}/dev
>
> The problem is that most notably when using lvm2 the "--exit" call seems to be causing udev messages
> relating to the *rootfs* to be lost so that the system fails to boot.
>
> Looking at udevd.c, it does the following when requested to exit:
>
> /* discard queued events and kill workers */
> event_queue_cleanup(udev, EVENT_QUEUED);
> worker_kill(udev, 0);
>
> I'm currently trying to debug what is left in the queue to get a better handle on this, but I am
> wondering if "udevadm control --exit" should request that udevd drain the queues rather than
> discarding the messages for our case. Is the reason the messages are discarded to avoid slowing down
> the boot coupled with the expectation that the caller will use "udevadm trigger" to catch up later?
--exit just does a clean shutdown, it will not check for pending
events, only already running stuff will be properly finished, but
nothing new will be started.
If you want queued stuff, queued in udevd or the kernel, to be all
handled before exiting, add a call to 'settle' before the --exit call.
Kay
^ permalink raw reply
* Re: udevd messages lost on exit?
From: James Hunt @ 2011-09-30 9:33 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4E857DFD.2060709@ubuntu.com>
On 30/09/11 10:03, Kay Sievers wrote:
> --exit just does a clean shutdown, it will not check for pending
> events, only already running stuff will be properly finished, but
> nothing new will be started.
So if events are pending in udevd they will be lost unless trigger is called?
> If you want queued stuff, queued in udevd or the kernel, to be all
> handled before exiting, add a call to 'settle' before the --exit call.
Is that combination atomic?
Kind regards,
James Hunt
^ permalink raw reply
* Re: udevd messages lost on exit?
From: Kay Sievers @ 2011-09-30 9:44 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4E857DFD.2060709@ubuntu.com>
On Fri, Sep 30, 2011 at 11:33, James Hunt <james.hunt@ubuntu.com> wrote:
> On 30/09/11 10:03, Kay Sievers wrote:
>> --exit just does a clean shutdown, it will not check for pending
>> events, only already running stuff will be properly finished, but
>> nothing new will be started.
> So if events are pending in udevd they will be lost unless trigger is called?
There is no idea at all of any continuous handling of events from
initramfs to the real root. These are completely different rule sets
and the stuff from initramfs needs to be replayed anyway.
>> If you want queued stuff, queued in udevd or the kernel, to be all
>> handled before exiting, add a call to 'settle' before the --exit call.
> Is that combination atomic?
See above. You need to trigger anyway. The rootfs might configure the
devices differently than the initramfs. The device database usually
much more stuff to carry.
Kay
^ permalink raw reply
* Re: Is ASCII the expected udev character encoding?
From: Kay Sievers @ 2011-09-30 9:45 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4E857E1D.8000406@ubuntu.com>
On Fri, Sep 30, 2011 at 10:30, James Hunt <james.hunt@ubuntu.com> wrote:
> Working on the Ubuntu bug below where a battery unit is exposing non-printable characters via udev
> made me wonder: is the expected character encoding for all udev messages ASCII? Or is the
> expectation that the kernel simply acts as a pass-through (such that it is the responsibility of
> userspace to determine the exact meaning of such messages)? If ASCII is expected, should this be
> made manifest somewhere?
>
> Â https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/829980
>
> I'm happy to provide a kernel patch for the bug above, but need to understand whether the kernel
> should be sanitizing udev message content, or leaving that up to userspace.
There are no rules really. Especially not about valid utf8 encoding,
or printable chars only.
If you use D-Bus to transport udev properties as D-Bus strings, you
need to make sure they are valid utf8, or use byte arrays instead of
strings.
Kay
^ permalink raw reply
* drive removes and then re-adds itself causing udev rule to re-run
From: brad @ 2011-10-03 12:07 UTC (permalink / raw)
To: linux-hotplug
I have a udev rule to detect when drives are added to a system via an
esata drive dock. Here is the rule:
ACTION="add", KERNEL="sd?", RUN+="/bin/bash /home/rbt/Desktop/script.sh
$kernel"
I use the rule to get the kernel name of the device (sdc, sdd, sde, etc.)
and write it to a file. I normally use this rule on a one slot esata drive
dock and in that case, it works fine.
However, when I use a multi-slot esata drive dock (4 drive slots) drives
sometimes remove themselves and then immediately re-add themselves causing
the rule to fire multiple times. The drives that do this have not been
physically removed from the drive dock and have not powered down. When
this occurs, it causes a bug in my program as that's not expected to
occur.
# udevadm --version = 157
Could anyone on the list offer advice on how to prevent the re-firing of
the rule? I'm going to try setting a env var to prevent firing of the
rule:
ACTION="add", KERNEL="sd?", ENV{status}!="done", ENV{status}="done",
RUN+="/bin/bash /home/rbt/Desktop/script.sh $kernel"
But I suspect that it won't work as udev thinks the device was removed
(even though it wasn't and then re-added) so the variable won't be set.
Here's a log I captured showing the removal and re-addition:
KERNEL[1317412756.066853] remove
/devices/pci0000:00/0000:00:01.0/0000:01:00.0/host0/target0:0:0/0:0:0:0/bsg/0:0:0:0
(bsg)
KERNEL[1317412756.066883] remove
/devices/pci0000:00/0000:00:01.0/0000:01:00.0/host0/target0:0:0/0:0:0:0/scsi_generic/sg4
(scsi_generic)
KERNEL[1317412756.066900] remove
/devices/pci0000:00/0000:00:01.0/0000:01:00.0/host0/target0:0:0/0:0:0:0/scsi_device/0:0:0:0
(scsi_device)
KERNEL[1317412756.066917] remove
/devices/pci0000:00/0000:00:01.0/0000:01:00.0/host0/target0:0:0/0:0:0:0/scsi_disk/0:0:0:0
(scsi_disk)
KERNEL[1317412756.066995] remove
/devices/pci0000:00/0000:00:01.0/0000:01:00.0/host0/target0:0:0/0:0:0:0/block/sdc/sdc2
(block)
KERNEL[1317412756.067020] remove
/devices/pci0000:00/0000:00:01.0/0000:01:00.0/host0/target0:0:0/0:0:0:0/block/sdc/sdc1
(block)
UDEV [1317412756.067829] remove
/devices/pci0000:00/0000:00:01.0/0000:01:00.0/host0/target0:0:0/0:0:0:0/bsg/0:0:0:0
(bsg)
UDEV [1317412756.067854] remove
/devices/pci0000:00/0000:00:01.0/0000:01:00.0/host0/target0:0:0/0:0:0:0/scsi_generic/sg4
(scsi_generic)
UDEV [1317412756.067871] remove
/devices/pci0000:00/0000:00:01.0/0000:01:00.0/host0/target0:0:0/0:0:0:0/scsi_disk/0:0:0:0
(scsi_disk)
KERNEL[1317412756.070392] remove /devices/virtual/bdi/8:32 (bdi)
KERNEL[1317412756.070420] remove
/devices/pci0000:00/0000:00:01.0/0000:01:00.0/host0/target0:0:0/0:0:0:0/block/sdc
(block)
UDEV [1317412756.070499] remove /devices/virtual/bdi/8:32 (bdi)
UDEV [1317412756.070658] remove
/devices/pci0000:00/0000:00:01.0/0000:01:00.0/host0/target0:0:0/0:0:0:0/scsi_device/0:0:0:0
(scsi_device)
UDEV [1317412756.071349] remove
/devices/pci0000:00/0000:00:01.0/0000:01:00.0/host0/target0:0:0/0:0:0:0/block/sdc/sdc2
(block)
UDEV [1317412756.071864] remove
/devices/pci0000:00/0000:00:01.0/0000:01:00.0/host0/target0:0:0/0:0:0:0/block/sdc/sdc1
(block)
KERNEL[1317412756.074152] remove
/devices/pci0000:00/0000:00:01.0/0000:01:00.0/host0/target0:0:0/0:0:0:0
(scsi)
KERNEL[1317412756.074172] remove
/devices/pci0000:00/0000:00:01.0/0000:01:00.0/host0/target0:0:0 (scsi)
KERNEL[1317412756.074187] add
/devices/pci0000:00/0000:00:01.0/0000:01:00.0/host0/target0:0:0 (scsi)
KERNEL[1317412756.074201] add
/devices/pci0000:00/0000:00:01.0/0000:01:00.0/host0/target0:0:0/0:0:0:0
(scsi)
KERNEL[1317412756.074215] add
/devices/pci0000:00/0000:00:01.0/0000:01:00.0/host0/target0:0:0/0:0:0:0/scsi_disk/0:0:0:0
(scsi_disk)
KERNEL[1317412756.074229] add
/devices/pci0000:00/0000:00:01.0/0000:01:00.0/host0/target0:0:0/0:0:0:0/scsi_device/0:0:0:0
(scsi_device)
KERNEL[1317412756.074246] add
/devices/pci0000:00/0000:00:01.0/0000:01:00.0/host0/target0:0:0/0:0:0:0/scsi_generic/sg4
(scsi_generic)
KERNEL[1317412756.074273] add
/devices/pci0000:00/0000:00:01.0/0000:01:00.0/host0/target0:0:0/0:0:0:0/bsg/0:0:0:0
(bsg)
UDEV [1317412756.079955] remove
/devices/pci0000:00/0000:00:01.0/0000:01:00.0/host0/target0:0:0/0:0:0:0/block/sdc
(block)
UDEV [1317412756.080552] remove
/devices/pci0000:00/0000:00:01.0/0000:01:00.0/host0/target0:0:0/0:0:0:0
(scsi)
UDEV [1317412756.081001] remove
/devices/pci0000:00/0000:00:01.0/0000:01:00.0/host0/target0:0:0 (scsi)
UDEV [1317412756.081182] add
/devices/pci0000:00/0000:00:01.0/0000:01:00.0/host0/target0:0:0 (scsi)
UDEV [1317412756.082019] add
/devices/pci0000:00/0000:00:01.0/0000:01:00.0/host0/target0:0:0/0:0:0:0
(scsi)
UDEV [1317412756.082037] add
/devices/pci0000:00/0000:00:01.0/0000:01:00.0/host0/target0:0:0/0:0:0:0/scsi_device/0:0:0:0
(scsi_device)
UDEV [1317412756.082260] add
/devices/pci0000:00/0000:00:01.0/0000:01:00.0/host0/target0:0:0/0:0:0:0/scsi_disk/0:0:0:0
(scsi_disk)
UDEV [1317412756.084781] add
/devices/pci0000:00/0000:00:01.0/0000:01:00.0/host0/target0:0:0/0:0:0:0/scsi_generic/sg4
(scsi_generic)
UDEV [1317412756.084886] add
/devices/pci0000:00/0000:00:01.0/0000:01:00.0/host0/target0:0:0/0:0:0:0/bsg/0:0:0:0
(bsg)
KERNEL[1317412756.086104] add
/devices/pci0000:00/0000:00:01.0/0000:01:00.0/host0/target0:0:0/0:0:0:0/block/sdc
(block)
KERNEL[1317412756.086751] add
/devices/pci0000:00/0000:00:01.0/0000:01:00.0/host0/target0:0:0/0:0:0:0/block/sdc/sdc1
(block)
KERNEL[1317412756.086818] add
/devices/pci0000:00/0000:00:01.0/0000:01:00.0/host0/target0:0:0/0:0:0:0/block/sdc/sdc2
(block)
KERNEL[1317412756.086908] add /devices/virtual/bdi/8:32 (bdi)
UDEV [1317412756.087126] add /devices/virtual/bdi/8:32 (bdi)
UDEV [1317412756.132662] add
/devices/pci0000:00/0000:00:01.0/0000:01:00.0/host0/target0:0:0/0:0:0:0/block/sdc
(block)
UDEV [1317412756.520435] add
/devices/pci0000:00/0000:00:01.0/0000:01:00.0/host0/target0:0:0/0:0:0:0/block/sdc/sdc1
(block)
UDEV [1317412756.523139] add
/devices/pci0000:00/0000:00:01.0/0000:01:00.0/host0/target0:0:0/0:0:0:0/block/sdc/sdc2
(block)
Thanks for any advice!
Brad
^ permalink raw reply
* Re: drive removes and then re-adds itself causing udev rule to re-run
From: Kay Sievers @ 2011-10-03 12:30 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <41252.128.173.192.90.1317643658.squirrel@webmail.tuffmail.net>
On Mon, Oct 3, 2011 at 14:07, <brad@16systems.com> wrote:
> I have a udev rule to detect when drives are added to a system via an
> esata drive dock. Here is the rule:
>
> ACTION="add", KERNEL="sd?", RUN+="/bin/bash /home/rbt/Desktop/script.sh
> $kernel"
>
> I use the rule to get the kernel name of the device (sdc, sdd, sde, etc.)
> and write it to a file. I normally use this rule on a one slot esata drive
> dock and in that case, it works fine.
>
> However, when I use a multi-slot esata drive dock (4 drive slots) drives
> sometimes remove themselves and then immediately re-add themselves causing
> the rule to fire multiple times. The drives that do this have not been
> physically removed from the drive dock and have not powered down. When
> this occurs, it causes a bug in my program as that's not expected to
> occur.
>
> # udevadm --version = 157
>
> Could anyone on the list offer advice on how to prevent the re-firing of
> the rule? I'm going to try setting a env var to prevent firing of the
> rule:
>
> ACTION="add", KERNEL="sd?", ENV{status}!="done", ENV{status}="done",
> RUN+="/bin/bash /home/rbt/Desktop/script.sh $kernel"
>
> But I suspect that it won't work as udev thinks the device was removed
> (even though it wasn't and then re-added) so the variable won't be set.
> Here's a log I captured showing the removal and re-addition:
Your app needs to handle that. There is no way for udev to work around
that, the device was really removed from the kernel and is added back.
Kay
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox