Bug#759277: gummiboot: function pointer typedefs using KnR-style(?) parameter declarations
On Tue, May 12, 2015 at 2:01 PM, Julian Andres Klode j...@debian.org 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 9:01 PM, Kay Sievers k...@vrfy.org wrote: On Thu, Aug 14, 2014 at 3:07 PM, Simon McVittie simon.mcvit...@collabora.co.uk 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#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 simon.mcvit...@collabora.co.uk 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#754411: udev: loop mounts fail after 204-14 update
On Fri, Jul 11, 2014 at 1:35 PM, Michael Biebl bi...@debian.org 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#754411: udev: loop mounts fail after 204-14 update
On Thu, Jul 10, 2014 at 10:55 PM, Michael Biebl bi...@debian.org 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#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 j...@debian.org 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 j...@debian.org 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 j...@debian.org 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 j...@debian.org 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#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 sh...@churchofgit.com 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#725714: udev firmware loading does not work in the Debian installer
On Fri, Dec 13, 2013 at 12:12 AM, Andreas Cadhalpun andreas.cadhal...@googlemail.com wrote: On 12.12.2013 23:19, Kay Sievers wrote: On Thu, Dec 12, 2013 at 10:58 PM, Michael Biebl em...@michaelbiebl.de 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 em...@michaelbiebl.de 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 em...@michaelbiebl.de 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 em...@michaelbiebl.de 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 b...@decadent.org.uk 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#591290: Buffer I/O error on device sr0, logical block 0
On Mon, Aug 9, 2010 at 08:02, Stanislav Maslovski stanislav.maslov...@gmail.com 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#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#550152: udev - Remove symlinks
On Sun, Apr 18, 2010 at 23:08, Marco d'Itri m...@linux.it wrote: On Apr 18, Mario 'BitKoenig' Holbe mario.ho...@tu-ilmenau.de 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 m...@linux.it wrote:
On Apr 19, Kay Sievers kay.siev...@vrfy.org 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 wa...@debian.org 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
mario.ho...@tu-ilmenau.de 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 m...@linux.it wrote:
On Apr 18, Mario 'BitKoenig' Holbe mario.ho...@tu-ilmenau.de 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#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 did...@raboud.com 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#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
Bug#525537: udev: gpio-keys input driver should have class kbd
On Sun, Apr 26, 2009 at 21:54, Marco d'Itri m...@linux.it 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#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 phil_cmcsb_endec...@chezphil.org 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 phil_cmcsb_endec...@chezphil.org 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 kay.siev...@vrfy.org 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#515598: persistent disk symlinks changed - to _, nothing in changelog
On Tue, 2009-03-03 at 17:57 +0100, Michael Prokop wrote: * martin f krafft madd...@debian.org [20090303 16:01]: also sprach Marco d'Itri m...@linux.it [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 m...@linux.it wrote:
From: Phil Endecott spam_from_debian_bug...@chezphil.org
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#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#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#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#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#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#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#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 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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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 Address 0x1c4 out of bounds)
at namedev.c:50
50 if (s[0] == '\0') {
(gdb) where
#0 strcmp_pattern (p=0x805cc60 ipw2100, s=0x1c4 Address 0x1c4 out of
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/ethN
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#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#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#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]
