* Re: udev: timeout on WAIT_FOR_SYSFS
From: Filipe Brandenburger @ 2011-08-02 19:43 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CABe66sWBkuV+Faof9V_6L4sXzxNdUtyGWmFQLbitnpF7Q89=TA@mail.gmail.com>
Hi Kay, thanks for your answers!
On Tue, Aug 2, 2011 at 15:30, Kay Sievers <kay.sievers@vrfy.org> wrote:
> On Tue, Aug 2, 2011 at 16:57, Filipe Brandenburger <filbranden@gmail.com> wrote:
>> I tried adding a call to "udevsettle" just before initializing VxVM
>> but it doesn't help, whenever I have the problem that triggers that
>> log message the devices do not show up even after udevsettle. I also
>> tried "udevtrigger" but that didn't help either.
>
> Missing devices are likely not related to udev but your
> driver/hardware/setup. I guess in the case you miss the stuff, you
> also don't have the device in /sys/block, right?
Indeed, that's the problem, the problem device is not present in
/sys/block or in /dev.
>> I saw this patch that looked interesting, it's from almost 4 years ago
>> but it resembles the codebase of RHEL5 that I'm running:
>> http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h9ea7c6c67de69379b603196a0eff6f7ce2e469a
>>
>> I'm pretty much considering applying that patch to udevd since it will
>> probably fix it, but as I can't reproduce the problem reliably I
>> wanted to ask some questions just to have more confidence in going on
>> with that fix.
>
> As said, that only makes the error logging go away, and maybe some
> udev-event users that expect proper sysfs timing.
Hmmm... So you're saying there's no correlation from the fact that I
get the "wait_for_sysfs: waiting for ... failed" message and the fact
that when I need the devices (on volume manager startup) they are
still not present? Even if I have a call to "udevsettle" just before
the volume manager initialization? Won't the failure of wait_for_sysfs
affect the result of a "udevsettle" call?
>> For instance, the log message is somewhat vague saying some SCSI disks
>> take 6.5s to populate sysfs, does someone have some details of which
>> kinds of disks cause that?
>
> I don't really remember the details, but it was probably the disk
> spin-up time, that blocked the creation of the sysfs files for
> seconds. The code that does that got all changed in later kernels to
> be timed properly.
Ok, so is it possible that this is the issue I have here? I only have
it in one machine so it may be because of faulty/suboptimal SAN behind
it?
Thanks for your answers, I'm trying to get to the bottom of it and
hopefully your help will lead me into the right direction!
Fil
^ permalink raw reply
* Re: udev: timeout on WAIT_FOR_SYSFS
From: Kay Sievers @ 2011-08-02 19:30 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CABe66sWBkuV+Faof9V_6L4sXzxNdUtyGWmFQLbitnpF7Q89=TA@mail.gmail.com>
On Tue, Aug 2, 2011 at 16:57, Filipe Brandenburger <filbranden@gmail.com> wrote:
> I'm having some problems with a Red Hat 5 based machine that still
> uses the udev code before that patch. I'm having the problem that some
> times the devices do not all show up properly by the time they are
> needed.
>
> The devices are on a SAN, they are behind a QLA2xxx HBA and on an
> Hitachi storage.
>
> Occasionally (not always), I'm having a message such as this one during reboot:
> udevd-event[24448]: wait_for_sysfs: waiting for
> '/sys/devices/pci0000:00/0000:00:06.0/0000:0d:00.1/host1/rport-1:0-0/target1:0:0/1:0:0:4/ioerr_cnt'
> failed
That looks like a correct device to expect the SCSI device attribute.
There is no rule to fix.
> The target and LUN change sometimes but it's basically the same
> message. Soon after that, I have initialization of Veritas VxVM but
> when I get this message it fails as not all devices are available.
> Other times the boot process completes as usual and all devices are
> present. In a previous e-mail to Kay Sievers he suggested I might be
> missing a KERNEL="[0-9]*:[0-9]*" filter for the SCSI udev rule, but I
> don't think that's the case as the issue is intermittent and happens
> only once every "x" reboots.
That's only needed for newer kernels on systems with ancient udev,
where the old rules match new devices which did not exist at the time
udev was released.
We don't have any of the sysfs timing problems for common devices on
today's systems. We fixed them all.
Anyway, fixing the rule would only make the logged error go away, not
change anything else, or make a device appear which is missing.
> I tried adding a call to "udevsettle" just before initializing VxVM
> but it doesn't help, whenever I have the problem that triggers that
> log message the devices do not show up even after udevsettle. I also
> tried "udevtrigger" but that didn't help either.
Missing devices are likely not related to udev but your
driver/hardware/setup. I guess in the case you miss the stuff, you
also don't have the device in /sys/block, right?
> I saw this patch that looked interesting, it's from almost 4 years ago
> but it resembles the codebase of RHEL5 that I'm running:
> http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h9ea7c6c67de69379b603196a0eff6f7ce2e469a
>
> I'm pretty much considering applying that patch to udevd since it will
> probably fix it, but as I can't reproduce the problem reliably I
> wanted to ask some questions just to have more confidence in going on
> with that fix.
As said, that only makes the error logging go away, and maybe some
udev-event users that expect proper sysfs timing.
> For instance, the log message is somewhat vague saying some SCSI disks
> take 6.5s to populate sysfs, does someone have some details of which
> kinds of disks cause that?
I don't really remember the details, but it was probably the disk
spin-up time, that blocked the creation of the sysfs files for
seconds. The code that does that got all changed in later kernels to
be timed properly.
> Is this related to SAN disks? If this was
> experienced with qla2xxx driver and/or Hitachi SAN even better as that
> confirms the issue I'm having...
>
> Also, can someone tell what would cause a device to take long to
> populate sysfs? Is this related to the load (as in "Load Average") of
> the machine at the time the module is loaded? Could that be related to
> some heavy scripts being called from udev rules?
>
> And could someone please give me some idea of between which events the
> timeout is?
No between, it all the same device. When the kernel sends 'add' sysfs
is expected to be fully populated, which it isn't in old SCSI code.
Udev works around that by looping in the event handler until sysfs is
ready.
> Is it from the point udev gets the event from a queue
> until the device shows up in sysfs? Does that depend on the driver (in
> this case qla2xxx) or the device itself? What can affect that timing?
It's the SCSI core, that got changed. But again, it's mostly
cosmetics. It will not prevent any disk device node from being
created. Some additional symlinks might fail to get the properties,
and might not be created, but I don't remember anything like that.
Kay
^ permalink raw reply
* udev: timeout on WAIT_FOR_SYSFS
From: Filipe Brandenburger @ 2011-08-02 14:57 UTC (permalink / raw)
To: linux-hotplug
Hello,
I'm having some problems with a Red Hat 5 based machine that still
uses the udev code before that patch. I'm having the problem that some
times the devices do not all show up properly by the time they are
needed.
The devices are on a SAN, they are behind a QLA2xxx HBA and on an
Hitachi storage.
Occasionally (not always), I'm having a message such as this one during reboot:
udevd-event[24448]: wait_for_sysfs: waiting for
'/sys/devices/pci0000:00/0000:00:06.0/0000:0d:00.1/host1/rport-1:0-0/target1:0:0/1:0:0:4/ioerr_cnt'
failed
The target and LUN change sometimes but it's basically the same
message. Soon after that, I have initialization of Veritas VxVM but
when I get this message it fails as not all devices are available.
Other times the boot process completes as usual and all devices are
present. In a previous e-mail to Kay Sievers he suggested I might be
missing a KERNEL="[0-9]*:[0-9]*" filter for the SCSI udev rule, but I
don't think that's the case as the issue is intermittent and happens
only once every "x" reboots.
I tried adding a call to "udevsettle" just before initializing VxVM
but it doesn't help, whenever I have the problem that triggers that
log message the devices do not show up even after udevsettle. I also
tried "udevtrigger" but that didn't help either.
I saw this patch that looked interesting, it's from almost 4 years ago
but it resembles the codebase of RHEL5 that I'm running:
http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h9ea7c6c67de69379b603196a0eff6f7ce2e469a
I'm pretty much considering applying that patch to udevd since it will
probably fix it, but as I can't reproduce the problem reliably I
wanted to ask some questions just to have more confidence in going on
with that fix.
For instance, the log message is somewhat vague saying some SCSI disks
take 6.5s to populate sysfs, does someone have some details of which
kinds of disks cause that? Is this related to SAN disks? If this was
experienced with qla2xxx driver and/or Hitachi SAN even better as that
confirms the issue I'm having...
Also, can someone tell what would cause a device to take long to
populate sysfs? Is this related to the load (as in "Load Average") of
the machine at the time the module is loaded? Could that be related to
some heavy scripts being called from udev rules?
And could someone please give me some idea of between which events the
timeout is? Is it from the point udev gets the event from a queue
until the device shows up in sysfs? Does that depend on the driver (in
this case qla2xxx) or the device itself? What can affect that timing?
Thank you very much in advance!
Filipe
^ permalink raw reply
* [PATCH] rules: input - fix detection of bluetooth hid devices in Xorg
From: Thomas Bächler @ 2011-08-02 8:56 UTC (permalink / raw)
To: linux-hotplug
Commit c49df20758e0f22778cfc93b598f2929f4c86272 prevented udev from
creating broken symlinks for bluetooth hid devices. Unfortunately,
it also removed the ID_INPUT=1 and ID_INPUT_{KEY,MOUSE}=1 properties
from those devices. Xorg relies on these properties for cold- and
hotplugging of input devices.
With this patch, udev still omits the broken symlinks, but also
imports the input_id properties again.
---
rules/rules.d/60-persistent-input.rules | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/rules/rules.d/60-persistent-input.rules b/rules/rules.d/60-persistent-input.rules
index 65a6381..28d50d2 100644
--- a/rules/rules.d/60-persistent-input.rules
+++ b/rules/rules.d/60-persistent-input.rules
@@ -2,9 +2,9 @@
ACTION="remove", GOTO="persistent_input_end"
SUBSYSTEM!="input", GOTO="persistent_input_end"
-SUBSYSTEMS="bluetooth", GOTO="persistent_input_end"
ENV{ID_INPUT}="", IMPORT{program}="input_id %p"
+SUBSYSTEMS="bluetooth", GOTO="persistent_input_end"
SUBSYSTEMS="usb", ENV{ID_BUS}="", IMPORT{program}="usb_id --export %p"
# determine class name for persistent symlinks
--
1.7.6
^ permalink raw reply related
* Re: the file system for /dev
From: Kay Sievers @ 2011-07-31 21:47 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20110731163116.GA24315@linux1>
On Sun, Jul 31, 2011 at 20:05, Greg KH <greg@kroah.com> wrote:
> On Sun, Jul 31, 2011 at 11:31:16AM -0500, William Hubbs wrote:
>>
>> The setup section of the udev README mentions that /dev should get the
>> devtmpfs file system, but it also says that udev can be run on a blank
>> tmpfs as long as you create /dev/{null,kmsg,console}. Also, the
>> requirements section never mentions CONFIG_DEVTMPFS.
>>
>> So, I guess I'm attempting to figure out what is preferred. Is devtmpfs
>> preferred for distros?
>
> Yes.
Right, it's the only way to avoid races when modules are loaded and
the device nodes are expected to exist when modprobe returns, or when
ioctl-like interfaces are used to create new devices. When the call
return from the kernel, we can be sure the nodes are created. Only
devtmpfs provides this synchronization-less behavior here, tmpfs
always needs to be synchronized with the asynchronous udev actions.
>> What are reasons that someone might not want to use devtmpfs with
>> udev?
Nothing really. In theory, it might be useful in container-like setups
to be able to run udev on a plain tmpfs. I don't think that is used
anywhere these days, it's surely not really tested anymore.
Such theoretic setups are the only reason the mknod() code is still in
udev, it's not really needed anymore, and we could also just remove it
and hard require devtmpfs, I guess.
> They don't want to use it? Â I don't know, why not ask the distros that
> don't use it why they don't want it.
Without devtmpfs quite a few things will not work out-of-the-box as
expected, and nobody really cares about these failure cases, because
we all use devtmpfs these days.
Kay
^ permalink raw reply
* Re: the file system for /dev
From: Greg KH @ 2011-07-31 18:05 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20110731163116.GA24315@linux1>
On Sun, Jul 31, 2011 at 11:31:16AM -0500, William Hubbs wrote:
> All,
>
> The setup section of the udev README mentions that /dev should get the
> devtmpfs file system, but it also says that udev can be run on a blank
> tmpfs as long as you create /dev/{null,kmsg,console}. Also, the
> requirements section never mentions CONFIG_DEVTMPFS.
>
> So, I guess I'm attempting to figure out what is preferred. Is devtmpfs
> preferred for distros?
Yes.
> What are reasons that someone might not want to use devtmpfs with
> udev?
They don't want to use it? I don't know, why not ask the distros that
don't use it why they don't want it.
good luck,
greg k-h
^ permalink raw reply
* the file system for /dev
From: William Hubbs @ 2011-07-31 16:31 UTC (permalink / raw)
To: linux-hotplug
[-- Attachment #1: Type: text/plain, Size: 443 bytes --]
All,
The setup section of the udev README mentions that /dev should get the
devtmpfs file system, but it also says that udev can be run on a blank
tmpfs as long as you create /dev/{null,kmsg,console}. Also, the
requirements section never mentions CONFIG_DEVTMPFS.
So, I guess I'm attempting to figure out what is preferred. Is devtmpfs
preferred for distros? What are reasons that someone might not want to
use devtmpfs with udev?
William
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* [ANNOUNCE] udev 173
From: Kay Sievers @ 2011-07-30 22:26 UTC (permalink / raw)
To: linux-hotplug
Here comes a new udev version. Thanks to all who have contributed to
this release.
The tarball can be found here:
ftp://ftp.kernel.org/pub/linux/utils/kernel/hotplug/
The development repository can be found here:
http://www.kernel.org/git/?p=linux/hotplug/udev.git;a=summary
The ChangeLog can be found here:
http://www.kernel.org/git/?p=linux/hotplug/udev.git;a=blob;hb=HEAD;f=ChangeLog
udev 173
====
Bugfixes.
The udev-acl extra is no longer enabled by default. To enable it,
--enable-udev_acl needs to be given at ./configure time. On systemd
systems, the udev-acl rules prevent it from running as the functionality
has moved to systemd.
udev 172
====
Bugfixes.
Udev now enables kernel media-presence polling if available. Part
of udisks optical drive tray-handling moved to cdrom_id: The tray
is locked as soon as a media is detected to enable the receiving
of media-eject-request events. Media-eject-request events will
eject the media.
Libudev enumerate is now able to enumerate a subtree of a given
device.
The mobile-action-modeswitch modeswitch tool was deleted. The
functionality is provided by usb_modeswitch now.
^ permalink raw reply
* Re: separate /usr/broken with udev extras
From: Kay Sievers @ 2011-07-30 22:20 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20110730204023.GA21402@linux1>
On Sun, Jul 31, 2011 at 00:14, William Hubbs <w.d.hubbs@gmail.com> wrote:
> On Sat, Jul 30, 2011 at 11:45:39PM +0200, Kay Sievers wrote:
>> Some stuff is broken for years for all non-simple services. The real
>> fix is just a cp -ax away, I guess. :)
>>
>> As mentioned, the distro's fix is to mount /usr from initramfs, and
>> that's the only realistic option for /{bin,lib} vs. /usr/{bin.lib}
>> split, with the ever-growing use of tools from /usr during bootup.
>>
>> The random split of tools tools in /{bin,lib} vs. /usr/{bin.lib} makes
>> no sense today, what /{bin,lib} was for UNIX is the initramfs for
>> Linux today.
>>
>> We are actually currently planning to move all tools from the rootfs
>> to /usr, where they belong and sort out the chaotic split of install
>> locations. There will be only compat symlinks left in / then.
>
> Why not go the other way and move things that udev needs from /usr to /?
>
> That would be an easier transition imho than moving everything to /usr.
Because many of these tools have dependencies on libs in /usr, or
config in /usr/share. It's a game we can not win realistically, we
will need to move too much stuff to /, which makes the entire idea of
splitting / and /usr in the first place moot.
What's not needed today is stuff in /. We can think of /usr a /System.
The entire system is installed in one single directory, and that can
be mounted r/o, or even shared between many hosts/guest. The stuff on
the rootfs is always host-only then.
Kay
^ permalink raw reply
* Re: separate /usr/broken with udev extras
From: William Hubbs @ 2011-07-30 22:14 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20110730204023.GA21402@linux1>
[-- Attachment #1: Type: text/plain, Size: 1151 bytes --]
On Sat, Jul 30, 2011 at 11:45:39PM +0200, Kay Sievers wrote:
> Some stuff is broken for years for all non-simple services. The real
> fix is just a cp -ax away, I guess. :)
>
> As mentioned, the distro's fix is to mount /usr from initramfs, and
> that's the only realistic option for /{bin,lib} vs. /usr/{bin.lib}
> split, with the ever-growing use of tools from /usr during bootup.
>
> The random split of tools tools in /{bin,lib} vs. /usr/{bin.lib} makes
> no sense today, what /{bin,lib} was for UNIX is the initramfs for
> Linux today.
>
> We are actually currently planning to move all tools from the rootfs
> to /usr, where they belong and sort out the chaotic split of install
> locations. There will be only compat symlinks left in / then.
Why not go the other way and move things that udev needs from /usr to /?
That would be an easier transition imho than moving everything to /usr.
William
>
> Kay
> --
> 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
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: separate /usr/broken with udev extras
From: Kay Sievers @ 2011-07-30 22:08 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20110730204023.GA21402@linux1>
On Sat, Jul 30, 2011 at 23:53, William Hubbs <w.d.hubbs@gmail.com> wrote:
> On Sat, Jul 30, 2011 at 11:23:00PM +0200, Marco d'Itri wrote:
>> On Jul 30, Kay Sievers <kay.sievers@vrfy.org> wrote:
>>
>> > We just gave up supporting the split of tools in / vs. /usr. It does
>> You did, as shown many times other distributions surely did not.
>>
>> I don't even know /how/ I could stop supporting a standalone /usr: some
>> distributions actually support upgrading a system to the next release,
>> and this cannot require repartitioning.
>
> Right, I have had a separate /usr on all of my installed systems for
> years, and I don't know of a reason having this shouldn't be supported.
Claiming as a distro that booting up with and empty /usr, with 'half'
of the tools missing, is just wishful thinking, and it the end not
more than a lie. In reality It works reliably only for limited
requirements regarding device config. I see all these bugs for many
years now.
> I would rather see us work on fixing the tools so that it can still be
> done.
Honestly, I don't think that will ever happen. It's just too much
stuff to fix and change.
Very basic server-like setups will just continue to work as they did
before. But more and more of the new stuff will just fail in
non-interesting ways.
All things that expect the new stuff to run properly, need to get an
initramfs that can mount /usr before init is started, or need to copy
/usr back to the rootfs. There is no other realistic option, really.
Kay
^ permalink raw reply
* Re: separate /usr/broken with udev extras
From: William Hubbs @ 2011-07-30 21:53 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20110730204023.GA21402@linux1>
[-- Attachment #1: Type: text/plain, Size: 700 bytes --]
On Sat, Jul 30, 2011 at 11:23:00PM +0200, Marco d'Itri wrote:
> On Jul 30, Kay Sievers <kay.sievers@vrfy.org> wrote:
>
> > We just gave up supporting the split of tools in / vs. /usr. It does
> You did, as shown many times other distributions surely did not.
>
> I don't even know /how/ I could stop supporting a standalone /usr: some
> distributions actually support upgrading a system to the next release,
> and this cannot require repartitioning.
Right, I have had a separate /usr on all of my installed systems for
years, and I don't know of a reason having this shouldn't be supported.
I would rather see us work on fixing the tools so that it can still be
done.
William
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: separate /usr/broken with udev extras
From: Kay Sievers @ 2011-07-30 21:45 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20110730204023.GA21402@linux1>
On Sat, Jul 30, 2011 at 23:23, Marco d'Itri <md@linux.it> wrote:
> On Jul 30, Kay Sievers <kay.sievers@vrfy.org> wrote:
>
>> We just gave up supporting the split of tools in / vs. /usr. It does
> You did, as shown many times other distributions surely did not.
Good luck!
I'm looking forward to things like patches for the D-Bus config moving
to the rootfs. :)
> I don't even know /how/ I could stop supporting a standalone /usr: some
> distributions actually support upgrading a system to the next release,
> and this cannot require repartitioning.
Some stuff is broken for years for all non-simple services. The real
fix is just a cp -ax away, I guess. :)
As mentioned, the distro's fix is to mount /usr from initramfs, and
that's the only realistic option for /{bin,lib} vs. /usr/{bin.lib}
split, with the ever-growing use of tools from /usr during bootup.
The random split of tools tools in /{bin,lib} vs. /usr/{bin.lib} makes
no sense today, what /{bin,lib} was for UNIX is the initramfs for
Linux today.
We are actually currently planning to move all tools from the rootfs
to /usr, where they belong and sort out the chaotic split of install
locations. There will be only compat symlinks left in / then.
Kay
^ permalink raw reply
* Re: separate /usr/broken with udev extras
From: Marco d'Itri @ 2011-07-30 21:23 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20110730204023.GA21402@linux1>
On Jul 30, Kay Sievers <kay.sievers@vrfy.org> wrote:
> We just gave up supporting the split of tools in / vs. /usr. It does
You did, as shown many times other distributions surely did not.
I don't even know /how/ I could stop supporting a standalone /usr: some
distributions actually support upgrading a system to the next release,
and this cannot require repartitioning.
--
ciao,
Marco
^ permalink raw reply
* Re: separate /usr/broken with udev extras
From: Kay Sievers @ 2011-07-30 20:56 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20110730204023.GA21402@linux1>
On Sat, Jul 30, 2011 at 22:40, William Hubbs <w.d.hubbs@gmail.com> wrote:
> Wehave the following bug report on gentoo linux regarding udev and and
> external dependencies on a system with a separate /usr partition.
>
> http://bugs.gentoo.org/show_bug.cgi?id64235
>
> Comment #1, in particular, is of interest to me, because I think we
> could solve this on gentoo if we had event types that told us when these
> failures happened. Right now, it seems that all ofthese failures are
> marked nomatch by udev, could they be marked as failed instead?
Udev does not support missing tools which are referenced from rules,
that's just an error that is logged.
Today we can not expect a successful bootup with /usr empty and 'half'
of the needed tools missing. Most of the basic stuff, including udev
itself has usually nothing in /usr, but the number of tools needing
things from /usr is growing all the time, and it's unrealistic to
fix/change them all. Too many tools do not support to be started with
an empty /usr, and it's not as simple a fixing udev to re-run the
events.
Please mount /usr from initramfs before 'init' is started, or if the
setup is simple enough, at least before udev and other services start.
We just gave up supporting the split of tools in / vs. /usr. It does
not make much sense today anymore, all tools should be available
during bootup.
Related to this, you might want to read:
http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
Kay
^ permalink raw reply
* separate /usr/broken with udev extras
From: William Hubbs @ 2011-07-30 20:40 UTC (permalink / raw)
To: linux-hotplug
All,
Wehave the following bug report on gentoo linux regarding udev and and
external dependencies on a system with a separate /usr partition.
http://bugs.gentoo.org/show_bug.cgi?id64235
Comment #1, in particular, is of interest to me, because I think we
could solve this on gentoo if we had event types that told us when these
failures happened. Right now, it seems that all ofthese failures are
marked nomatch by udev, could they be marked as failed instead?
Thanks,
William
failures occurred or
^ permalink raw reply
* Re: udev_monitor_receive_device() without polling
From: Kay Sievers @ 2011-07-27 16:59 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20110727184147.65060ce2@leda.vpn.lugor.de>
On Wed, Jul 27, 2011 at 18:41, Christian Hesse <mail@eworm.de> wrote:
> the function udev_monitor_receive_device() used to be blocking a few releases
> back. After the change I had to make my application poll for events.
> Is there any way to to get a blocking behavior and make it work without
> polling?
You can set all options on the file descriptor directly, you can
retrieve from the monitor.
Kay
^ permalink raw reply
* udev_monitor_receive_device() without polling
From: Christian Hesse @ 2011-07-27 16:41 UTC (permalink / raw)
To: linux-hotplug
Hello everybody,
the function udev_monitor_receive_device() used to be blocking a few releases
back. After the change I had to make my application poll for events.
Is there any way to to get a blocking behavior and make it work without
polling?
--
Schoene Gruesse
Chris
^ permalink raw reply
* Re: Building using older kernel headers
From: Kay Sievers @ 2011-07-27 16:23 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CALR4fEK5s5CGEb6QgDyF=ytkEkV21mgVFLGgNpOtBLYZbWdTsw@mail.gmail.com>
On Wed, Jul 27, 2011 at 17:25, Diego Iastrubni <diegoiast@gmail.com> wrote:
> I am trying to build udev 172 using a toolchain which uses a 2.6.32
> (or older). The previous version I tested (v114) compiled fine, and
> the newer version (V172) does not compile since it needs
> BTN_TRIGGER_HAPPY available at linux/input.h
>
> My options are:
>
> 1) Use a new toolchain
> 2) Use an older version (which one..?)
> 3) Patch udev for cases in which the symbol in sot found
> 3.a) define the symbol locally
> 3.b) #ifdef that offending code out
>
> I currently chose to to 3.a, which seems to work for now, even though
> I am running under kernel 2.6.32 (which does not support the joystick
> event which triggered this issue). I think 3.b can be a good idea, and
> I know that even using a newer toolchain works for me, but I would
> like to keep the toolchain.
>
> Which is the newest udev version you can recommend me?
I can't tell, in general I can not recommend running bleeding edge
udev, or any other early boot tool, on old kernels, it might all work
fine, but it's usually just not tested, I personally never run such
setups. We only properly support the other direction: recent kernels
on older userspace.
> Will you accept such patch, for 3.a, or 3.b?
You can probably disable entire features like the keymap if you don't
need it. In general the latest udev version does not really support
old kernel headers, or features/interfaces not available in older
kernels. And no, we don't want to copy kernel definitions in the udev
code, it's better, to just point the build to a recent kernel tree.
Also be aware, that the shipped rules might require an even newer
kernel as the one needed to build, so running a new udev here might
cause problems for non-core features. We only really test things that
are not older than usually 6-9 months. If you need to support such old
kernels, the well-maintained udev version from that time, used in the
enterprise releases of Red Hat or SUSE, might be the safest bet.
Kay
^ permalink raw reply
* Building using older kernel headers
From: Diego Iastrubni @ 2011-07-27 15:25 UTC (permalink / raw)
To: linux-hotplug
[-- Attachment #1: Type: text/plain, Size: 868 bytes --]
Hi all,
I am trying to build udev 172 using a toolchain which uses a 2.6.32
(or older). The previous version I tested (v114) compiled fine, and
the newer version (V172) does not compile since it needs
BTN_TRIGGER_HAPPY available at linux/input.h
My options are:
1) Use a new toolchain
2) Use an older version (which one..?)
3) Patch udev for cases in which the symbol in sot found
3.a) define the symbol locally
3.b) #ifdef that offending code out
I currently chose to to 3.a, which seems to work for now, even though
I am running under kernel 2.6.32 (which does not support the joystick
event which triggered this issue). I think 3.b can be a good idea, and
I know that even using a newer toolchain works for me, but I would
like to keep the toolchain.
Which is the newest udev version you can recommend me?
Will you accept such patch, for 3.a, or 3.b?
- diego
[-- Attachment #2: udev-fix-udev-linux-2.6.32-ugly.patch --]
[-- Type: text/x-patch, Size: 2318 bytes --]
Only in udev-172/extras/input_id/: .deps
Only in udev-172/extras/input_id/: .dirstamp
Only in udev-172/extras/input_id/: input_id
diff -u udev-172.orig/extras/input_id/input_id.c udev-172/extras/input_id/input_id.c
--- udev-172.orig/extras/input_id/input_id.c 2011-06-06 19:31:56.000000000 +0300
+++ udev-172/extras/input_id/input_id.c 2011-07-27 13:21:41.162057204 +0300
@@ -38,6 +38,53 @@
#define LONG(x) ((x)/BITS_PER_LONG)
#define test_bit(bit, array) ((array[LONG(bit)] >> OFF(bit)) & 1)
+// ugly work around for older toolchains which contain
+// kernel headers bellow 2.6.32,
+// defines happly stollen from /usr/include/linux/input.h
+#ifndef BTN_TRIGGER_HAPPY
+#define BTN_TRIGGER_HAPPY 0x2c0
+#define BTN_TRIGGER_HAPPY1 0x2c0
+#define BTN_TRIGGER_HAPPY2 0x2c1
+#define BTN_TRIGGER_HAPPY3 0x2c2
+#define BTN_TRIGGER_HAPPY4 0x2c3
+#define BTN_TRIGGER_HAPPY5 0x2c4
+#define BTN_TRIGGER_HAPPY6 0x2c5
+#define BTN_TRIGGER_HAPPY7 0x2c6
+#define BTN_TRIGGER_HAPPY8 0x2c7
+#define BTN_TRIGGER_HAPPY9 0x2c8
+#define BTN_TRIGGER_HAPPY10 0x2c9
+#define BTN_TRIGGER_HAPPY11 0x2ca
+#define BTN_TRIGGER_HAPPY12 0x2cb
+#define BTN_TRIGGER_HAPPY13 0x2cc
+#define BTN_TRIGGER_HAPPY14 0x2cd
+#define BTN_TRIGGER_HAPPY15 0x2ce
+#define BTN_TRIGGER_HAPPY16 0x2cf
+#define BTN_TRIGGER_HAPPY17 0x2d0
+#define BTN_TRIGGER_HAPPY18 0x2d1
+#define BTN_TRIGGER_HAPPY19 0x2d2
+#define BTN_TRIGGER_HAPPY20 0x2d3
+#define BTN_TRIGGER_HAPPY21 0x2d4
+#define BTN_TRIGGER_HAPPY22 0x2d5
+#define BTN_TRIGGER_HAPPY23 0x2d6
+#define BTN_TRIGGER_HAPPY24 0x2d7
+#define BTN_TRIGGER_HAPPY25 0x2d8
+#define BTN_TRIGGER_HAPPY26 0x2d9
+#define BTN_TRIGGER_HAPPY27 0x2da
+#define BTN_TRIGGER_HAPPY28 0x2db
+#define BTN_TRIGGER_HAPPY29 0x2dc
+#define BTN_TRIGGER_HAPPY30 0x2dd
+#define BTN_TRIGGER_HAPPY31 0x2de
+#define BTN_TRIGGER_HAPPY32 0x2df
+#define BTN_TRIGGER_HAPPY33 0x2e0
+#define BTN_TRIGGER_HAPPY34 0x2e1
+#define BTN_TRIGGER_HAPPY35 0x2e2
+#define BTN_TRIGGER_HAPPY36 0x2e3
+#define BTN_TRIGGER_HAPPY37 0x2e4
+#define BTN_TRIGGER_HAPPY38 0x2e5
+#define BTN_TRIGGER_HAPPY39 0x2e6
+#define BTN_TRIGGER_HAPPY40 0x2e7
+#endif
+
static int debug = 0;
static void log_fn(struct udev *udev, int priority,
Only in udev-172/extras/input_id/: input_id.o
Only in udev-172/extras/input_id/: .libs
^ permalink raw reply
* SATA card insertion crashes if wifi active
From: shivprashant @ 2011-07-27 6:08 UTC (permalink / raw)
To: linux-hotplug
hi,
i am developing PCIe hotplug driver on mpc8315erdb. the hotplug
functionality works fine if wifi (libertas) driver is not loaded. once
libertas driver (uses SPI) is loaded, insertion or removal of SATA card
results in an unrecoverable kernel crash. following is the error log.
-----------------------------------------------------------------------------------------------------------------------------------------
-sh-2.05b# PCIE Card Inserted to Slot 0
pci 0001:01:00.0: ignoring class b20 (doesn't match header type 01)
pci 0001:01:00.0: PCI bridge to [bus 02-ff] (subtractive decode)
pci 0001:02:00.0: BAR 6: assigned [mem 0x40000000-0x4000ffff pref]
pci 0001:02:00.0: BAR 5: assigned [mem 0x40010000-0x40011fff]
pci 0001:02:00.0: BAR 5: set to [mem 0x40010000-0x40011fff] (PCI address
[0x40010000-0x40011fff]
pci 0001:02:00.1: BAR 4: assigned [io 0xff7fa000-0xff7fa00f]
pci 0001:02:00.1: BAR 4: set to [io 0xff7fa000-0xff7fa00f] (PCI address
[0x1000-0x100f]
pci 0001:02:00.1: BAR 0: assigned [io 0xff7fa010-0xff7fa017]
pci 0001:02:00.1: BAR 0: set to [io 0xff7fa010-0xff7fa017] (PCI address
[0x1010-0x1017]
pci 0001:02:00.1: BAR 2: assigned [io 0xff7fa018-0xff7fa01f]
pci 0001:02:00.1: BAR 2: set to [io 0xff7fa018-0xff7fa01f] (PCI address
[0x1018-0x101f]
pci 0001:02:00.1: BAR 1: assigned [io 0xff7fa020-0xff7fa023]
pci 0001:02:00.1: BAR 1: set to [io 0xff7fa020-0xff7fa023] (PCI address
[0x1020-0x1023]
pci 0001:02:00.1: BAR 3: assigned [io 0xff7fa024-0xff7fa027]
pci 0001:02:00.1: BAR 3: set to [io 0xff7fa024-0xff7fa027] (PCI address
[0x1024-0x1027]
pci 0001:01:00.0: PCI bridge to [bus 02-02]
pci 0001:01:00.0: bridge window [io disabled]
pci 0001:01:00.0: bridge window [mem disabled]
pci 0001:01:00.0: bridge window [mem pref disabled]
Oops: Machine check, sig: 7 [#1]
MPC831x RDB
last sysfs file: /sys/devices/pci0000:00/0000:00:10.0/class
Modules linked in: libertas_spi libertas
NIP: c0015c9c LR: c0015c78 CTR: c0015c5c
REGS: cfadfd70 TRAP: 0200 Not tainted (2.6.36.1)
MSR: 00041030 <ME,IR,DR> CR: 84004044 XER: 00000000
TASK = cf896410[976] 'kworker/u:2' THREAD: cfade000
GPR00: 00000000 cfadfe20 cf896410 fdef7054 00000001 00000054 00000004
cfadfe38
GPR08: 0000ffff 00000086 00000000 02000000 24004042 00020d78 0fffb000
ffffffff
GPR16: 00000000 c0374c9c c0374c9c c0374c9c c0320000 c0400000 c0370000
c0374c9c
GPR24: 00000000 c0400000 cf83c200 cfaf6868 00000000 00000050 cfadfe38
00000004
NIP [c0015c9c] mpc83xx_pcie_read_config+0x40/0xd0
LR [c0015c78] mpc83xx_pcie_read_config+0x1c/0xd0
Call Trace:
[cfadfe20] [c0015c78] mpc83xx_pcie_read_config+0x1c/0xd0 (unreliable)
[cfadfe30] [c0182d00] pci_bus_read_config_dword+0x48/0x70
[cfadfe50] [c0185eb8] pci_dev_reset+0x94/0x39c
[cfadfe90] [c018a70c] pci_create_sysfs_dev_files+0x1f4/0x3bc
[cfadfeb0] [c0183140] pci_bus_add_device+0x40/0x58
[cfadfec0] [c01831ac] pci_bus_add_devices+0x54/0x15c
[cfadfee0] [c0183220] pci_bus_add_devices+0xc8/0x15c
[cfadff00] [c0199174] pcie_hpd_enable_slot+0x30c/0x3f8
[cfadff50] [c01992ac] pcie_hpd_enable_worker+0x4c/0xc8
[cfadff60] [c0034224] process_one_work+0x10c/0x328
[cfadff90] [c0035890] worker_thread+0x1a4/0x2ec
[cfadffb0] [c0039bb4] kthread+0x7c/0x80
[cfadfff0] [c000f200] kernel_thread+0x4c/0x68
Instruction dump:
7cfe3b78 90010014 4bfffecd 2f1f0001 39200086 2c030000 41820028 2f9f0002
419a0038 419e0068 7c0004ac 7c001c2c <0c000000> 4c00012c 901e0000 39200000
---[ end trace 4ff32ec36de6bfae ]---
Unable to handle kernel paging request for data at address 0xfffffffc
Faulting instruction address: 0xc0039668
Oops: Kernel access of bad area, sig: 11 [#2]
MPC831x RDB
last sysfs file: /sys/devices/pci0000:00/0000:00:10.0/class
Modules linked in: libertas_spi libertas
NIP: c0039668 LR: c0035480 CTR: 00000000
REGS: cfadfbd0 TRAP: 0300 Tainted: G D (2.6.36.1)
MSR: 00001032 <ME,IR,DR> CR: 44002044 XER: 20000000
DAR: fffffffc, DSISR: 20000000
TASK = cf896410[976] 'kworker/u:2' THREAD: cfade000
GPR00: c02f56a4 cfadfc80 cf896410 cf896410 00000000 c03e37b0 c03e29e4
c03e29e0
GPR08: 00000000 00000000 00000040 00000040 24002022 00020d78 0fffb000
ffffffff
GPR16: 00000000 c0374c9c c0374c9c c0374c9c cf896574 c03e0d80 c03e0d80
00000000
GPR24: c03e0000 c03e0d80 cfade000 cf823bd0 c03e0d80 00000000 cfade000
cfadfca0
NIP [c0039668] kthread_data+0x4/0xc
LR [c0035480] wq_worker_sleeping+0x18/0x9c
Call Trace:
[cfadfc80] [c00536c8] __call_rcu+0x4c/0x144 (unreliable)
[cfadfca0] [c02f56a4] schedule+0x1b8/0x344
[cfadfce0] [c0023598] do_exit+0x428/0x5dc
[cfadfd20] [c000d0a4] kernel_bad_stack+0x0/0x4c
[cfadfd40] [c000dcbc] machine_check_exception+0xf0/0x1a4
[cfadfd60] [c000fa28] ret_from_except_full+0x0/0x4c
--- Exception: 200 at mpc83xx_pcie_read_config+0x40/0xd0
LR = mpc83xx_pcie_read_config+0x1c/0xd0
[cfadfe30] [c0182d00] pci_bus_read_config_dword+0x48/0x70
[cfadfe50] [c0185eb8] pci_dev_reset+0x94/0x39c
[cfadfe90] [c018a70c] pci_create_sysfs_dev_files+0x1f4/0x3bc
[cfadfeb0] [c0183140] pci_bus_add_device+0x40/0x58
[cfadfec0] [c01831ac] pci_bus_add_devices+0x54/0x15c
[cfadfee0] [c0183220] pci_bus_add_devices+0xc8/0x15c
[cfadff00] [c0199174] pcie_hpd_enable_slot+0x30c/0x3f8
[cfadff50] [c01992ac] pcie_hpd_enable_worker+0x4c/0xc8
[cfadff60] [c0034224] process_one_work+0x10c/0x328
[cfadff90] [c0035890] worker_thread+0x1a4/0x2ec
[cfadffb0] [c0039bb4] kthread+0x7c/0x80
[cfadfff0] [c000f200] kernel_thread+0x4c/0x68
Instruction dump:
7c0803a6 38210030 7d808120 4e800020 7fc3f378 38800000 4bfeb545 4bffff58
81220138 8069fff8 4e800020 81230138 <8069fffc> 4e800020 9421fff0 7c0802a6
---[ end trace 4ff32ec36de6bfaf ]---
Fixing recursive fault but reboot is needed!
Unable to handle kernel paging request for data at address 0xfffffffc
Faulting instruction address: 0xc0039668
Oops: Kernel access of bad area, sig: 11 [#3]
MPC831x RDB
last sysfs file: /sys/devices/pci0000:00/0000:00:10.0/class
Modules linked in: libertas_spi libertas
NIP: c0039668 LR: c0035480 CTR: c01c02a4
REGS: cfadfa40 TRAP: 0300 Tainted: G D (2.6.36.1)
MSR: 00001032 <ME,IR,DR> CR: 44002024 XER: 20000000
DAR: fffffffc, DSISR: 20000000
TASK = cf896410[976] 'kworker/u:2' THREAD: cfade000
GPR00: c02f56a4 cfadfaf0 cf896410 cf896410 00000000 ffffffff c01bd784
00020000
GPR08: 00000000 00000000 00000002 00000002 44002022 00020d78 0fffb000
ffffffff
GPR16: 00000000 c0374c9c c0374c9c c0374c9c cf896574 c03e0d80 c03e0d80
00000000
GPR24: c03e0000 c03e0d80 cfade000 cfadfbd0 c03e0d80 00000000 cfade000
cfadfb10
NIP [c0039668] kthread_data+0x4/0xc
LR [c0035480] wq_worker_sleeping+0x18/0x9c
Call Trace:
[cfadfaf0] [c03e0d80] 0xc03e0d80 (unreliable)
[cfadfb10] [c02f56a4] schedule+0x1b8/0x344
[cfadfb50] [c00236e8] do_exit+0x578/0x5dc
[cfadfb90] [c000d0a4] kernel_bad_stack+0x0/0x4c
[cfadfbb0] [c0012850] bad_page_fault+0x90/0xd8
[cfadfbc0] [c000f87c] handle_page_fault+0x7c/0x80
--- Exception: 300 at kthread_data+0x4/0xc
LR = wq_worker_sleeping+0x18/0x9c
[cfadfc80] [c00536c8] __call_rcu+0x4c/0x144 (unreliable)
[cfadfca0] [c02f56a4] schedule+0x1b8/0x344
[cfadfce0] [c0023598] do_exit+0x428/0x5dc
[cfadfd20] [c000d0a4] kernel_bad_stack+0x0/0x4c
[cfadfd40] [c000dcbc] machine_check_exception+0xf0/0x1a4
[cfadfd60] [c000fa28] ret_from_except_full+0x0/0x4c
--- Exception: 200 at mpc83xx_pcie_read_config+0x40/0xd0
LR = mpc83xx_pcie_read_config+0x1c/0xd0
[cfadfe30] [c0182d00] pci_bus_read_config_dword+0x48/0x70
[cfadfe50] [c0185eb8] pci_dev_reset+0x94/0x39c
[cfadfe90] [c018a70c] pci_create_sysfs_dev_files+0x1f4/0x3bc
[cfadfeb0] [c0183140] pci_bus_add_device+0x40/0x58
[cfadfec0] [c01831ac] pci_bus_add_devices+0x54/0x15c
[cfadfee0] [c0183220] pci_bus_add_devices+0xc8/0x15c
[cfadff00] [c0199174] pcie_hpd_enable_slot+0x30c/0x3f8
[cfadff50] [c01992ac] pcie_hpd_enable_worker+0x4c/0xc8
[cfadff60] [c0034224] process_one_work+0x10c/0x328
[cfadff90] [c0035890] worker_thread+0x1a4/0x2ec
[cfadffb0] [c0039bb4] kthread+0x7c/0x80
[cfadfff0] [c000f200] kernel_thread+0x4c/0x68
Instruction dump:
7c0803a6 38210030 7d808120 4e800020 7fc3f378 38800000 4bfeb545 4bffff58
81220138 8069fff8 4e800020 81230138 <8069fffc> 4e800020 9421fff0 7c0802a6
---[ end trace 4ff32ec36de6bfb0 ]---
Fixing recursive fault but reboot is needed!
Unable to handle kernel paging request for data at address 0xfffffffc
Faulting instruction address: 0xc0039668
Oops: Kernel access of bad area, sig: 11 [#4]
MPC831x RDB
last sysfs file: /sys/devices/pci0000:00/0000:00:10.0/class
Modules linked in: libertas_spi libertas
NIP: c0039668 LR: c0035480 CTR: c01c02a4
REGS: cfadf8b0 TRAP: 0300 Tainted: G D (2.6.36.1)
MSR: 00001032 <ME,IR,DR> CR: 44002024 XER: 20000000
DAR: fffffffc, DSISR: 20000000
TASK = cf896410[976] 'kworker/u:2' THREAD: cfade000
GPR00: c02f56a4 cfadf960 cf896410 cf896410 00000000 ffffffff c01bd784
00020000
GPR08: 00000000 00000000 00000002 00000002 44002022 00020d78 0fffb000
ffffffff
GPR16: 00000000 c0374c9c c0374c9c c0374c9c cf896574 c03e0d80 c03e0d80
00000000
GPR24: c03e0000 c03e0d80 cfade000 cfadfa40 c03e0d80 00000000 cfade000
cfadf980
NIP [c0039668] kthread_data+0x4/0xc
LR [c0035480] wq_worker_sleeping+0x18/0x9c
Call Trace:
[cfadf960] [c03e0d80] 0xc03e0d80 (unreliable)
[cfadf980] [c02f56a4] schedule+0x1b8/0x344
[cfadf9c0] [c00236e8] do_exit+0x578/0x5dc
[cfadfa00] [c000d0a4] kernel_bad_stack+0x0/0x4c
[cfadfa20] [c0012850] bad_page_fault+0x90/0xd8
[cfadfa30] [c000f87c] handle_page_fault+0x7c/0x80
--- Exception: 300 at kthread_data+0x4/0xc
LR = wq_worker_sleeping+0x18/0x9c
[cfadfaf0] [c03e0d80] 0xc03e0d80 (unreliable)
[cfadfb10] [c02f56a4] schedule+0x1b8/0x344
[cfadfb50] [c00236e8] do_exit+0x578/0x5dc
[cfadfb90] [c000d0a4] kernel_bad_stack+0x0/0x4c
[cfadfbb0] [c0012850] bad_page_fault+0x90/0xd8
[cfadfbc0] [c000f87c] handle_page_fault+0x7c/0x80
--- Exception: 300 at kthread_data+0x4/0xc
LR = wq_worker_sleeping+0x18/0x9c
[cfadfc80] [c00536c8] __call_rcu+0x4c/0x144 (unreliable)
[cfadfca0] [c02f56a4] schedule+0x1b8/0x344
[cfadfce0] [c0023598] do_exit+0x428/0x5dc
[cfadfd20] [c000d0a4] kernel_bad_stack+0x0/0x4c
[cfadfd40] [c000dcbc] machine_check_exception+0xf0/0x1a4
-----------------------------------------------------------------------------------------------------------------------------------------
--
With Regards,
Shivaprashanth H
^ permalink raw reply
* Re: udev rule matching using ENV
From: william @ 2011-07-27 4:48 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4E2F1236.8050500@cobradevil.org>
On 07/26/2011 10:35 PM, Kay Sievers wrote:
> On Tue, Jul 26, 2011 at 21:18, william<kc@cobradevil.org> wrote:
>> i am trying to create a udev rule which executes a script whenever a usb
>> stick is removed with a particular uuid
>>
>> So i created 99-remove-usb.rules with the following contents
>>
>> IMPORT{program}="/usr/local/bin/usb-stick-uuid.sh"
>> ACTION="remove", ENV{ID_FS_UUID}="ENV{MY_UUID}",
>> But it does never match.
> ENV{ID_FS_UUID}="$env{MY_UUID}" ?
>
no match with the $env{MY_UUID}
When i remove this match so it will execute the script i do get the
MY_UUID in the environment so i know it gets filled.
Also visible when using:
udevadm test --action=remove /block/sdb
William
> Kay
> --
> 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 rule matching using ENV
From: Kay Sievers @ 2011-07-26 20:35 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4E2F1236.8050500@cobradevil.org>
On Tue, Jul 26, 2011 at 21:18, william <kc@cobradevil.org> wrote:
> i am trying to create a udev rule which executes a script whenever a usb
> stick is removed with a particular uuid
>
> So i created 99-remove-usb.rules with the following contents
>
> IMPORT{program}="/usr/local/bin/usb-stick-uuid.sh"
> ACTION="remove", ENV{ID_FS_UUID}="ENV{MY_UUID}",
> But it does never match.
ENV{ID_FS_UUID}="$env{MY_UUID}" ?
Kay
^ permalink raw reply
* udev rule matching using ENV
From: william @ 2011-07-26 19:18 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4E2F1236.8050500@cobradevil.org>
Dear list
i am trying to create a udev rule which executes a script whenever a usb
stick is removed with a particular uuid
The uuid is changeable and we have a common settings file which exports
the UUID from the usb partition.
What i would like is to import the UUID from the settings file and match
that with the actual ID_FS_UUID with the remove action.
So i created 99-remove-usb.rules with the following contents
IMPORT{program}="/usr/local/bin/usb-stick-uuid.sh"
ACTION="remove", ENV{ID_FS_UUID}="ENV{MY_UUID}",
RUN+="/usr/local/bin/usb-removed.sh"
The program usb-stick-uuid.sh now only echo's:
MY_UUIDÿ744c66-3671-447c-8fa0-d96fc6f82352
and nothing else.
But it does never match.
When i enter the uuid by hand in the rule it does work:
ACTION="remove",
ENV{ID_FS_UUID}="ff744c66-3671-447c-8fa0-d96fc6f82352",
RUN+="/usr/local/bin/usb-removed.sh"
Am i doing something wrong or is it just the way it works? I also could
not find any example on the internet matching two ENV strings.
My system:
ubuntu 10.10
udev version 162
With kind regards
William
^ permalink raw reply
* udev rule matching using ENV
From: william @ 2011-07-26 19:15 UTC (permalink / raw)
To: linux-hotplug
Dear list
i am trying to create a udev rule which executes a script whenever a usb
stick is removed with a particular uuid
The uuid is changeable and we have a common settings file which exports
the UUID from the usb partition.
What i would like is to import the UUID from the settings file and match
that with the actual ID_FS_UUID with the remove action.
So i created 99-remove-usb.rules with the following contents
IMPORT{program}="/usr/local/bin/usb-stick-uuid.sh"
ACTION="remove", ENV{ID_FS_UUID}="ENV{MY_UUID}",
RUN+="/usr/local/bin/usb-removed.sh"
The program usb-stick-uuid.sh now only echo's:
MY_UUIDÿ744c66-3671-447c-8fa0-d96fc6f82352
and nothing else.
But it does never match.
When i enter the uuid by hand in the rule it does work:
ACTION="remove",
ENV{ID_FS_UUID}="ff744c66-3671-447c-8fa0-d96fc6f82352",
RUN+="/usr/local/bin/usb-removed.sh"
Am i doing something wrong or is it just the way it works? I also could
not find any example on the internet matching two ENV strings.
My system:
ubuntu 10.10
udev version 162
^ 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