Bug#346543: [EMAIL PROTECTED]: Bug#346543: udev netlink problems with kernel 2.6.15 on alpha]
On Sun, Jan 08, 2006 at 07:21:35PM +0100, Marco d'Itri wrote: > Any comments? > Subject: Bug#346543: udev netlink problems with kernel 2.6.15 on alpha > To: [EMAIL PROTECTED] > From: Uwe Schindler <[EMAIL PROTECTED]> > > I installed linux-image-2.6.15-1 (2.6.15-2) from Norbert on my alpha > machine. After rebooting I got some strange effects: > > udevd[pid]: error receiving netlink events: no buffer space > available > I think you should open a bug report directly at udev and tell them > to set the receive buffer size directly in the udev code so that it > does not depend on /proc/variables set before. It could also be an > error in the kernel, but on Norberts machine it works. I do not know... udevd sets the buffer size to 16Mb since some time, without fiddling around with the global sysctrls: http://kernel.org/git/?p=linux/hotplug/udev.git;a=blob;hb=HEAD;f=udevd.c#l781 If that's not working, it's probably a kernel bug on your architecture. Works fine for me, here is a big buffer filled up with a stopped udevd: $ cat /proc/net/netlink sk Eth PidGroups Rmem Wmem Dump Locks dfd86000 0 0 00 2 f7779800 0 3259 0011 00 2 dfe3f200 9 0 00 2 dfc27200 10 0 00 2 f1885200 15 6396 2789309 0 2 dffbce00 15 0 00 2 dfe3fe00 16 0 00 2 Kay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#346543: [EMAIL PROTECTED]: Bug#346543: udev netlink problems with kernel 2.6.15 on alpha]
On Mon, Jan 09, 2006 at 09:02:22AM +0100, Uwe Schindler wrote: > At 02:00 09.01.2006, Kay Sievers wrote: > >On Sun, Jan 08, 2006 at 07:21:35PM +0100, Marco d'Itri wrote: > >> Any comments? > > > >> Subject: Bug#346543: udev netlink problems with kernel 2.6.15 on alpha > >> To: [EMAIL PROTECTED] > >> From: Uwe Schindler <[EMAIL PROTECTED]> > >> > >> I installed linux-image-2.6.15-1 (2.6.15-2) from Norbert on my alpha > >> machine. After rebooting I got some strange effects: > >> > >> udevd[pid]: error receiving netlink events: no buffer space > >> available > > > >> I think you should open a bug report directly at udev and tell them > >> to set the receive buffer size directly in the udev code so that it > >> does not depend on /proc/variables set before. It could also be an > >> error in the kernel, but on Norberts machine it works. I do not know... > > > >udevd sets the buffer size to 16Mb since some time, without fiddling > >around with the global sysctrls: > > > >http://kernel.org/git/?p=linux/hotplug/udev.git;a=blob;hb=HEAD;f=udevd.c#l781 > > > >If that's not working, it's probably a kernel bug on your architecture. > >Works fine for me, here is a big buffer filled up with a stopped udevd: > > $ cat /proc/net/netlink > > sk Eth PidGroups Rmem Wmem Dump Locks > > dfd86000 0 0 00 2 > > f7779800 0 3259 0011 00 2 > > dfe3f200 9 0 00 2 > > dfc27200 10 0 00 2 > > f1885200 15 6396 2789309 0 2 > > dffbce00 15 0 00 2 > > dfe3fe00 16 0 00 2 > > Hm interesting. In your code I see, that you only set the actual > buffer size (not the maximum): > setsockopt(uevent_netlink_sock, SOL_SOCKET, SO_RCVBUFFORCE, > &buffersize, sizeof(buffersize)); /* == 16*1024*1024 */ No, it's "...FORCE"! > I had the same problem. When leaving out in my udev-fix script the > setting of that MAX value BEFORE the actual value via /proc it does > not work. I could check both values (MAX and CURRENT) before setting > them on boot time with a "cat" command to printout in the script as > soon as I reboot. > > As I know from the "maximum file descriptors" thing that userspace > programs can only set the current value, not the maximum value for > the whole system. On Linux this maximum value can only be set by > /proc and in Solaris in the kernel configuration file. > > Could it be that on alpha the maximum value is too small initially? No, idea, but as it obviously works on the common architectures, you need to track that on the failing box, I don't have such a system to try. Good luck, Kay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#317333: [EMAIL PROTECTED]: Bug#317333: acknowledged by developer (Bug#317333: fixed in udev 0.063-1)]
On Thu, Aug 25, 2005 at 07:47:56PM +0200, Marco d'Itri wrote: > An interesting comment. > Subject: Bug#317333: acknowledged by developer (Bug#317333: fixed in udev > 0.063-1) > From: Mourad De Clerck <[EMAIL PROTECTED]> > To: Marco d'Itri <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > On Thu, 2005-08-25 at 16:49 +0200, Marco d'Itri wrote: > > On Aug 14, Mourad De Clerck <[EMAIL PROTECTED]> wrote: > > > > > Unfortunately, using linux-image-2.6.12-1-k7 2.6.12-2 and udev 0.066-1 I > > > can still reproduce this bug. After boot certain devices don't show up, > > One of the udev maintainers suggested to try adding mousedev to > > /etc/modules. > > > > Actually, they are on to something because I had just found out > something significant. > > I had 2 things in my /etc/modules: > > mousedev > ide-cd > > The reason why I added mousedev is that (quite) a while back it wouldn't > get automatically loaded. ide-cd was a debian default if I am not > mistaken. > > I commented both out, and on reboot /dev/input/mice was there! Strange, the event seems to get lost. If you restore the failing setup and add a "sleep 1" before udevstart, does it work then? > Just to make sure there were no other devices missing, I started > udevstart again and compared the before and afters: > > --- dev_before_udevstart.txt2005-08-25 16:20:35.0 +0200 > +++ dev_after_udevstart.txt 2005-08-25 16:20:54.0 +0200 > @@ -1,2 +1,5 @@ > /dev/ > +/dev/dvd1 > +/dev/cdrw1 > +/dev/cdrom1 > /dev/vcsa1 > > Now this is weird (and new) - there's no clear reason why extra > (unecessary) dev nodes are made afterwards, and why he didn't make them > in the first place (on boot). The nodes point to the same thing: > > lrwxrwxrwx 1 root root 3 Aug 25 16:19 /dev/dvd -> hdc > lrwxrwxrwx 1 root root 3 Aug 25 16:20 /dev/dvd1 -> hdc > > (similarly for cdrw/cdrw1, and cdrom/cdrom1 - there's no dvd0) > > I guess it's because I commented out ide-cd too ...? > > It's still very weird that modules listed in /etc/modules have this > effect on udev. In the end the same modules are loaded, just at > different times (and maybe twice?). No, this is ok. %e is used, i think. That %e is not very smart and just increases the number if the udevdb is not cleared before the run of udevstart. Kay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#317333: The case of udev and the missing /dev/input/mice
On Wed, Sep 21, 2005 at 03:38:06AM +0100, Scott James Remnant wrote: > Background: in the upcoming Ubuntu 5.10 we've been having some problems > with /dev/input/mice not being created on startup despite the "mousedev" > module being hard-loaded early in the boot sequence. > (http://bugzilla.ubuntu.com/show_bug.cgi?id=12915 for those interested). > > Debian has had similar problems too (http://bugs.debian.org/317333) and > found that starting udevd earlier manually seemed to fix it. Yes, that's a good way to fix it. > After much debugging, I've finally figured out what's going on ... it's > a bit of a story, but here goes... Great, we finally have an idea why this happens. Thanks for finding that out. > On receiving the netlink event for the printer port, udevd disables > receipt of any "sequence numbered" events from udevsend (ie. those that > will almost certainly be duplicated over the netlink socket). > Unfortunately this means all the udevsend events we're about to receive > from the processes that backed off a second or so while fighting over > who got to start udevd[1]. > > These udevsend processes deliver their events to udevd, which cheerfully > ignores them because it thinks it's going to get another copy over the > netlink socket any second now. Unfortunately the netlink event has > already been and gone, and we just ignored an event we weren't supposed > to. > > > The two problems as I see them are: > > 1) The fact that receiving a netlink event disables sequence numbered >udevsend events, when there's already code to deal with de-duping >events anyway. Is there actually any need for this additional check, >can't we just queue both events and have them ignored by >msg_queue_insert() ? > > 2) That this ignoring of events is done at receipt, rather than in queue >order. This means that the "later" parport_pc netlink event is able >to disable queueing of udevsend events with a lower sequence number. > > I can envisage that #1 is necessary in case the time between receiving > the udevsend and netlink event is so long that we've already processed > and removed one of the events by the time the second is queued. Yes, that was the reason for ignoring the incoming messages. > In which case the problem becomes fixing #2, however unless the kernel > promises strict ordering of events over the netlink socket (which I > doubt, otherwise it wouldn't need sequence numbers) Netlink events are always in the right order. The SEQNUM is only needed for the forked events. > we can't assume > that we've received all of the pre-netlink events we are going to. Right, as "/proc/sys/kernel/hotplug" events are forked processes, you will never know when and in which order they will arrive. > I suspect the right solution is actually to implement history of what > events we've already processed, and de-dupe them that way; rather than > ignoring messages on receipt. We could just accept all events with a lower sequence number as the first netlink event's one, that may fix it. The "right solution" is to start udevd as one of the first things after taking over control from the kernel. This way you will only catch the events for the last "non driver core" subsystem, the input layer. At the time the input layer is fixed, the need for udevsend will completely go away and /proc/sys/kernel/hotplug should be disabled when taking over control from the kernel - it is only needed in initramfs. After input is fixed, the whole event reordering and timeout handling will be removed from udevd and we need to start udevd manually anyway. Kay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#329226: udevstart breaks when device not responding
On Tue, Sep 20, 2005 at 11:28:17PM +0200, Marco d'Itri wrote: > FYI. It's unreproducible even by the submitter. That's one of the problems with a synchronous udevstart. It should go away for a lot of other reasons too and I refused all the "coldplug" patches for udevstart for that reason. I expect udevstart kills (alarm) itself after 2 minutes, while it hangs in the *_id programs. There is no easy fix for this. Making udevsynthesize working good enough, which should not have this problem, seems like the best option. Kay > - Forwarded message from Stephen Frost <[EMAIL PROTECTED]> - > > Subject: Bug#329226: udevstart breaks when device not responding > Reply-To: Stephen Frost <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > X-Debian-PR-Message: report 329226 > X-Debian-PR-Package: udev > X-Debian-PR-Keywords: > From: Stephen Frost <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > > Package: udev > Version: 0.070-2 > Severity: Important > > Greetings, > > When installing udev for the first time on a system which has access > to snapshots of other partitions (on my SAN), and those snapshots were > disabled (which means IO failures when trying to read them), udev > failed to install rather badly. > > Populating the new /dev filesystem temporarily mounted on > /tmp/udev.vrFxvY/... > > ... > > [587655.084649] SCSI error : <5 0 0 0> return code = 0x802 > [587655.084682] sdc: Current: sense key: Hardware Error > [587655.084713] <> ASC=0x84 ASCQ=0x0ASC=0x84 ASCQ=0x0 > [587655.084750] end_request: I/O error, dev sdc, sector 6 > > ... > > root 8075 0.0 0.0 2944 1424 pts/1S+ 11:19 0:00 \ >/bin/sh -e /var/lib/dpkg/info/udev.postinst configure > root 8111 0.2 0.0 2200 1144 pts/1S+ 11:19 0:00 \ >/sbin/udevstart > root 8480 0.0 0.0 1820 444 pts/1D+ 11:19 0:00 \ >/sbin/vol_id --export /tmp/udev.gzcWTS/.tmp-8-32 > > ... > > dpkg: error processing udev (--configure): >subprocess post-installation script returned error exit status 1 > > ... > > I enabled the snapshots for the moment to get udev installed. I'm > curious as to what would happen if I rebooted while the snapshots were > disabled though. I do need udev, unfortunately, because multipath > depends on it. I'm pretty sure this is a situation udev needs to be > able to handle though. > > Thanks, > > Stephen > > - End forwarded message - > - Forwarded message from Stephen Frost <[EMAIL PROTECTED]> - > > Subject: Bug#329226: udevstart breaks when device not responding > Reply-To: Stephen Frost <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > X-Debian-PR-Message: report 329226 > X-Debian-PR-Package: udev > X-Debian-PR-Keywords: > From: Stephen Frost <[EMAIL PROTECTED]> > To: Marco d'Itri <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > X-Editor: Vim http://www.vim.org/ > X-Info: http://www.snowman.net > X-Operating-System: Linux/2.4.24ns.3.0 (i686) > X-Uptime: 12:19:49 up 101 days, 8:35, 12 users, load average: 0.07, 0.10, > 0.09 > X-Spam-Level: > X-Spam-Status: No, hits=-6.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER > autolearn=no version=2.60-bugs.debian.org_2005_01_02 > > * Marco d'Itri ([EMAIL PROTECTED]) wrote: > > On Sep 20, Stephen Frost <[EMAIL PROTECTED]> wrote: > > > dpkg: error processing udev (--configure): > > >subprocess post-installation script returned error exit status 1 > > Did you try to kill some process? I can't see how an error could be > > propagated from vol_id to postinst. > > Nope, I didn't kill any processes. It took it a while to fail. In case > it gets lost in irc: > > 12:10 Md: It's in the bug log > 12:11 Md: Basically, vol_id was failing. > 12:11 'cause it was trying to read the device, and the device > was, like, 'uh, no.' > 12:11 I didn't kill off any processes, no... > 12:12 Md: Well, alright, vol_id was the process which was > running when I was seeing > stuff in dmesg show up (the stuff that's in the bug > log) > 12:12 Md: It's possible there was some other issue making > udevstart fail.. > 12:13 Md: But when I enabled the snapshots, I saw vol_id go > past the first set of things > it was being run on. > 12:13 (--export /tmp/udev.gzcWTS/.tmp-8-32 went to, like, > 8-16, etc, iirc) > 12:14 It looked like udevstart was running vol_id multiple > times, and checking if it > worked or not each time, and if it didn't, was exiting > unhappily. > > It seems to me that vol_id errors should probably be non-fatal, but I'm > not entirely sure what it's doing. In this instance I would still want > the appropriate scripts to be run for the device (to properly set up the > multipath stuff for the device) even if the device can't be read at the > moment.
Bug#328960: /sbin/udevsend: main: environment buffer too small, probably not called by the kernel
On Sat, Sep 24, 2005 at 01:29:34AM +0200, Marco d'Itri wrote: > On Sep 18, Kay Sievers <[EMAIL PROTECTED]> wrote: > > > The kernel event buffer is smaller than the udevsend buffer. I expect > > udevsend is not called from the kernel. What's in /proc/sys/kernel/hotplug? > > Or maybe some symlink does still exist in the hotplug.d/ dir to call > > udevsend? Or something like this... > > Actually udevsend *was* not called by the kernel, but by the hal > post-installation script... Is this really bad? This cannot work cause the system shell environment is much too big. Invoke it with "env -i". Kay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#401826: [PATCH] Fix inotify syscalls on M32R
Applied to the upstream udev tree. Thanks, Kay On Wed, 2006-12-06 at 16:17 +0900, Kazuhiro Inaoka wrote: > Please apply a patch to fix inotify syscalls on M32R. > --- udev-0.103/udev_sysdeps.h.org 2006-12-06 05:29:31.503967152 + > +++ udev-0.103/udev_sysdeps.h 2006-12-06 05:30:02.502139848 + > @@ -64,6 +64,10 @@ > # define __NR_inotify_init 290 > # define __NR_inotify_add_watch 291 > # define __NR_inotify_rm_watch 292 > +#elif defined (__m32r__) > +# define __NR_inotify_init 290 > +# define __NR_inotify_add_watch 291 > +# define __NR_inotify_rm_watch 292 > #elif defined (__hppa__) > # define __NR_inotify_init 269 > # define __NR_inotify_add_watch 270 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#398962: [2.6.18] Platform devices incorrectly provide $MODALIAS?
On 11/25/06, Frans Pop <[EMAIL PROTECTED]> wrote: In Debian we are currently seeing some problems with drivers that are repeatedly loaded unsuccessfully: kernel: Intel ISA PCIC probe: not found. FATAL: Error inserting i82365: no such device kernel: Intel ISA PCIC probe: not found. [...] According to Marco d'Itri this could be because "platform devices in recent kernels provide $MODALIAS while they should not. So udev will always try loading again the driver after it has been loaded." He has suggested working around this by excluding loading drivers for platform devices in udev. However, Sven Luther noted that e.g. the Pegasos marvell gigabit ethernet port is a platform device for which the driver should be loaded. Can anyone shed some light on this and suggest a solution? The only sane solution is to fix the kernel platform-subsystem to use aliases instead of direct module names. In the bug you mentioned, the platform device requests its _own_ module, the one which has just created the device again. This misuse of modalias causes a modprobe-loop when the init of the module fails. The author of that code seems ignorant to the issues he creates by doing that, but we hope to get that fixed. For now you can just blacklist all platform events like Marco already suggested. Kay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#398962: [2.6.18] Platform devices incorrectly provide $MODALIAS?
On Tue, 2006-11-28 at 08:12 +0100, Bastian Blank wrote: > On Mon, Nov 27, 2006 at 03:45:36PM +0100, Kay Sievers wrote: > >For now you can just > > blacklist all platform events like Marco already suggested. > > Nope. modprobe don't have the knowledge that this is an alias. Exactly, that's the root of the problem. But it isn't what Marco put in the Debian package, and I was referring to. Kay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#389250: udev: does not always rename wireless interface
On Sun, 2006-10-29 at 00:10 +0200, Brice Goglin wrote: > Kay Sievers wrote: > > This is just for testing, if that works, we may need to fix the > > kernel to create the bus-device driver link at the proper time > > to be catched by DRIVERS==. > > Just wondering whether there is anything new about this bug report. > Marco said it could be ipw2200 having the "race between driver setup and > populating the MAC address file in sysfs as some drivers do". Kay talks > about fixing the kernel. Should I talk to the ipw2200 maintainer? Or is > this a known problem that netdev people are dealing with for all drivers? It likely affects all devices, not only netdev's or certain drivers. This should fix it: http://www.kernel.org/git/?p=linux/kernel/git/gregkh/patches.git;a=blob;hb=HEAD;f=driver/driver-link-sysfs-timing.patch Kay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#389250: udev: does not always rename wireless interface
On Sun, 2006-10-29 at 23:28 +0100, Brice Goglin wrote: > reassign 389250 linux-2.6 > thanks > Kay Sievers wrote: > > On Sun, 2006-10-29 at 00:10 +0200, Brice Goglin wrote: > > > >> Kay Sievers wrote: > >> > >>> This is just for testing, if that works, we may need to fix the > >>> kernel to create the bus-device driver link at the proper time > >>> to be catched by DRIVERS==. > >>> > >> Just wondering whether there is anything new about this bug report. > >> Marco said it could be ipw2200 having the "race between driver setup and > >> populating the MAC address file in sysfs as some drivers do". Kay talks > >> about fixing the kernel. Should I talk to the ipw2200 maintainer? Or is > >> this a known problem that netdev people are dealing with for all drivers? > >> > > > > It likely affects all devices, not only netdev's or certain drivers. > > This should fix it: > > > > http://www.kernel.org/git/?p=linux/kernel/git/gregkh/patches.git;a=blob;hb=HEAD;f=driver/driver-link-sysfs-timing.patch > > > > Yes, 2.6.19-rc3 with this patch seems to work very well, thanks a lot. > Is this patch supposed to go into 2.6.19? > > I am reassigning this bug to linux-2.6. I guess it could be tagged > fixed-upstream too. 2.6.20, I expect. It should be in -mm at the moment, automatically pulled-in from Greg's tree. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#398651: /dev/dvb nodes no longer created after udev upgrade
On Thu, 2006-11-16 at 12:33 +0100, Torsten Crass wrote: > > It's probably you, since DVB devices work fine for me and apparently > > everybody else. > > perhaps you and everybody else is accessing DVB devices via loadable > modules, while I'm using a rather monolithic kernel with the drivers > compiled in? > > > Are you sure that the driver has been loaded? > > According to the dmesg output I submitted together with the bug report, > both cards get reckognized and initialized properly (it seems to me). > > > Are the devices created if > > you run udevtrigger? > > Nope. Please compare the relevant sysfs-trees (/sys/class/dvb/*) of the working kernel with the non-working one. Do you see the same list of devices there? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#294123: udev: Bad parsing of regular expressions in *.rules
On Tue, 2005-02-08 at 21:53 -0800, Greg KH wrote: >On Wed, Feb 09, 2005 at 03:24:31AM +0100, Kay Sievers wrote: >> Can't you match against some interface attributes in sysfs, which are >> telling you which one is the first interface of this device? >> >> You may compare: >> udevinfo -a -p /class/tty/ttyUSB0 >> udevinfo -a -p /class/tty/ttyUSB1 >> >> if you find a difference between both interfaces to match against, that >> is not dependent on the kernel device name. > >This is a real tough one to try to match on, as these both point to the >same exact physical device. Same USB interface even. It's a pain, >stupid palm devices... Ahh, I see. So we may follow the link to the physical device and look for the name of the _first_ serial interface of this device? Would this solve the problem? Kay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#294123: udev: Bad parsing of regular expressions in *.rules
On Mon, 2005-02-14 at 09:30 -0800, Greg KH wrote: >On Sun, Feb 13, 2005 at 04:14:41AM +0100, Kay Sievers wrote: >> On Tue, 2005-02-08 at 21:53 -0800, Greg KH wrote: >> >On Wed, Feb 09, 2005 at 03:24:31AM +0100, Kay Sievers wrote: >> >> Can't you match against some interface attributes in sysfs, which are >> >> telling you which one is the first interface of this device? >> >> >> >> You may compare: >> >> udevinfo -a -p /class/tty/ttyUSB0 >> >> udevinfo -a -p /class/tty/ttyUSB1 >> >> >> >> if you find a difference between both interfaces to match against, that >> >> is not dependent on the kernel device name. >> > >> >This is a real tough one to try to match on, as these both point to the >> >same exact physical device. Same USB interface even. It's a pain, >> >stupid palm devices... >> >> Ahh, I see. So we may follow the link to the physical device and look >> for the name of the _first_ serial interface of this device? Would this >> solve the problem? > >Heh, not quite, as you usually want the _second_ serial interface to >sync off of, the first one is not useful at all (well, some tools use >it, but 99% of the users never will care about it.) > >And then there's the fun problem of some Sony devices creating two >serial "devices" where the second one is just a "fake" one, and you >really need to connect to the first. > >Bah, sometimes I really hate Palm... Yeah, I can imagine that. But would it be possible to get the right one with the information available in sysfs? Someone could write a small script which matches the vendor and return a symlink for the _right_ interface. Would that work? Btw: The "Bad parsing ..." wasn't a udev issue. It's solved. Thanks, Kay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#271997: hal 0.4.5 "It's going to go 100% failure in 72 hours." released
On Sun, 2005-01-16 at 18:08 +0100, Sjoerd Simons wrote:
> On Wed, Jan 12, 2005 at 05:33:39PM -0500, David Zeuthen wrote:
> >
> > Hey,
> >
> > Another week, another HAL release :-). Download from
> >
> > http://freedesktop.org/~david/dist/hal-0.4.5.tar.gz
> >
> > Changes from 0.4.4:
> >
> > - Fix bug with vfat label reading (Kay Sievers, Fredrik Nilsson, Joeny)
>
> This seems to have fixed some filesystems and broken others. I got the
> following from a debian user:
>
> I just upgraded hal (from 0.4.4-1) and noticed, that it doesn't detect
> the volume label of my usb external drive correctly anymore. I found
> this bug, and this change seems to be the cause...
>
> Both mlabel and udev_volume_id show the correct label ("ICYBOX"), but
> hal uses "AD", which is pretty useless...
What does:
hald --verbos=yes --daemon=no
print?
Thanks,
Kay
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#271997: hal 0.4.5 "It's going to go 100% failure in 72 hours." released
On Sun, 2005-01-16 at 18:36 +0100, David Eriksson wrote:
> On Sun, 2005-01-16 at 18:17 +0100, Kay Sievers wrote:
> > On Sun, 2005-01-16 at 18:08 +0100, Sjoerd Simons wrote:
> > >
> > > Both mlabel and udev_volume_id show the correct label ("ICYBOX"), but
> > > hal uses "AD", which is pretty useless...
> >
> > What does:
> > hald --verbos=yes --daemon=no
> >
> > print?
>
> I get about the same error, my mount point gets called "Ap":
>
> http://www.2good.nu/blandat/hald-mountpoint.log
There was only a one-line change in the FAT16 label reading code, but I
can't see how this is wrong.
What does:
dd if=/dev/sda1 bs=512 count=32 skip=32256 | hexdump -C
print for this volume? It will print the complete raw data of the root
directory entries.
And did you try to read the volume name on Windows?
Thanks,
Kay
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#298192: udev: segfault with new rule on startup
On Tue, 2005-03-08 at 00:03 +0100, Marco d'Itri wrote:
> This rule causes udevstart 054 to segfault:
>
> BUS="pci", SUBSYSTEM="net", DRIVER="ipw2100", NAME="wlan"
>
> - Forwarded message from Thomas Breitner <[EMAIL PROTECTED]> -
>
> Subject: Bug#298192: udev: segfault with new rule on startup
> Reply-To: [EMAIL PROTECTED], [EMAIL PROTECTED]
> From: Thomas Breitner <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
>
> Thanks, here it is:
>
> mala:~/sourcen/udev-0.054# /etc/init.d/udev restart
> Recreating device nodes.../etc/init.d/udev: line 216: 10361 Segmentation
> fault udevstart
> mala:~/sourcen/udev-0.054# gdb /sbin/udevstart
> GNU gdb 6.3-debian
> Program received signal SIGSEGV, Segmentation fault.
> strcmp_pattern (p=0x805cc60 "ipw2100", s=0x1c4 )
> at namedev.c:50
> 50 if (s[0] == '\0') {
> (gdb) where
> #0 strcmp_pattern (p=0x805cc60 "ipw2100", s=0x1c4 bounds>) at namedev.c:50
Yeah, that's a bad bug in the rule matching. The sysfs_device is NULL,
and we try to find the name here. I will fix it.
But I don't know why the sysfs_device is NULL in this case, I can't
reproduce it with the same hardware. Thomas, it would be nice if you can
send the output of:
udevinfo -a -p /sys/class/net/eth
Thanks,
Kay
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#297481: hotplug: Fails to load firmware for ipw2200 after upgrade
On Tue, 2005-03-01 at 21:26 +0100, Marco d'Itri wrote: >reassign 297481 kernel-image-2.6.8-i386 >thanks > >On Mar 01, Kay Sievers <[EMAIL PROTECTED]> wrote: > >> This kernel will not work correctly with managed events. It has holes in >> the sequence numbers. You need at least 2.6.10 if I remember correctly. >This sucks, because the next Debian release will ship 2.6.8 as the >default 2.6 kernel. Do you know what needs to be backported to fix this? It's all in lib/kobject_uevent.c and should be trivial. It was changed to increment the seqnum counter only if the kset wants to emit the event. >What else does this break? I should be safe, I think. Kay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#411967: udev: Name conflicts in z20_persistent.rules
> The problem lies within /dev/disk/by-id. Even though the card reader > has four slots, it only has one serial number, so only one link is > created in /dev/disk/by-id. It's called > usb-Generic_STORAGE_DEVICE_05170 and it points to one of > /dev/sd[abcd], not always the same one. I suppose there's a race > condition somewhere. > The card reader is a Kingston FCR-HS215/1, if that matters. > Vendor/device ids: 11b0:6108. Yes, that's a known issue. So far, we've seen that only for very cheap devices, not something with a brand name on it. Usually, the different ports on a card reader have different names: /dev/disk/ |-- by-id | |-- usb-_CF_TS-RD13_2511 -> ../../sdb | |-- usb-_MS_TS-RD13_2511 -> ../../sdd | |-- usb-_SD_TS-RD13_2511 -> ../../sdc | `-- usb-_XD_TS-RD13_2511 -> ../../sde ... |-- by-path | |-- pci-:00:1d.7-usb-0:3:1.0-scsi-0:0:0:0 -> ../../sdb | |-- pci-:00:1d.7-usb-0:3:1.0-scsi-0:0:0:1 -> ../../sdc | |-- pci-:00:1d.7-usb-0:3:1.0-scsi-0:0:0:2 -> ../../sdd | |-- pci-:00:1d.7-usb-0:3:1.0-scsi-0:0:0:3 -> ../../sde ... Hmm, we could add the SCSI-LUN number, like we do in path_id. Hannes, any idea what's the best fix for it? Thanks, Kay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#411967: udev: Name conflicts in z20_persistent.rules
On Sat, 2007-03-03 at 17:59 +0100, Kay Sievers wrote: > > The problem lies within /dev/disk/by-id. Even though the card reader > > has four slots, it only has one serial number, so only one link is > > created in /dev/disk/by-id. It's called > > usb-Generic_STORAGE_DEVICE_05170 and it points to one of > > /dev/sd[abcd], not always the same one. I suppose there's a race > > condition somewhere. > > > The card reader is a Kingston FCR-HS215/1, if that matters. > > Vendor/device ids: 11b0:6108. > > Yes, that's a known issue. So far, we've seen that only for very cheap > devices, not something with a brand name on it. Usually, the different > ports on a card reader have different names: > /dev/disk/ > |-- by-id > | |-- usb-_CF_TS-RD13_2511 -> ../../sdb > | |-- usb-_MS_TS-RD13_2511 -> ../../sdd > | |-- usb-_SD_TS-RD13_2511 -> ../../sdc > | `-- usb-_XD_TS-RD13_2511 -> ../../sde > ... > |-- by-path > | |-- pci-:00:1d.7-usb-0:3:1.0-scsi-0:0:0:0 -> ../../sdb > | |-- pci-:00:1d.7-usb-0:3:1.0-scsi-0:0:0:1 -> ../../sdc > | |-- pci-:00:1d.7-usb-0:3:1.0-scsi-0:0:0:2 -> ../../sdd > | |-- pci-:00:1d.7-usb-0:3:1.0-scsi-0:0:0:3 -> ../../sde > ... > > Hmm, we could add the SCSI-LUN number, like we do in path_id. Ok, I talked with Hannes, and we decided to change usb_id to append "-$target:$lun" to the id of usb-mass storage devices. It looks like this now: /dev/disk/by-id/ |-- usb-Generic_STORAGE_DEVICE_02773-0:0 -> ../../sdb |-- usb-Generic_STORAGE_DEVICE_02773-0:1 -> ../../sdc |-- usb-Generic_STORAGE_DEVICE_02773-0:2 -> ../../sdd `-- usb-Generic_STORAGE_DEVICE_02773-0:3 -> ../../sde It will be part of udev 107. Hope will work as expected. Thanks, Kay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#415744: udev: [PATCH] fix libvolume_id.pc libdir
On Wed, 2007-03-21 at 18:43 +0200, Guillem Jover wrote: > The current .pc file has a wrong libdir (/lib), it should be /usr/lib > as there is where the .so file is located. This makes pkg-config to > not trim the -L argument which is problematic at least on sbox. What do you mean? The .so file is in /lib(64), not in /usr, it's usually needed for bootup, so it can never be in /usr. Thanks, Kay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#409385: udev: not unique path_id for multiple-LUNs iSCSI targets
> I was willing to use /dev/disk/by-path/ devices with an iSCSI setup when
> I figured out not all devices were available by path. I discovered that
> it was because my iSCSI target provided several LUNs, which are not
> reflected by path_id.
>
> The attached patch solves the problem by appending the LUN to the path.
> - d="ip-${iscsi_address}:${iscsi_port}-iscsi-${iscsi_tgtname}"
> + iscsi_lun="${DEV##*:}"
> +
> d="ip-${iscsi_address}:${iscsi_port}-iscsi-${iscsi_tgtname}:${iscsi_lun}"
We already have a fix in the SLES release with -lun- as the separator.
I'll commit this for the next udev version.
Thanks,
Kay
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#366853: vol_id returns incorrect information for my randomly-encrypted swap device
On Thu, 2006-08-17 at 22:46 -0700, Andrew Pimlott wrote: > I suspect I have a similar problem to the reporter of this bug. I have > a swap partition that is set up as an encrypted dm device with a random > key, using the cryptsetup package. cryptsetup now has a test that calls > vol_id, which thinks that my partition is vfat: > > % sudo /lib/udev/vol_id /dev/hda2 > ID_FS_USAGE=filesystem > ID_FS_TYPE=vfat > ID_FS_VERSION=FAT32 > ID_FS_UUID= > ID_FS_LABEL= > ID_FS_LABEL_SAFE= > > % sudo mount -t vfat /dev/hda2 /mnt/tmp > mount: /dev/hda2: can't read superblock > > Inspecting this partition, I see clearly "MSDOS5.0", presumably the > long-preserved remnants of a vfat filesystem. However, since the kernel > refuses to mount the partition as vfat, it seems that vol_id could apply > a stricter check. > > I realize that vol_id can never be perfect, since the device metadata > may be consistent with multiple formats. And I agree that device > initialization tools (like mkswap) should zero out part of the device. > But it would still help to make vol_id more exact, because this issue > evidently bites users in practice. Perhaps there could be flags for > quick-and-dirty check versus more complete check. It's almost impossible to make libvolume_id stricter, in most cases, even the kernel mounts a mkswap formatted (and obviously corrupt) fat volume just fine and allows writing to it. It's mkswap which is horribly broken here and needs to be fixed. You can just use dd and clean the volume before reformatting it. I talked to the former maintainer of mkswap long ago and he said it's a 'feature' of mkswap not to overwrite anything not needed for the swap signature - so far, he seem not to have the slightest clue what all this is about. The maintainer has changed in the meantime, which is great, so we may have a chance to fix that now, but I didn't try to talk to him. Kay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#366853: vol_id returns incorrect information for my randomly-encrypted swap device
On Fri, 2006-08-18 at 08:59 -0700, Andrew Pimlott wrote: > On Fri, Aug 18, 2006 at 02:13:53PM +0200, Kay Sievers wrote: > > It's almost impossible to make libvolume_id stricter, in most cases, > > even the kernel mounts a mkswap formatted (and obviously corrupt) fat > > volume just fine and allows writing to it. > > Ok, thanks for the explanation. > > > It's mkswap which is horribly broken here and needs to be fixed. > > Hopefully the bug I filed with util-linux will produce some change. That would be nice. In case you need to argue, the mkfs.ext* tools and mkfs.reisferfs tools invalidate the start and the end (md raid) of the volume too, to overwrite old signatures after having the same problems. > > You can just use dd and clean the volume before reformatting it. > > Right--I've done that to the partition, and now I have no problem. Yeah, but it's bad, that we need to do this after that issue is known for more than a year now. Thanks, Kay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#392580: udev: (Some) Epson SCSI scanners not recognized as scanners
On Thu, 2006-10-12 at 13:26 +0200, Jö Fahlke wrote:
> Package: udev
> Version: 0.100-2
> Severity: normal
> Tags: patch
>
> My Epson scanner is not assigned to group "scanner" when I switch it
> on and scan the SCSI bus. This is because it identifies itself as
> type 3 (processor) and vendor "EPSON", but permissions.rules matches
> for vender "Epson".
>
> This patch solve the problem for me:
> ==
> --- /etc/udev/permissions.rules 2006/09/21 18:37:41 1.6
> +++ /etc/udev/permissions.rules 2006/10/12 10:49:09
> @@ -25,6 +25,7 @@
> SUBSYSTEMS=="scsi", ATTRS{type}=="1",
> GROUP="tape"
> SUBSYSTEMS=="scsi", ATTRS{type}=="3", ATTRS{vendor}=="HP", GROUP="scanner"
> SUBSYSTEMS=="scsi", ATTRS{type}=="3", ATTRS{vendor}=="Epson",
> GROUP="scanner"
> +SUBSYSTEMS=="scsi", ATTRS{type}=="3", ATTRS{vendor}=="EPSON",
> GROUP="scanner"
> SUBSYSTEMS=="scsi", ATTRS{type}=="5",
> GROUP="cdrom"
> SUBSYSTEMS=="scsi", ATTRS{type}=="6",
> GROUP="scanner"
>
> ==
>
> Note that some way to match values in a case insensitive manner would
> probably allow a more general fix which avoids similiar problems with
> other vendors.
fnmatch() which has a FNM_CASEFOLD option. We could use this but I don't
know a nice way to specify it in the rule key. For now you could just do
ugly things like:
ATTRS{vendor}=="E[Pp][Ss][Oo][Nn]"
Kay
Bug#389250: udev: does not always rename wireless interface
On Wed, 2006-09-27 at 12:45 +0200, Marco d'Itri wrote:
> On Sep 27, Brice Goglin <[EMAIL PROTECTED]> wrote:
>
> > >> # PCI device 0x8086:0x4220 (ipw2200)
> > >> SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:12:f0:12:05:03",
> > >> NAME="wifi"
> > >>
> > > Try replacing DRIVERS== with PHYSEDVDRIVER== and let me know.
> > It works!
> >
> > I don't see any documentation about PHYSEDVDRIVER anywhere. Am I
> > supposed to keep using it?
It must be ENV{PHYSDEVDRIVER}==, it is just a kernel supplied
environment variable.
> Or was this only for debugging purpose?
This is just for testing, if that works, we may need to fix the
kernel to create the bus-device driver link at the proper time
to be catched by DRIVERS==.
> It is deprecated and usually should not be used, probably DRIVER can
> be fixed to work as expected.
Yes, all kernel PHYSDEV* event variables are deprecated and will be
removed from the kernel in 2 years.
Thanks,
Kay
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#389892: writing_udev_rules: just unplug the card reader and insert new cards and replug
On Thu, 2006-09-28 at 16:40 +0800, Dan Jacobson wrote:
> X-debbugs-cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
> Package: udev
> Version: 0.100-1
> Severity: normal
> File: /usr/share/doc/udev/writing_udev_rules/index.html
>
> Regarding
>
> USB Card Reader
>
> These devices typically do not inform the host computer upon
> media change. So, if you plug in the device with no media, and
> then insert a card, the computer does not realise, and you do not
> have your mountable sdb1 partition node for the media.
>
> One possible solution is to take advantage of the all_partitions
> option, which will create 16 partition nodes for every block
> device that the rule matches:
>
>BUS=="usb", SYSFS{product}=="USB 2.0 CompactFlash Reader",
>SYMLINK+="cfrdr%n", OPTIONS+="all_partitions"
>
> You will now have nodes named: cfrdr, cfrdr1, cfrdr2, cfrdr3,
> ..., cfrdr15.
>
>
> I would say 1 times less complicated would be to tell the user to
> forget trying to understand all this, and
>
> 1. umount(8) cards already mounted on the reader, if any.
> 2. Unplug the reader from the USB socket.
> 3. Insert any additional cards into the reader.
> 4. Plug the reader back into the USB socket.
> 5. mount(8) your cards again.
>
> That's all.
>
> Sorry, but that's the view from us less sophisticated users.
Ick, no, just use a reasonable setup, where HAL will poll the device for
you and this is no issue at all. Nobody should write udev rules for
things like this these days.
> ===
>
> (By the way, one even wonders if BUS above should be SUBSYSTEMS.
Both work the same way. Yes, the document should be updated to use the
new key names.
> and one also wants to match all card readers, no matter the brand.
No recent system should need any of these udev rules to make
card-readers work. Udev rules or disconnect/reconnect advices are the
totally wrong solution for this problem.
> Also say what one has to do after one writes a rule. restart udevd?
> reboot? for it to take effect.
Nothing is needed. Udevd will notice any rules change by watching the
directory with inotify.
> But never mind. It is 1 times easier to forget trying to
> understand all this.)
As said, everybody can try to fiddle around with stuff like this if he's
interested in seeing how that works, we all do this sometimes. But
nothing of this should be needed today to get things working, if you
don't cripple your system or work in a very special environment and you
are expected to have that kind of special knowledge anyway.
Kay
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#383051: /lib/udev/vol_id translates volume id to uppercase for FAT partition.
On Mon, 2006-08-14 at 19:43 +0100, Tim Phipps wrote: > Package: udev > Version: 0.093-1 > Severity: normal > > Feel free to change this to minor or wishlist. I'd like vol_id to not > change the case of FAT partitions labels. I don't believe this will affect > many people since FAT partitions are usually created with upper case labels > anyway. It was quite hard to get a lower case one in there in the first > place so only lunatics like me will notice any change. Huh, what do you mean? Libvolume_id does not translate anything. What piece of software is showing a label with lowercase chars? Anyway, care to add the output of: /lib/udev/vol_id /dev/sdd1 and: strace -t -s1 /lib/udev/vol_id /dev/sdd1 so we can take a look at the label stored on your disk. Thanks, Kay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#383200: udev: typo in man page, 'Asign' should be 'Assign'
On Tue, 2006-08-15 at 10:08 -0500, Matt Zagrabelny wrote: > Package: udev > Version: 0.093-1 > Severity: minor > > > typo in /usr/share/man/man7/udev.7.gz > > 'Asign' should be 'Assign' Fixed. Thanks, Kay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#725714: udev firmware loading does not work in the Debian installer
On Fri, Dec 13, 2013 at 12:12 AM, Andreas Cadhalpun wrote: > On 12.12.2013 23:19, Kay Sievers wrote: >> On Thu, Dec 12, 2013 at 10:58 PM, Michael Biebl >> wrote: >>> This was removed upstream [1] and is highly unlikely to be added back. >>> Especially considering that the user space firmware loader is scheduled >>> to be removed sooner rather then later. >>> >>> This most likely means d-i needs to be updated to use some kind of >>> different mechanism to detect missing firmware. >>> >>> Kay, what is the recommended approach nowadays to detect such missing >>> firmware? >> >> There is no replacement for that. Userspace is no longer in the loop >> any more regarding firmware loading, it's all the kernel's job only. >> Hence, there will be no facility in udev for handling firmware, or >> getting notified about that. > According to Ben Hutchings the kernel still thinks udev is responsible for > handling missing firmware. Recent udev does not even have the code to handle firmware enabled. It's gone since a while already. >> The only possible solution would be to add explicit messages to the >> kernel drivers in case a firmware is really *missing* and the device >> does not just probe for stuff until it finds something. >> >> There are quite a lot devices which just look for *updates* and do not >> need anything to function. > In this case the WLAN devices really need the firmware to work, but since > the firmware is non-free, it is not included in the Debian installer. Which is not a technical problem, udev can or should try to solve. >> Such an explicit message would probably use printk_emit() and pass >> structured data with the filename and the ides from the kernel to >> userspace, and on systemd systems the journal would pick up the >> MESSAGE_ID and do something with it, or provide the data to other >> consumers. > The better approach would have been to write a replacement *before* dropping > the udev missing-firmware handling. There have been many technical reasons to let the kernel do the job, and that is how it works today, and it works well and reliably. > The Debian installer needs a way to load the firmware during installation, > otherwise the netinst.iso is pretty useless for WLAN devices with non-free > firmware. > Since a majority of the WLAN devices need non-free firmware, just dropping > this functionality without replacement is a serious regression. It is not, only if firmware is not installed, which seem to be a Debian-only problem but not a general one. Hence Debian needs to adopt/patch the software to do what it needs, and should not ask upstream to work around issues which seem to be a Debian-only problem. The in-kernel firmware loader solved years old serious problems, and it was worth to do it, and there is no reason to put back that fragile hack, just to solve a non-technical problem. > Therefore I ask you to re-enable it until a replacement is written. Udev will never load firmware again, the entire idea to use the driver core to create fake devices in userspace and let the kernel wait to them to be handled, was wrong at so many aspects, it will not come back from upstream udev. Kay -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#725714: udev firmware loading does not work in the Debian installer
On Fri, Dec 13, 2013 at 12:26 AM, Michael Biebl wrote: > Am 13.12.2013 00:12, schrieb Andreas Cadhalpun: >> The Debian installer needs a way to load the firmware during >> installation, otherwise the netinst.iso is pretty useless for WLAN >> devices with non-free firmware. >> Since a majority of the WLAN devices need non-free firmware, just >> dropping this functionality without replacement is a serious regression. >> Therefore I ask you to re-enable it until a replacement is written. > > Could something like isenkram [1] be integrated into d-i and install > necessary (firmware) packages based on the modalias information? > > Especially [2] looks like it could be a replacement. > That said, isenkram-autoinstall-firmware doesn't seem to use the > modalias info and instead greps through the modinfo output which looks > like a rather hackish approach on a cursory glance. > > Kay, what's you opinion on something like this? It could work. The device modaliases of the running machine can produce the list of modules that will be loaded on a machine. The modules themselves carry the file names of the firmware files in the module's metadata. Kay -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#725714: udev firmware loading does not work in the Debian installer
On Fri, Dec 13, 2013 at 12:34 AM, Michael Biebl wrote: > Am 13.12.2013 00:26, schrieb Michael Biebl: >> Am 13.12.2013 00:12, schrieb Andreas Cadhalpun: >>> The Debian installer needs a way to load the firmware during >>> installation, otherwise the netinst.iso is pretty useless for WLAN >>> devices with non-free firmware. >>> Since a majority of the WLAN devices need non-free firmware, just >>> dropping this functionality without replacement is a serious regression. >>> Therefore I ask you to re-enable it until a replacement is written. >> >> Could something like isenkram [1] be integrated into d-i and install >> necessary (firmware) packages based on the modalias information? >> >> Especially [2] looks like it could be a replacement. >> That said, isenkram-autoinstall-firmware doesn't seem to use the >> modalias info and instead greps through the modinfo output which looks >> like a rather hackish approach on a cursory glance. > > According to codesearch.d.n, hw-detect is the only tool using > /run/udev/firmware-missing. I'm inclined to re-assign this bug to > hw-detect and let the hw-detect maintainers decided how to handle this. > If something like the isenkram approach would be suitable for them PackageKit used it too. General note: the entire idea of blindly recording firmware requests is flawed. It makes not much sense to make assumptions about drivers and that the files they ask for are *missing*, they are not in many cases. Many drivers just request things to check for updates which in many cases never exist. Or they request multiple files in a row, to fall back to older versions they find. The only sensible way to produce information about *missing* firmware would be to add explicit messages to the kernel when things are really *missing*. Blindly tracing firmware requests and guessing around never really made sense. Also: That all this is gone now is a side-effect of moving firmware loading into the kernel where it belongs. There is nothing userspace can do about, the information is just no longer available to userspace. Kay -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#725714: udev firmware loading does not work in the Debian installer
On Fri, Dec 13, 2013 at 12:42 AM, Michael Biebl wrote: > Am 13.12.2013 00:34, schrieb Michael Biebl: > See also > http://lists.freedesktop.org/archives/systemd-devel/2013-November/014771.html > > But that thread just echoes what Kay already said, that user-space > firmware loading is deprecated and on it's way out. Right, it's gone, and upstream does not support it any more because it is technically the wrong solution and in-kernel loading the only supported option. It can all pretty trivially be made to run in userspsce like it did (unreliably in some cases) in the past, but the kernel and udev will need to be patched to do that. Kay -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#725714: udev firmware loading does not work in the Debian installer
On Fri, Dec 13, 2013 at 4:29 AM, Ben Hutchings wrote: > On Fri, 2013-12-13 at 00:28 +0100, Kay Sievers wrote: > [...] >> >> Such an explicit message would probably use printk_emit() and pass >> >> structured data with the filename and the ides from the kernel to >> >> userspace, and on systemd systems the journal would pick up the >> >> MESSAGE_ID and do something with it, or provide the data to other >> >> consumers. >> >> > The better approach would have been to write a replacement *before* >> > dropping >> > the udev missing-firmware handling. >> >> There have been many technical reasons to let the kernel do the job, >> and that is how it works today, and it works well and reliably. > [...] > > For the record, 3.12 still has: > > config FW_LOADER_USER_HELPER > bool "Fallback user-helper invocation for firmware loading" > depends on FW_LOADER > default y > > But at this point I suppose there is no point leaving it enabled. Yeah, not sure, if it could be removed. Fedora has that option disabled since a while. Kay -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#732157: [systemd-devel] Fwd: [Pkg-systemd-maintainers] Bug#732157: Want SIGSTOP-style daemon/service readiness notification
On Sat, Dec 14, 2013 at 11:19 PM, Shawn Landden wrote: > It would be nice if systemd could implement the service supervisor > side of the service readiness protocol that upstart calls "expect > stop": > > The service doesn't fork, and when considers itself ready it raises > SIGSTOP. The supervisor can observe this via the usual mechanisms, > being the service's parent, and when it occurs it sends the service > CONT and starts whatever was waiting for readiness. > > The sd_notify(3) protocol is just about tolerable, and it is good that > it's documented, but it is quite unattractive for a daemon author: > Either they have to add a build- and runtime- dependency on a > systemd-specific library, or they have to reimplement a fairly tedious > piece of socket code. > > For a daemon author, raise(SIGSTOP) is lovely and simple. > > I guess this would be a new "Type" (but I'm still halfway through the > docs so no expert). No, it's not lovely, it's a very cheap and very bad hack. These signals are for admins and not for system management tools; just the same way ptrace is the very wrong tool to track startup behavior of services. It is just so wrong to things like that, and systemd should not do that. Kay -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#745280: [gummiboot] Re: Bug#745280: fails to cope properly with an existing boot loader
On Fri, Apr 25, 2014 at 3:51 PM, Julian Andres Klode wrote:
> I received the following bug report in Debian about
> gummiboot.
>
> On Sun, Apr 20, 2014 at 10:04:23AM +0200, Philipp Kern wrote:
>> Package: gummiboot
>> Version: 44-1
>> Severity: important
>>
>> gummiboot fails to install if there is a preexisting EFI boot loader in
>> the fallback location (e.g. after a successful installation of Windows):
>>
>> pkern@simplex ~ % sudo gummiboot install --path=/boot/efi
>> Created /boot/efi/EFI/gummiboot.
>> Copied /usr/lib/gummiboot/gummibootx64.efi to
>> /boot/efi/EFI/gummiboot/gummibootx64.efi.
>> Failed to rename /boot/efi/EFI/Boot/BOOTX64.EFI~ to
>> /boot/efi/EFI/Boot/BOOTX64.EFI: File exists
>
> As we can see here, it tries to do an atomic replace of the boot loader,
> but this fails because /boot/efi (we need to use /boot/efi in Debian instead
> of /boot, because our kernel images are installed in /boot) is FAT32 and
> that does not seem to allow replacements.
It works just fine here on a FAT partition. I have no idea why it
would go wrong.
# blkid /dev/sda1
/dev/sda1: LABEL="EFI" UUID="9B5C-C8BD" TYPE="vfat" PARTLABEL="ESP"
PARTUUID="06a08fe0-82e8-4171-b00e-5afc13668ab4"
# strace -e rename gummiboot install --path=/boot
rename("/boot/EFI/gummiboot/gummibootx64.efi~",
"/boot/EFI/gummiboot/gummibootx64.efi") = 0
Copied /usr/lib/gummiboot/gummibootx64.efi to
/boot/EFI/gummiboot/gummibootx64.efi.
rename("/boot/EFI/Boot/BOOTX64.EFI~", "/boot/EFI/Boot/BOOTX64.EFI") = 0
Copied /usr/lib/gummiboot/gummibootx64.efi to /boot/EFI/Boot/BOOTX64.EFI.
Created EFI boot entry "Linux Boot Manager".
Kay
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#745280: [gummiboot] Re: Bug#745280: fails to cope properly with an existing boot loader
On Fri, Apr 25, 2014 at 7:10 PM, Julian Andres Klode wrote:
> On Fri, Apr 25, 2014 at 06:43:07PM +0200, Kay Sievers wrote:
>> On Fri, Apr 25, 2014 at 3:51 PM, Julian Andres Klode wrote:
>> > I received the following bug report in Debian about
>> > gummiboot.
>> >
>> > On Sun, Apr 20, 2014 at 10:04:23AM +0200, Philipp Kern wrote:
>> >> Package: gummiboot
>> >> Version: 44-1
>> >> Severity: important
>> >>
>> >> gummiboot fails to install if there is a preexisting EFI boot loader in
>> >> the fallback location (e.g. after a successful installation of Windows):
>> >>
>> >> pkern@simplex ~ % sudo gummiboot install --path=/boot/efi
>> >> Created /boot/efi/EFI/gummiboot.
>> >> Copied /usr/lib/gummiboot/gummibootx64.efi to
>> >> /boot/efi/EFI/gummiboot/gummibootx64.efi.
>> >> Failed to rename /boot/efi/EFI/Boot/BOOTX64.EFI~ to
>> >> /boot/efi/EFI/Boot/BOOTX64.EFI: File exists
>> >
>> > As we can see here, it tries to do an atomic replace of the boot loader,
>> > but this fails because /boot/efi (we need to use /boot/efi in Debian
>> > instead
>> > of /boot, because our kernel images are installed in /boot) is FAT32 and
>> > that does not seem to allow replacements.
>>
>> It works just fine here on a FAT partition. I have no idea why it
>> would go wrong.
>
> It seems to be a matter of lower vs. uppercase, for example:
>
> $ ls -l EFI/Boot/
> -rwxr-xr-x 1 root root 78107 Apr 11 00:25 bootx64.efi
> # mv y EFI/Boot/BOOTX64.efi
> mv: cannot move 'y' to 'EFI/Boot/BOOTX64.efi': File exists
>
> But:
> # mv y EFI/Boot/bootx64.efi
>
> works as intended. Strace shows the difference:
>
> rename("y", "EFI/Boot/BOOTX64.efi") = -1 EEXIST (File exists)
> rename("y", "EFI/Boot/bootx64.efi") = 0
>
> It does work in some cases though. I'm not entirely sure what is
> broken here.
>
> The file system is mounted in utf8 which produces the warning
> [2.998918] FAT-fs (sdb1): utf8 is not a recommended IO charset for FAT
> filesystems, filesystem will be case sensitive!
> which probably causes this. I'm not sure why it is mounted with
> utf-8, though.
I have it mounted without any specific options:
http://cgit.freedesktop.org/systemd/systemd/tree/src/efi-boot-generator/efi-boot-generator.c#n108
which results in:
rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro
Kay
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#745280: [gummiboot] Re: Bug#745280: fails to cope properly with an existing boot loader
On Fri, Apr 25, 2014 at 8:25 PM, Julian Andres Klode wrote: > The Debian kernels are configured > CONFIG_FAT_DEFAULT_IOCHARSET="utf8" > which causes iocharset=utf8 to be the default here, rather than > iocharset=ascii. I can now > either work around that in the gummiboot package by one of > > (1) unlink() and then rename() > (2) do a stupid glob() [Bb][Oo][Tt][Xx]64.[Ee][Ff][Ii] (and the same for the > rest of the path) > > I don't think you'd like either of those upstream, so you might want to change > the generator to pass iocharset=ascii. We do not (apart from me) use that > generator, though, so it won't help Debian -- we generate a fstab entry during > system installation instead. Are we sure that this is the expected kernel behaviour? Seems pretty odd to be caused by the charset option: With ascii all is fine: # mount /dev/sda1 /boot -o iocharset=ascii # touch /boot/EFI/A # rm /boot/EFI/a rm: remove regular empty file ‘/boot/EFI/a’? y With UTF8 it breaks: # mount /dev/sda1 /boot -o iocharset=utf8 # touch /boot/EFI/A # rm /boot/EFI/a rm: cannot remove ‘/boot/EFI/a’: No such file or directory And it gets even more weird here: All is fine: [root@lon /]# touch /boot/EFI/a [root@lon /]# touch /boot/EFI/A This fails: [root@lon /]# touch /boot/EFI/A [root@lon /]# touch /boot/EFI/a touch: cannot touch ‘/boot/EFI/a’: File exists -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#758050: [systemd-devel] Bug#758050: udev: ID_VENDOR_FROM_DATABASE, ID_MODEL_FROM_DATABASE for unrecognised USB device are taken from USB hub
On Thu, Aug 14, 2014 at 9:01 PM, Kay Sievers wrote: > On Thu, Aug 14, 2014 at 3:07 PM, Simon McVittie > wrote: >> I recently opened this Debian bug, for which I attach a >> patch that seems to work. Bug report quoted in full below. >> >> I would appreciate udev maintainers' opinions on whether this is >> likely to break non-USB devices, or whether there is a better way >> to do it. > > Maybe replace streq(dsubsys, "usb") with a specific match on " devtype > == usb_device" (sysfs hierarchy is usb_interface -> usb_device) and if > we hit that, we make sure we stop looking at any of the parents? Pushed a fix, similar to your patch, with the above explicit check for "usb_device". Thanks, Kay -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#754411: udev: loop mounts fail after 204-14 update
On Thu, Jul 10, 2014 at 10:55 PM, Michael Biebl wrote: > Am 10.07.2014 22:02, schrieb Peter Poeschl: >> Package: udev >> Version: 204-14 >> Severity: important >> >> Dear Maintainer, >> >>* What led up to the situation? >> udev upgrade from 204-8 to 204-14 removed the file /etc/udev/links.conf. >> >>* What exactly did you do (or not do) that was effective (or >> ineffective)? >> Try to loop-mount a file via an existing /etc/fstab entry >> >>* What was the outcome of this action? >> mount failed with >>mount: Could not find any loop device. Maybe this kernel does not know >> about the loop device? (If so, recompile or `modprobe loop'.) >> >>* What outcome did you expect instead? >> mount succeeds >> >> >> Workaround: >>1) running >> # modprobe loop >> temporarily solves the problem. >> >>2) # echo 'loop' > /etc/modules-load.d/loop.conf >> persistently solves the problem, but I don't know if this is the proper >> solution. >> > > Kay, is the loop modules supposed to be auto-loaded these days or does > it require and explicit modprobe? The logic in util-linux, libmount, losetup, ... tries to access /dev/loop-control which will block and trigger a kernel-side module auto-load. All that is needed is that tmpfiles have created the "dead" device node to access from userspace, and the major/minor of that node will resolve to the kernel module providing the requested device. Kay -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#754411: udev: loop mounts fail after 204-14 update
On Fri, Jul 11, 2014 at 1:35 PM, Michael Biebl wrote: > Am 11.07.2014 05:01, schrieb Kay Sievers: >> The logic in util-linux, libmount, losetup, ... tries to access >> /dev/loop-control which will block and trigger a kernel-side module >> auto-load. >> >> All that is needed is that tmpfiles have created the "dead" device >> node to access from userspace, and the major/minor of that node will >> resolve to the kernel module providing the requested device. > > This seems to be setup correctly afaics: > > # modinfo loop > filename: /lib/modules/3.14-1-amd64/kernel/drivers/block/loop.ko > alias: devname:loop-control > alias: char-major-10-237 > alias: block-major-7-* > license:GPL > depends: > intree: Y > vermagic: 3.14-1-amd64 SMP mod_unload modversions > parm: max_loop:Maximum number of loop devices (int) > parm: max_part:Maximum number of partitions per loop device (int) > > # ls -la /dev/loop* > crw--- 1 root root 10, 237 Jul 11 06:02 /dev/loop-control > > > Yet, mount still fails > # mount -oloop /tmp/ISO/boot.iso /mnt/loop/ > mount: Could not find any loop device. Maybe this kernel does not know >about the loop device? (If so, recompile or `modprobe loop'.) > > Is our mount version too old or should it work irregardless of the mount > version? > > # mount --version > mount from util-linux 2.20.1 (with libblkid and selinux support) # lsmod | grep loop # mount -o loop nothing /mnt mount: nothing: failed to setup loop device: No such file or directory # lsmod | grep loop loop 28197 0 # mount --version mount from util-linux 2.25-rc2 (libmount 2.25.0: selinux, assert, debug) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#759277: gummiboot: function pointer typedefs using KnR-style(?) parameter declarations
On Tue, May 12, 2015 at 2:01 PM, Julian Andres Klode wrote: > Control: forwarded -1 k...@vrfy.org > > (Adding Kay Sievers & Harald Hoyer from upstream) > > On Mon, Aug 25, 2014 at 09:10:48PM +0200, Michael Tautschnig wrote: >> Package: gummiboot >> Version: 45-2 >> Usertags: goto-cc >> Severity: wishlist >> Tags: upstream >> >> While trying to build gummiboot using our research compiler infrastructure >> the >> build stumbled upon the following declaration in src/efi/console.c (from >> line 29 >> onwards): >> >> typedef EFI_STATUS (EFIAPI *EFI_INPUT_RESET_EX)( >> struct _EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL *This; >> BOOLEAN ExtendedVerification; >> ); >> >> While even gcc -Wall -pedantic will emit warnings, clang entirely rejects >> this. >> To address this, the semicolons after the function parameters should be >> replaced >> by commas, and the last one should be omitted, like this: >> >> typedef EFI_STATUS (EFIAPI *EFI_INPUT_RESET_EX)( >> struct _EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL *This, >> BOOLEAN ExtendedVerification >> ); >> >> The same problem appears multiple times in that file. >> >> I'm not sure about the rationale for the chosen syntax and surely this is an >> upstream problem, but I couldn't figure out what their bugtracker was. > > I'm not sure either, I added the upstream authors to the list > of recipients. Just a bug. Surprised that gcc even accepts that. Send a patch if you like it in the gummiboot repo, I'll fix the version in the systemd repo. Thanks, Kay -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#758050: [systemd-devel] Bug#758050: udev: ID_VENDOR_FROM_DATABASE, ID_MODEL_FROM_DATABASE for unrecognised USB device are taken from USB hub
On Thu, Aug 14, 2014 at 3:07 PM, Simon McVittie wrote: > I recently opened this Debian bug, for which I attach a > patch that seems to work. Bug report quoted in full below. > > I would appreciate udev maintainers' opinions on whether this is > likely to break non-USB devices, or whether there is a better way > to do it. Maybe replace streq(dsubsys, "usb") with a specific match on " devtype == usb_device" (sysfs hierarchy is usb_interface -> usb_device) and if we hit that, we make sure we stop looking at any of the parents? Thanks, Kay -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#376589: udev: z25_persistent-net.rules is no longer generated
On Tue, 2006-07-04 at 19:35 +0200, Marco d'Itri wrote: > On Jul 04, Andreas Beckmann <[EMAIL PROTECTED]> wrote: > > > # ignore interfaces without a driver link > > DRIVER!="?*", GOTO="persistent_net_generator_end" > > > > If I comment out this line, z25_persistent-net.rules is generated on > > boot (if it was missing), so the test seems to be too limiting. > Too bad, because it's needed. > > > > Unless you can point me to an actual bug, then the explanation of > > > this behaviour is that your network card(s) do not support generation of > > > persistent rules, older versions of udev lacked some checks which were > > > added later. > > > > Are the following network cards too old? > > # PCI device 14e4:4401 (b44) (onboard) > > # PCI device 10ec:8139 (8139too) (PCI card) > No, and unless you added the drivers name in the comment you reported > it means that the driver symlinks exist because the script has found them. > Kay, do you have any idea about why DRIVER!="?*" is not working as > expected? The device itself does not have a DRIVER value set. We need to select a parent device with BUS to match against DRIVER, but unfortunately there are pci devices in the higher chain which don't have a driver value, so BUS=="?*", DRIVER!="?*" will not work. I see currently no easy solution other than using PHYSDEVDRIVER, until we know how to solve that. > > I attach a copy of /sys/class/net/eth* as described in #368845. > > Kernel 2.6.16-2-k7 (2.6.16-15), there are no 'driver' symlinks. > They are in the device/ directory. Care to provide: udevinfo -a -p /class/net/eth0 That should print all the DRIVER= values, just to check if that is correct. Thanks, Kay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#376589: udev: z25_persistent-net.rules is no longer generated
On Wed, 2006-07-05 at 14:51 +0200, Andreas Beckmann wrote:
> I switched testing to another machine that can be rebooted more easily.
> It has only one (onboard) network interface:
> # PCI device 10ec:8139 (8139too)
>
> Kay Sievers wrote:
> ...
> > Care to provide:
> > udevinfo -a -p /class/net/eth0
> >
> > That should print all the DRIVER= values, just to check if that is
> > correct.
>
> looking at device '/class/net/eth0':
> looking at device '/devices/pci:00/:00:0a.0':
> ID==":00:0a.0"
> BUS=="pci"
> DRIVER=="8139too"
> looking at device '/devices/pci:00':
> ID=="pci:00"
> BUS==""
> DRIVER==""
That looks fine.
> Marco d'Itri wrote:
> > On Jul 04, Andreas Beckmann <[EMAIL PROTECTED]> wrote:
> >
> >> # ignore interfaces without a driver link
> >> DRIVER!="?*", GOTO="persistent_net_generator_end"
> > So try replacing this rule with:
> >
> > PHYSDEVDRIVER!="?*", GOTO="persistent_net_generator_end"
> >
> > and check if it works better.
>
> There is no difference between DRIVER!="?*" and PHYSDEVDRIVER!="?*" - no
> z25_persistent-net.rules created during boot.
PHYSDEVDRIVER is an environment variable set by the kernel and needs to
be in an ENV{} key to match the value.
Kay
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#366853: udev: vol_id returns incorrect information for my root device
> I've found that the problem appears to be related to vol_id failing to > find proper information for my root device, /dev/sda1. I've run the > commands 'e2label', '/lib/udev/vol_id', 'mount' and 'fdisk' with the > following results: Never use any of the all broken mkfs* tools without writing zeros to the start and the end of the partition before applying a different format. Overwrite at least 64kb. (Sane formatting applications like everything that is libparted based don't need this.) Kay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#378839: bluez-pcmcia-support: udev support broken
On Wed, Jul 19, 2006 at 12:16:54PM +0200, Marco d'Itri wrote:
> Is this correct?
>
> - Forwarded message from [EMAIL PROTECTED] -
>
> From: [EMAIL PROTECTED]
> To: Debian Bug Tracking System <[EMAIL PROTECTED]>
> Subject: bluez-pcmcia-support: udev support broken
>
> Package: bluez-pcmcia-support
> Version: 3.1-2
> Severity: grave
> Justification: renders package unusable
>
>
> The udev rules supplied by the package don't work. At least on my
> system tested with a SPHINX and a Sitecom card.
>
> The solution is to replace ENV{BUS} by ENV{PHYSDEVBUS} in
> bluez-pcmcia-support.udev and to correspondingly change $DEVPATH to
> $PHYSDEVPATH in bluetooth.sh, i. e. revert to the solution I sent in
> #351106.
ENV{BUS} never existed, so it can't work. The PHYDEV* values are
deprecated and and should better not be used. They will not go away
soon, but if that can be solved without them, it would be nice.
PHYSDEVBUS is just the subsystem of the parent device, which can
probably be matched with BUS=="pcmcia".
Kay
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#378839: [Pkg-bluetooth-maintainers] Bug#378839: bluez-pcmcia-support: udev support broken
On Tue, 2006-07-25 at 12:52 +0200, Felix Homann wrote:
> On Tuesday 25 July 2006 11:12, Filippo Giunchedi wrote:
> > what about the change from DEVPATH to PHYSDEVPATH Felix proposed in
> > bluetooth.sh?
>
> Hi again,
>
> MANFID=`cat /sys/$PHYSDEVPATH/manf_id`","`cat /sys/$PHYSDEVPATH/card_id`
>
> and
>
> MANFID=`cat /sys/$DEVPATH/device/manf_id`","`cat /sys/$DEVPATH/device/card_id`
>
> seem to be equivalent in this setting. I don't know if either one is prefered
> or deprecated, but I would now prefer the latter since it's simpler:
>
> $DEVPATH -> /class/tty/ttyS2
> $PHYSDEVPATH -> /devices/pci:00/:00:1e.0/:06:01.0/0.0
PHYSDEVPATH and the 'device' link are both deprecated and will go away
some day in the future, you better pass the values you want to use in
your script down from udev with $sysfs{}. That is not dependent on a
specific order of devices in sysfs.
Kay
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#378839: [Pkg-bluetooth-maintainers] Bug#378839: bluez-pcmcia-support: udev support broken
On Tue, 2006-07-25 at 15:43 +0200, Felix Homann wrote:
> On Tuesday 25 July 2006 13:18, Kay Sievers wrote:
> > PHYSDEVPATH and the 'device' link are both deprecated and will go away
> > some day in the future, you better pass the values you want to use in
> > your script down from udev with $sysfs{}. That is not dependent on a
> > specific order of devices in sysfs.
> I've attached working (for me) rules+bluetooth.sh. $sysfs{manf_id} and
> $sysfs{card_id} are passed to bluetooth.sh.
Looks fine, and should not break, if something in sysfs changes, which
is nice.
Btw, you should be able to just do RUN+="bluetooth.sh", as udev will
look in /lib/udev/ if it does not start with a '/'.
Thanks,
Kay
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#501503: udev: Griffin Powermate USB knob doesn't get /dev/input/by-id|path links
On Mon, Apr 27, 2009 at 00:31, Phil Endecott wrote: > So protocol==0 is not specific to this unusual device; even a keyboard or > mouse will have 0 for its non-boot interfaces. So the current logic will > only create /dev/by-id|path nodes for boot interfaces. Is that intentional? These links got added to distinguish multiple keyboards on mainframe-like servers, that's why the rules have been so strict so far, and cover only "real" input devices. :) We see several mouse-like devices, which are not covered by that, and we might need to find a scheme to include them in the link creation. We need to be careful here though, because there are tons of HID devices with "00" which have nothing to do with input devices in the usual sense. I have a thermometer which is exactly like that. :) What kind of kernel devices does this device create, I mean, if you run "udevadm monitor --kernel" and plug it in, what does it say? Care to show the entire sequence? Is it "inputX" only for the input devices, or do you get also a "mouseX" device? Also, care to add the full section of "lsusb -v" for this device? Thanks, Kay -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#501503: udev: Griffin Powermate USB knob doesn't get /dev/input/by-id|path links
On Mon, Apr 27, 2009 at 01:47, Phil Endecott wrote: > Kay Sievers wrote: >> These links got added to distinguish multiple keyboards on >> mainframe-like servers, that's why the rules have been so strict so >> far, and cover only "real" input devices. :) > > Hmm, OK; so how am I supposed to identify things that may be connected to > different sockets and enumerated in different orders each time I use them? Oh, it's just where it comes from, because you asked if it was intentional. >> We see several mouse-like devices, which are not covered by that, and >> we might need to find a scheme to include them in the link creation. >> We need to be careful here though, because there are tons of HID >> devices with "00" which have nothing to do with input devices in the >> usual sense. I have a thermometer which is exactly like that. :) > > Right. I have a Wi-Spy which I think is a HID device. Does it do any harm > to add links for things like that? In this case the input layer should not pick these up, so we would not create a link here, as we hook into input events here. It's just that we should be careful not to add stuff here which we don't really know where it belongs, It's hard to change these links later, when people already use them. >> What kind of kernel devices does this device create, I mean, if you >> run "udevadm monitor --kernel" and plug it in, what does it say? > UEVENT[1240788686.325203] add /class/input/input15/event12 (input) >> Care to show the entire sequence? > > Not sure what you mean. The above sequence of events you posted. >> Is it "inputX" only for the input devices, or do you get also a "mouseX" >> device? > > I get only an eventX device: Ok, so we don't get any other specific class device from the input layer. >> Also, care to add the full section of "lsusb -v" for this device? > > Bus 001 Device 009: ID 077d:0410 Griffin Technology PowerMate The device also does not tell us anything interesting. Does the input subsystem tell us anything specific we might want to use to classify the device? What does: grep . /sys/class/input/inputX/capabilities/* print? Replace the X with the actual number, which changes with every reconnect. Thanks, Kay -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#501503: udev: Griffin Powermate USB knob doesn't get /dev/input/by-id|path links
On Mon, Apr 27, 2009 at 02:36, Kay Sievers wrote: >> Bus 001 Device 009: ID 077d:0410 Griffin Technology PowerMate > > The device also does not tell us anything interesting. > > Does the input subsystem tell us anything specific we might want to > use to classify the device? What does: > grep . /sys/class/input/inputX/capabilities/* > print? Replace the X with the actual number, which changes with every > reconnect. In the meantime, I've added change to append the usb interface number to the event device, if we don't find a common class. This should be unique, and not clash with other interfaces of the same device. It adds the input device of my webcam snow, which should behave in the same way as your device regarding the not catched input class: /dev/input/ |-- by-id | |-- usb-046d_09a4_C4B15020-event-if00 -> ../event13 | |-- usb-Chicony_Electronics_Co.__Ltd._4807-event-if00 -> ../event12 | |-- usb-Logitech_USB-PS_2_Optical_Mouse-event-mouse -> ../event14 ... It's here: http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=4d3657816a9652cc57b7a23c2adc858d83851f02 Thanks, Kay -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#525537: udev: gpio-keys input driver should have class kbd
On Sun, Apr 26, 2009 at 21:54, Marco d'Itri wrote:
> Is this reasonable?
> With udev 0.140 (or rather: sometime after 0.125) we've lost the
> persistent device symlink /dev/input/by-path/platform-gpio-keys-event-
> due to the following change in 60-persistent-input.rules which no longer
> allows an empty ID_CLASS:
> It seems to me that the simplest solution is to let udev define a class
> for gpio-keys (kbd seems most logical), for example with the following
> change in 60-persistent-input.rules:
>
> -DRIVERS=="atkbd", ENV{ID_CLASS}="kbd"
> +DRIVERS=="atkbd|gpio-keys", ENV{ID_CLASS}="kbd"
I guess, this is any key on a system board, and is not like the usual,
pretty well defined "kbd".
For path links of platform devices, we should just create a:
/dev/input/by-path/platform-gpio-keys-event
link, which should be fine as long as there is only a single interface
per platform device. USB devices should also be fine in having this
link, because they include the interface number in the path name.
I've committed a change along with some other pending changes to the
git repository.
Thanks,
Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#422049: udev: udevinfo manual page does not document short options
It's consistent in all udev programs. Only long-options are supported today. The short options are for convenience, or for compatibility to old releases only. Thanks, Kay > Package: udev > Version: 0.105-4 > Severity: minor > File: /usr/bin/udevinfo > > udevinfo accepts some short options that are not documented in the > manual page or in udevinfo --help. It would be nice if they were > documented in both places. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#459788: libvolume-id-dev: Missing definition of ${exec_prefix} in generated pkgconfig data
On Tue, 2008-01-08 at 18:17 +, Neil Williams wrote: > When cross building packages depending on libvolume-id, pkgconfig fails > to parse the pc file generated by udev because the exec_prefix value is > not defined: > > $ pkg-config /usr/arm-linux-gnu/lib/pkgconfig/libvolume_id.pc --libs > libvolume_id > Variable 'exec_prefix' not defined in > '/usr/arm-linux-gnu/lib/pkgconfig/libvolume_id.pc' > The pc file is missing the first two lines: > prefix= > exec_prefix= > > The values for the missing variables are not particularly important, but > pkg-config does require that the variables are specified so that it can > work out how to calculate dependencies during the cross build. Short > circuiting this step by hardcoding the value for libdir as /usr/lib > prevents pkg-config from converting libdir to be /usr/arm-linux-gnu/lib > etc. when cross compiling. > > The attached patch adds dummy values to the pc file which allow > pkg-config to operate correctly: Applied. Thanks, Kay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#348221: udev: create /dev/em8300* nodes
On Tue, Jan 17, 2006 at 09:42:57PM +0100, Marco d'Itri wrote: > On Jan 17, Kay Sievers <[EMAIL PROTECTED]> wrote: > > > That driver seem to bypass the kernel driver core. If that's the case > > the driver needs to be fixed as udevd depends on proper MAJOR/MINOR export > > in the environment now, which happens automatically if the class > > interface is used correctly. > Even if it worked with 079? Yes, udev 080 depends on proper driver core integration. With the removal of libsysfs, we have been able to optimize udev's operation not to need to open any sysfs file for a simple event, which is much more efficient. Thanks, Kay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#348221: udev: create /dev/em8300* nodes
On Tue, Jan 17, 2006 at 09:50:21PM +0100, Kay Sievers wrote:
> On Tue, Jan 17, 2006 at 09:42:57PM +0100, Marco d'Itri wrote:
> > On Jan 17, Kay Sievers <[EMAIL PROTECTED]> wrote:
> >
> > > That driver seem to bypass the kernel driver core. If that's the case
> > > the driver needs to be fixed as udevd depends on proper MAJOR/MINOR export
> > > in the environment now, which happens automatically if the class
> > > interface is used correctly.
>
> > Even if it worked with 079?
>
> Yes, udev 080 depends on proper driver core integration. With the
> removal of libsysfs, we have been able to optimize udev's operation
> not to need to open any sysfs file for a simple event, which is
> much more efficient.
I see this in the driver in file em8300_sysfs.c:
static CLASS_DEVICE_ATTR(dev, S_IRUGO, show_devnum, NULL);
static struct class_device_attribute *em8300_attrs[] = {
&class_device_attr_version,
&class_device_attr_dev,
NULL
};
This needs to be fixed to use the:
dev_t devt; /* dev_t, creates the sysfs "dev" */
in the struct class_device instead. Then udev will create the node
again.
Kay
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#348866: udev: 0.081-1 doesn't boot on 2.6.15 kernel
On Thu, Jan 19, 2006 at 03:24:05PM +0100, Marco d'Itri wrote: > The boot procedure stop after some times at parport without creating devices > (eg ttyS0 and others). > The udev 0.080-1 had same behaviour. Previous versions to 0.080 where > working. On the console I see: > > udevd [811]: udev_done seq 771, pid [892] exit with 1, 178 seconds old > > The above line is repeated from seq 771 to 780. Also, an error like > > udevd [811]: get_msg_from_envbuf: DEVPATH missing, ignore message Hmm, this should be almost impossible to have the kernel send an event without DEVPATH. No idea what's going on here. Are we sure that nothing uses udevsend or any other tool that talks to the udev daemon? Does blacklisting or temporarily renaming the modules "parport_pc" and "parport" and "lp" make the box booting? Kay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#350613: [EMAIL PROTECTED]: Bug#350613: Minor typo in manpage]
On Mon, Jan 30, 2006 at 10:51:10PM +0100, Marco d'Itri wrote: > small typo in the manpage: >GOTO Jumps to the next LABEL with a matching gname > should read >GOTO Jumps to the next LABEL with a matching name Fixed. Thanks, Kay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#350235: [EMAIL PROTECTED]: Re: Re: Bug#350235: ide pcmcia problem]
On Fri, Feb 03, 2006 at 12:32:40PM +0100, Marc Haber wrote: > On Wed, Feb 01, 2006 at 10:52:25AM +0100, Marco d'Itri wrote: > > On Feb 01, Marc Haber <[EMAIL PROTECTED]> wrote: > > > On Wed, Feb 01, 2006 at 03:08:42AM +0100, Kay Sievers wrote: > > > > What does udevtest print on your box? > > > With or without the block/removable rule in place? With or without the > > > CF card inserted? > > With the rule and the card. > > $ sudo udevtest /block/hde > Password: > main: looking at device '/block/hde' from subsystem 'block' > run_program: '/sbin/cdrom_id --export /dev/.tmp-33-0' > run_program: '/sbin/cdrom_id' returned with status 3 > udev_rules_get_name: no node name set, will use kernel name 'hde' > create_node: creating device node '/dev/hde', major = '33', minor = '0', mode > = '0660', uid = '0', gid = '25' > main: run: 'socket:/org/kernel/udev/monitor' > main: run: '/etc/init.d/hdparm hotplug' > main: run: 'udev_run_hotplugd block' > main: run: 'udev_run_devd block' > > Sorry for taking so much time. Oh, you need to make sure, that cdrom_id and nothing else runs on _any_ removable ide drive, just like the persistent disk rules are skipped. Every open() of a removable ide device will cause a revalidation of the partition table, which caues the events to loop. Kay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#351606: [EMAIL PROTECTED]: Re: Bug#351606: multipath mis-detects SATA raid1 by default]
On Thu, Feb 09, 2006 at 08:25:14PM +0100, Bastian Blank wrote: > Hi folks > > I got the following bugreport against multipath-tools, which by default > uses scsi_id to detect multiple paths. > > scsi_id on SATA devices (via libata) returns a string like: > | 0ATA_ST3160827AS_Linux_ATA-SCSI_simulator Add this: $ cat /etc/scsi_id.config vendor="ATA",options=-p 0x80 Kay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#350235: pcmciautils ?
On Sun, Jan 29, 2006 at 12:07:50PM +0100, Marco d'Itri wrote: > On Jan 29, di dit <[EMAIL PROTECTED]> wrote: > > I can see why the rule does not work, at the removable==1 level we have > BUS=="block" instead of the expected BUS=="ide", and DRIVER is only > available at the upper level. > Kay? Correct, that broke with the stricter logic to select the parent device in the recent udev. I'll go fix udev also to look at SYSFS at the device we received the event for and not only at the device selected by BUS. Then it should work again. In the case you compile udev yourself, can you check, if adding this to udev_rules.c fixes this? I'm on the road at the moment and don't have an IDE device, but the same logic works when testing with scsi. value = sysfs_attr_get_value(udev->dev_parent->devpath, key_name); if (value == NULL) + value = sysfs_attr_get_value(udev->dev->devpath, key_name); + if (value == NULL) goto try_parent; strlcpy(val, value, sizeof(val)); Thanks, Kay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#350235: pcmciautils ?
On Sun, Jan 29, 2006 at 12:07:50PM +0100, Marco d'Itri wrote:
> On Jan 29, di dit <[EMAIL PROTECTED]> wrote:
>
> I can see why the rule does not work, at the removable==1 level we have
> BUS=="block" instead of the expected BUS=="ide", and DRIVER is only
> available at the upper level.
> Kay?
>
> BUS=="ide", SYSFS{removable}=="1", DRIVER!="ide-cdrom", GOTO="no_volume_id"
>
>
> Maybe a rule like this one would work, but is it correct? (And how are
> people going to figure this?)
>
> BUS=="ide", SYSFS{block/removable}=="1", DRIVER!="ide-cdrom",
> GOTO="no_volume_id"
Sure, it is correct, but we should better not introduce dependencies on
the weird symlinks that crosslink "class devices" and "devices", they
will probably go away when we change /sys/devices to a sane layout and
the "block device" will just become a real child of the "device".
Changing udev to look with SYSFS{} at the device we got the event for,
should work just fine.
Thanks,
Kay
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#350490: udev 0.083-1 do not mount my usb drives (disk, mobile). With 0.082 it works. I downgrade it to work again
On Wed, Feb 01, 2006 at 12:00:26AM +0100, Sjoerd Simons wrote:
> On Tue, Jan 31, 2006 at 10:54:08PM +0100, Marco d'Itri wrote:
> > On Jan 30, Michael Ott <[EMAIL PROTECTED]> wrote:
> >
> > > I believe that dbus or fam will mount my disk. But my mobile memory will
> > > mount with udev 0.082 and not with 0.083. I remember that it works
> > > yesterday and after update it did not work.
> > I see that #350762 has been opened too against HAL, but I still do not
> > know what's wrong. Sjoerd, do you have any ideas about this? Kay?
> >
> > The relevant rules are:
> >
> > ENV{SEQNUM}=="[0-9]*", ENV{UDEVD_EVENT}=="1",
> > RUN+="/usr/lib/hal/hal.hotplug"
> >
> > BUS="scsi",KERNEL="sd[a-z]*",
> > PROGRAM="/etc/udev/scripts/device-removable.sh %k 'usb ieee1394'",
> > RESULT="1", MODE="0640", GROUP="hal"
> >
> > BUS="usb", KERNEL="ub[a-z]*", MODE="0640", GROUP="hal"
>
> As you guessed correctly in an earlier mail. Not adding $SUBSYSTEM as $1 to
> programs anymore breaks the hal hotplug helper.
>
> The hal currently in experimental has udev passing events over a socket
> instead
> of using the helper, so it works fine. Didn't upload it to unstable directly
> because it had the first version of my priv. patch applied to it.
>
> Luckily the priv. sep. patch seems to work fine. So i'm planning to upload
> hal
> 0.5.6 with the current priv. sep. patch and some other patches from HAL CVS
> to
> unstable which should fix this issue :)
Oh, yeah, sorry forgot the old hal helper cause we don't use it anymore for a
long time. Adding $env{SUBSYSTEM} to the rule should fix it. The current HAL
will
install its own rule in the udev directory by default.
Kay
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#350235: [EMAIL PROTECTED]: Re: Re: Bug#350235: ide pcmcia problem]
> From: Marc Haber <[EMAIL PROTECTED]>
> To: Marco d'Itri <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> Cc: Marc Haber <[EMAIL PROTECTED]>
> Subject: Re: Re: Bug#350235: ide pcmcia problem
>
> found 350235 0.84-1
> thanks
>
> On Sat, Jan 28, 2006 at 01:51:39PM +0100, Marco d'Itri wrote:
> > Indeed... But maybe the recent changes in sysfs processing in udev broke
> > the rule. First, try removing the symlink to persistent.rules to verify
> > that it actually is what is exposing the bug, then after you succesfully
> > loaded the driver check with something like:
> >
> > udevinfo -a -p /block/hde/hde1
> >
> > why it's not working.
>
> I have seen the same issues on my notebook, with udev 0.84-1.
>
> > A workaround may be to add again this rule:
> >
> > BUS=="ide", SYSFS{../removable}=="1", DRIVER!="ide-cdrom",
> > GOTO="no_volume_id"
>
> I needed that addition to make the PCMCIA CF card work.
Hmm, I found a CF card and the rule works fine for me:
match_key: key DRIVER value='ide-cdrom'
match_key: match DRIVER 'ide-cdrom' <-> 'ide-disk'
match_key: DRIVER is true (non-matching value)
match_key: key BUS value='ide'
match_key: match BUS 'ide' <-> 'ide'
match_key: BUS is true (matching value)
match_rule: check 1 SYSFS keys
sysfs_attr_get_value: open
'/devices/pci:00/:00:1e.0/:04:00.0/0.0/ide0/0.0'/'removable'
sysfs_attr_get_value: new uncached attribute
'/sys/devices/pci:00/:00:1e.0/:04:00.0/0.0/ide0/0.0/removable'
sysfs_attr_get_value: add to cache
'/sys/devices/pci:00/:00:1e.0/:04:00.0/0.0/ide0/0.0/removable'
sysfs_attr_get_value: attribute
'/sys/devices/pci:00/:00:1e.0/:04:00.0/0.0/ide0/0.0/removable' does
not exist
sysfs_attr_get_value: open '/block/hda'/'removable'
sysfs_attr_get_value: new uncached attribute '/sys/block/hda/removable'
sysfs_attr_get_value: add to cache '/sys/block/hda/removable'
sysfs_attr_get_value: cache '/sys/block/hda/removable' with value '1'
match_rule: removed 0 trailing whitespace chars from '1'
match_key: key SYSFS value='1'
match_key: match SYSFS '1' <-> '1'
match_key: SYSFS is true (matching value)
match_rule: all 1 SYSFS keys matched
udev_rules_get_name: moving forward to label 'persistent_end'
What does udevtest print on your box?
This is for the CF card:
pim:/home/kay/work/src/udev # ./udevtest /block/hda
main: looking at device '/block/hda' from subsystem 'block'
udev_rules_get_name: no node name set, will use kernel name 'hda'
create_node: creating device node '/dev/hda', major = '3', minor = '0', mode
= '0640', uid = '0', gid = '6'
main: run: '/lib/udev/idedma.sh /dev/hda'
main: run: 'socket:/org/freedesktop/hal/udev_event'
main: run: 'socket:/org/kernel/udev/monitor'
This is for a real disk:
pim:/home/kay/work/src/udev # ./udevtest /block/sda
main: looking at device '/block/sda' from subsystem 'block'
run_program: '/sbin/usb_id -x'
run_program: '/sbin/usb_id' returned with status 1
run_program: '/sbin/scsi_id -g -x -s /block/sda -d /dev/.tmp-8-0'
run_program: '/sbin/scsi_id' (stdout) 'ID_VENDOR=ATA'
run_program: '/sbin/scsi_id' (stdout) 'ID_MODEL=HTS726060M9AT00'
run_program: '/sbin/scsi_id' (stdout) 'ID_REVISION=MH4O'
run_program: '/sbin/scsi_id' (stdout)
'ID_SERIAL=SATA_HTS726060M9AT00_MRH453M4HWHG7B'
run_program: '/sbin/scsi_id' (stdout) 'ID_TYPE=disk'
run_program: '/sbin/scsi_id' (stdout) 'ID_BUS=scsi'
run_program: '/sbin/scsi_id' returned with status 0
udev_rules_get_name: add symlink
'disk/by-id/scsi-SATA_HTS726060M9AT00_MRH453M4HWHG7B'
run_program: '/sbin/path_id /block/sda'
run_program: '/sbin/path_id' (stdout) 'ID_PATH=pci-:00:1f.2-scsi-0:0:0:0'
run_program: '/sbin/path_id' returned with status 0
udev_rules_get_name: add symlink 'disk/by-path/pci-:00:1f.2-scsi-0:0:0:0'
run_program: '/sbin/vol_id --export /dev/.tmp-8-0'
run_program: '/sbin/vol_id' returned with status 4
run_program: '/sbin/edd_id --export /dev/.tmp-8-0'
run_program: '/sbin/edd_id' (stdout) 'ID_EDD=int13_dev80'
run_program: '/sbin/edd_id' returned with status 0
udev_rules_get_name: add symlink 'disk/by-id/edd-int13_dev80'
udev_rules_get_name: no node name set, will use kernel name 'sda'
create_node: creating device node '/dev/sda', major = '8', minor = '0', mode
= '0640', uid = '0', gid = '6'
create_node: creating symlink
'/dev/disk/by-id/scsi-SATA_HTS726060M9AT00_MRH453M4HWHG7B' to '../../sda'
create_node: creating symlink
'/dev/disk/by-path/pci-:00:1f.2-scsi-0:0:0:0' to '../../sda'
create_node: creating symlink '/dev/disk/by-id/edd-int13_dev80' to '../../sda'
main: run: 'socket:/org/freedesktop/hal/udev_event'
main: run: 'socket:/org/kernel/udev/monitor'
Kay
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#591290: Buffer I/O error on device sr0, logical block 0
> When booting with an audio CD in the drive, at the stage of udev > populating /dev/ I see these errors on the screen and also in the > dmesg output: > . > [ 11.216120] sr 3:0:0:0: [sr0] Result: hostbyte=DID_OK > driverbyte=DRIVER_SENSE > [ 11.216127] sr 3:0:0:0: [sr0] Sense Key : Illegal Request [current] > [ 11.216135] sr 3:0:0:0: [sr0] Add. Sense: Illegal mode for this track > [ 11.216144] sr 3:0:0:0: [sr0] CDB: Read(10): 28 00 00 00 00 00 00 > 00 02 00 Maybe a not fixed udisks, called from udev rules: http://cgit.freedesktop.org/udisks/commit/?id=c2464f7bf215cd17962e917b974c573378d4e58b Udev should not cause this anymore. Doing udevadm test /class/block/sr0 should show what's actually called, and repeating the listed calls manually, should show in the log what's causing the messages. Kay -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#583283: udev - Weird behaviour with device names including a slash
Yeah, devtmpfs misses the magic '!' -> '/' support. I'll go and fix this.
If you don't want to change the device name, you can fill-in the name
in the miscdevice structure, like:
static struct miscdevice tun_miscdev = {
.minor = TUN_MINOR,
.name = "tun",
.nodename = "net/tun",
.fops = &tun_fops,
};
Kay
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#583283: udev - Weird behaviour with device names including a slash
I take that back, tested it, devtmpfs works fine with the '!' magic. The driver core translates the stuff already. Looks like a different issue then. If you kill udevd, unload the module, delete the possible remaining node, then load the module again, what has devtmpfs created? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#574270: Functionality overlap between udev's modem-modeswitch and usb-modeswitch about 19d2:2000
On Thu, Mar 18, 2010 at 17:48, Didier 'OdyX' Raboud wrote:
> Hi udev upstreams !
>
> (please keep me and the Debian bug CC'ed).
>
> I am the Debian maintainer for usb-modeswitch and I got a user reporting that
> his 3G dongle was not "switched" anymore [0]. After some investigation, I
> strongly suspect that udev's modem-modeswitch and usb-modeswitch have a
> conflicting functionality overlap.
>
> From /lib/udev/rules.d/61-mobile-action.rules :
>
>> # modem-modeswitch does not work with these devices, the fake CD-ROM needs to
> be ejected
>>
>> # ZTE MF6xx
>> ACTION=="add", ENV{ID_CDROM}=="1", ENV{ID_VENDOR_ID}=="19d2",
> ENV{ID_MODEL_ID}=="2000", RUN+="/usr/bin/eject %k"
>
> From /lib/udev/rules.d/40-usb_modeswitch.rules :
>
>> # ZTE devices
>> ATTRS{idVendor}=="19d2", ATTRS{idProduct}=="2000", RUN+="usb_modeswitch
> '%b/%k'"
>
> It seems (to me) that those lines should be removed from udev (as
> usb-modeswitch
> provides a generic switching facility for more than "just" 19d2:2000.
>
> What is your opinion thereabout ?
If Dan has no objections, we are ready to delete modem-modeswitch from
the udev tree.
Kay
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#550152: udev - Remove symlinks
On Sun, Apr 18, 2010 at 23:08, Marco d'Itri wrote: >> On Apr 18, Mario 'BitKoenig' Holbe wrote: >> > KERNEL=="audio", NAME="%k0", SYMLINK+="%k" >> Nowadays this is considered bad, accordingly to the upstream maintainer >> you should not change the kernel name of a device. > > $ grep -rl 'NAME=[^=]' /etc/udev/rules.d /lib/udev/rules.d > /etc/udev/rules.d/70-persistent-net.rules NAME for network devices is fine. They also rename the kernel device. > /etc/udev/rules.d/00-local.rules If this specifies a name different than the kernel device name, it is something that should be fixed. > /lib/udev/rules.d/75-persistent-net-generator.rules NAME for network devices is fine, as mentioned. > /lib/udev/rules.d/55-dm.rules Device-mapper is work-in-progress, and probably just uses NAME="" which is ok. (should still not be done that way, but it does not matter here). > /lib/udev/rules.d/50-udev-default.rules It's probably just for support of older kernels, or for deprecated subsystems drivers like "ieee1394", which need to be replaced by "firewire". There should be no rule that specifies a name that is different from the kernel device name. > Apart from my own rules this seems to be quite a common behaviour. Swapping plain kernel-defined names with symlinks is not supported. It may work, but the behavior is undefined. Recent kernels provide *all* device node names, and with devtmpfs they also manage their creation and deletion. On recent systems, udev is only expected to manage additional symlinks and the permissions of the kernel-created device node. > Well, I think moving device nodes forth and back in the /dev tree is > quite common behavior Upstream udev does not really support this. Kernel device names are defined (and optionally created and deleted) by the kernel these days. Thanks, Kay -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#550152: udev - Remove symlinks
On Mon, Apr 19, 2010 at 11:46, Marco d'Itri wrote:
> On Apr 19, Kay Sievers wrote:
>
>> > /lib/udev/rules.d/55-dm.rules
>> Device-mapper is work-in-progress, and probably just uses NAME=""
>> which is ok.
> There is this rule, which is what the original poster was complaining
> about:
>
> ENV{DM_NAME}=="?*", NAME="mapper/$env{DM_NAME}", SYMLINK+="$kernel"
This is not supported and must be fixed. Udev does not support
swapping primary device names around, and devtmpfs will always create
the device node with the kernel name anyway.
If this is the intended behavior, the dm driver in the kernel needs to
provide this name (the kernel would need to properly be able to handle
block device renames though, which it can't. So is it not expected to
be the case anytime soon).
Kay
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#550152: udev - Remove symlinks
On Mon, Apr 19, 2010 at 12:13, Bastian Blank wrote: > On Mon, Apr 19, 2010 at 11:56:37AM +0200, Kay Sievers wrote: >> This is not supported and must be fixed. Udev does not support >> swapping primary device names around, and devtmpfs will always create >> the device node with the kernel name anyway. > > The documentation does not stat this constraint. It's a recent change in behavior. Please add this, if you think it should be mentioned. > And udev is not devtmpfs. I guess, I know a bit about both. :) And devtmpfs, which is mandatory by most major distros now, changed a bit of udev's logic. Udev is still expected to work without devtmpfs, but devtmpfs still defines the supported udev features, and some future version of udev may even require devtmpfs. Kay -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#550152: udev - Remove symlinks
On Mon, Apr 19, 2010 at 13:28, Mario 'BitKoenig' Holbe
wrote:
> On Mon, Apr 19, 2010 at 11:39:28AM +0200, Kay Sievers wrote:
>> On Sun, Apr 18, 2010 at 23:08, Marco d'Itri wrote:
>> >> On Apr 18, Mario 'BitKoenig' Holbe wrote:
>> >> > KERNEL=="audio", NAME="%k0", SYMLINK+="%k"
>> > /etc/udev/rules.d/00-local.rules
>>
>> If this specifies a name different than the kernel device name, it is
>> something that should be fixed.
>
> These are my own local rules and yes, these rules specify lots of
> rename-rules like the one above.
>
> Call it obsessive (well, this is what I'm calling it sometimes :)) or
> whatever you like. I personally don't like the kernel's style to threat
> 0-devices naming different than subsequent ones and prefer the other way
> around. I was free to do this all the time from the beginning of ages
> (i.e. static, fs-based /dev) up to udev 141. I always did this at my own
> risk and it was never a problem. I don't want to push my opinion about
> this to others, and I'm sure there are others with exactly the opposite
> opinion. I'd just like to be free again :)
Yeah, I'll check the current behavior, and if this is easy to fix.
It's weird to delete a link we just created in the same moment
ourselves. :)
But it might still cause problems now or in the future to replace the
defined kernel name with a symlink with the same name. Multiple
devices can claim the same name and the actual link that is created
get managed by a priority value. When a device goes away, the link
with the next highest priority is re-created. This all will fail in
interesting ways if links and node names are mixed. So the supported
solution is not to touch the kernel names and let udev manage only
symlinks to the standard kernel-provided name.
> I don't know what you exactly consider "different"... just a few
> examples for you to explain which of those you consider "good" and which
> "bad":
>
> SUBSYSTEM=="bsg", NAME="bsg/%k"
> SUBSYSTEMS=="usb", KERNEL=="hiddev[0-9]*", NAME="usb/%k"
> SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device",
> NAME="bus/usb/$env{BUSNUM}/$env{DEVNUM}"
> KERNEL=="capi", NAME="capi20",
> KERNEL=="capi[0-9]*", NAME="capi/%n"
> KERNEL=="card[0-9]*", NAME="dri/%k"
> KERNEL=="hw_random", NAME="hwrng"
> KERNEL=="cdemu[0-9]*", NAME="cdemu/%n"
> KERNEL=="pktcdvd[0-9]*", NAME="pktcdvd/%n"
> KERNEL=="cpu[0-9]*", NAME="cpu/%n/cpuid"
They are all gone from the upstream rules, and provided by the kernel
itself. And are only needed for older kernels. There is a
"compat.rules" file in the udev tree which has collected all these
rules, in case old kernels should run with a new udev:
http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob;f=rules/gentoo/30-kernel-compat.rules;hb=HEAD
>> > Apart from my own rules this seems to be quite a common behaviour.
>> Swapping plain kernel-defined names with symlinks is not supported. It
>> may work, but the behavior is undefined.
>
> Well, this is basically the reason why in my own local rules I generally
> provide symlinks from the kernel-defined names to the ones I prefer
> (which triggers the bug we were talking about here :)).
>
>> > Well, I think moving device nodes forth and back in the /dev tree is
>> > quite common behavior
>> Upstream udev does not really support this. Kernel device names are
>> defined (and optionally created and deleted) by the kernel these days.
>
> All right, devfs-style so to say.
It is a real devfs. With devtmpfs the model for udev has changed a
bit. We passed control over the device nodes, and the names to the
kernel, and udev it is expected to manage only permissions and
additional symlinks now.
Kay
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#550152: udev - Remove symlinks
Udev should no longer delete the link it has created: http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=6252f9e732c827defdac38e2eccab0657492d9c9 Still, replacing the default kernel-named nodes with links with the same name can result in unexpected behavior and is not supported. It does not matter if devtmpfs is used or not, today the kernel defines the device nodes names, and udev manages only additional symlinks and the node's permissions. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#515598: persistent disk symlinks changed - to _, nothing in changelog
On Tue, 2009-03-03 at 17:57 +0100, Michael Prokop wrote: > * martin f krafft [20090303 16:01]: > > also sprach Marco d'Itri [2009.02.16.1622 +0100]: > > > > udev used to create links like > > > I remember seeing another bug about this (which should be open), but I > > > am not inclined to add compatibility symlinks unless there is a lot of > > > pressure. > > > Is this upstream who took the liberty to just change *persistent* > > symlinks, did they not foresee the consequences of their actions, or > > is this a packaging thing? > > AFAICS this is due to a change in upstream's > udev_util_replace_chars() of udev/lib/libudev-util.c, used via > scsi_id() in udev/extras/scsi_id/scsi_id.c. ata-* links should be created by values from ata_id not scsi_id. Please check with: udevadm test /block/sda or udevtest /block/sda where the difference is coming from. Kay -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#501503: udev: Griffin Powermate USB knob doesn't get /dev/input/by-id|path links
On Wed, Mar 18, 2009 at 10:48, Marco d'Itri wrote:
> From: Phil Endecott
> I have a Griffin Powermate, which is a USB "knob" that can be used as
> e.g. a volume control, for scrolling through video/audio, etc. No
> /dev/input/by-* links are created for it. This is because
> persistent-input.rules only sets ENV{ID_CLASS} for keyboards and mice
> when it recognises them from their ATTRS{bInterfaceProtocol}. This
> device has ATTRS{bInterfaceProtocol}==0. I have added this, to give
> it class "misc"; I'm not sure if there is an official USB-spec-defined
> meaning for protocol==0 that I should be using:
>
> SUBSYSTEMS=="usb", \
> ATTRS{bInterfaceClass}=="03", ATTRS{bInterfaceProtocol}=="00", \
> ENV{ID_CLASS}="misc"
> I now get the desired symlinks:
>
> /dev/input/by-id/usb-Griffin_Technology,_Inc._Griffin_PowerMate-event-misc
> /dev/input/by-path/pci-:00:10.2-usb-0:1:1.0-event-misc
It's undefined if bInterfaceProtocol is 0.
What is the subclass value of the device? Like "lsusb -v" prints for a mouse:
bNumEndpoints 1
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 1 Boot Interface Subclass
bInterfaceProtocol 2 Mouse
Thanks,
Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#591290: Buffer I/O error on device sr0, logical block 0
On Mon, Aug 9, 2010 at 08:02, Stanislav Maslovski wrote: > On Tue, Aug 03, 2010 at 08:20:03AM +0200, Kay Sievers wrote: > Thanks for your input. I did what you suggested; the log from runnig > 'udevadm test /class/block/sr0' is attached to this e-mail. I see lots > of the same errors in dmesg when I run this test (see below). I can do > further tests if you tell me which calls I should run manually. It's a Debian bug. With upstream udev rules from 'make install', blkid runs only for data disks. Kay -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#561279: udev: Crash location and first-level cause
> srv:~# udevadm info > custom logging function 0x160e010 registered > selinux=0 > calling: info > Segmentation fault This was likely caused by using a va_list twice. This is expected to fix it: http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=d5a01cb8b31bd0791d1617c56d4c669a02018bd7 Thanks, Kay -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
