[arch-dev-public] [signoff] udev-172
Hi guys, A new udev version is in [testing], please test and signoff. Packaging changes: ============ Support for non-devtmpfs /dev is now moved from udev to udev-compat. This leaves only one static devices node (loop0) in the main udev package. This is needed due to broken design in the kernel, which hopefully one day should be fixed. Further deletion of arch specific rules: No more symlinks for cdroms (only a small subset of cdroms were given symlinks, this was inconsistent, so stop doing that). Framebuffer devices are no longer in the video group. Permissions and ownership of framebuffer devices are handled by X, so having udev rules which has no effect is just confusing (in case users want to change the group, the need to do it in xorg.conf). rtc and kbd devices are no longer world readable. Having kbd world readable looks like an invitation for key-loggers. rtc is no longer in the audio group. This does not make much sense, and the same change was made by other distros a long time ago. Framebuffer blacklisting: The blacklist file is moved from /etc/modprobe.d to /lib/modprobe.d, where it belongs. This means we can update the file without creating .pacsave files, and if a user wants to override the file it should be done by copying the file to /etc and editing it there (this file is no longer under the control of pacman). In other words, the modprobe .conf files work in the same way as the udev .rules files. Upstream changes: ============ Udev now enables kernel media-presence polling if available. Part of udisks optical drive tray-handling moved to cdrom_id: The tray is locked as soon as a media is detected to enable the receiving of media-eject-request events. Media-eject-request events will eject the media. Libudev enumerate is now able to enumerate a subtree of a given device. The mobile-action-modeswitch modeswitch tool was deleted. The functionality is provided by usb_modeswitch now. -- In addition two bugs were fixed upstream after being found by Arch user James Morris; and support for referencing disks by PARTUUID were added after a suggestion from Arch user Keshav P. R. (this should be useful for mkinitramfs). Well done guys! Cheers, Tom
Le 11 juillet 2011 12:15:59 Tom Gundersen a écrit :
Hi guys,
A new udev version is in [testing], please test and signoff.
Packaging changes: ============
Support for non-devtmpfs /dev is now moved from udev to udev-compat. This leaves only one static devices node (loop0) in the main udev package. This is needed due to broken design in the kernel, which hopefully one day should be fixed.
Further deletion of arch specific rules:
No more symlinks for cdroms (only a small subset of cdroms were given symlinks, this was inconsistent, so stop doing that). Framebuffer devices are no longer in the video group. Permissions and ownership of framebuffer devices are handled by X, so having udev rules which has no effect is just confusing (in case users want to change the group, the need to do it in xorg.conf). rtc and kbd devices are no longer world readable. Having kbd world readable looks like an invitation for key-loggers. rtc is no longer in the audio group. This does not make much sense, and the same change was made by other distros a long time ago.
Framebuffer blacklisting:
The blacklist file is moved from /etc/modprobe.d to /lib/modprobe.d, where it belongs. This means we can update the file without creating .pacsave files, and if a user wants to override the file it should be done by copying the file to /etc and editing it there (this file is no longer under the control of pacman). In other words, the modprobe .conf files work in the same way as the udev .rules files.
Upstream changes: ============
Udev now enables kernel media-presence polling if available. Part of udisks optical drive tray-handling moved to cdrom_id: The tray is locked as soon as a media is detected to enable the receiving of media-eject-request events. Media-eject-request events will eject the media.
Libudev enumerate is now able to enumerate a subtree of a given device.
The mobile-action-modeswitch modeswitch tool was deleted. The functionality is provided by usb_modeswitch now.
--
In addition two bugs were fixed upstream after being found by Arch user James Morris; and support for referencing disks by PARTUUID were added after a suggestion from Arch user Keshav P. R. (this should be useful for mkinitramfs). Well done guys!
Cheers,
Tom
My laptop still works as usual after a reboot. Signoff x86_64. Stéphane
On 11 July 2011 13:15, Tom Gundersen <teg@jklm.no> wrote:
Hi guys,
A new udev version is in [testing], please test and signoff.
Signoff x86_64.
[2011-07-11 12:15:59 +0200] Tom Gundersen:
A new udev version is in [testing], please test and signoff.
One thing I noticed: after reboot, the fuse module failed to be autoload when I ran stuff like sshfs; I had to add it to the MODULES array in /etc/rc.conf. That might be something worth mentioning. Apart from that, signoff both. -- Gaetan
On Mon, Jul 11, 2011 at 3:38 PM, Gaetan Bisson <bisson@archlinux.org> wrote:
One thing I noticed: after reboot, the fuse module failed to be autoload when I ran stuff like sshfs; I had to add it to the MODULES array in /etc/rc.conf. That might be something worth mentioning.
Thanks for catching this. It was not intentional. I have not tested with sshfs myself, but this is what I see on my system: % ls /lib/udev/devices loop0 % ls /dev/fuse -lah crw------- 1 root root 10, 229 Jul 11 15:13 /dev/fuse So, the fuse device node seems to be created. Do you see the same? Does installing udev-compat fix it? Cheers, Tom
Am 11.07.2011 15:51, schrieb Tom Gundersen:
% ls /dev/fuse -lah crw------- 1 root root 10, 229 Jul 11 15:13 /dev/fuse
So, the fuse device node seems to be created. Do you see the same? Does installing udev-compat fix it?
Permissions are incorrect here, should be 0666, otherwise a user cannot access it and trigger the module autoloading. I can't see the reason for this, but we do have two udev rules related to fuse: One in 50-udev-default.rules and one in 99-fuse.rules.
[2011-07-11 16:02:15 +0200] Thomas Bächler:
Permissions are incorrect here, should be 0666, otherwise a user cannot access it and trigger the module autoloading.
Sorry I was AFK for some time. You are correct: it was a permission issue on /dev/fuse that I had. -- Gaetan
On Mon, Jul 11, 2011 at 11:38 AM, Gaetan Bisson <bisson@archlinux.org> wrote:
[2011-07-11 16:02:15 +0200] Thomas Bächler:
Permissions are incorrect here, should be 0666, otherwise a user cannot access it and trigger the module autoloading.
Sorry I was AFK for some time.
You are correct: it was a permission issue on /dev/fuse that I had.
This isn't a permission error you had; it is likely a permission error every single person will have, so it needs to get addressed somehow. -Dan
[2011-07-11 11:41:59 -0400] Dan McGee:
On Mon, Jul 11, 2011 at 11:38 AM, Gaetan Bisson <bisson@archlinux.org> wrote:
You are correct: it was a permission issue on /dev/fuse that I had.
This isn't a permission error you had; it is likely a permission error every single person will have, so it needs to get addressed somehow.
Right. (That's what I meant but it came out wrong.) -- Gaetan
On 11 July 2011 18:41, Dan McGee <dpmcgee@gmail.com> wrote:
On Mon, Jul 11, 2011 at 11:38 AM, Gaetan Bisson <bisson@archlinux.org> wrote:
[2011-07-11 16:02:15 +0200] Thomas Bächler:
Permissions are incorrect here, should be 0666, otherwise a user cannot access it and trigger the module autoloading.
Sorry I was AFK for some time.
You are correct: it was a permission issue on /dev/fuse that I had.
This isn't a permission error you had; it is likely a permission error every single person will have, so it needs to get addressed somehow.
The permissions are wrong here as well. Below are the results of using 'git bisect' and installing the resulting packages in a VM, rebooting, and seeing if /dev/fuse has 600 or 666 permissions: (Reverting this commit [1] in the udev 172-1 package fixes the wrong permissions on /dev/fuse. I don't understand the changes in that commit myself, so I'll leave further troubleshooting to Tom and the other experts. :p) c112873b5bc9ebbae39c32f502bc6211f33546cc is the first bad commit commit c112873b5bc9ebbae39c32f502bc6211f33546cc Author: Kay Sievers <kay.sievers@vrfy.org> Date: Mon May 30 02:12:02 2011 +0200 rules: static_node - use 0660 if group is given to get the cigar >> On Tue, May 24, 2011 at 15:33, Tom Gundersen <teg@jklm.no> wrote: > > Close, but no cigar. Looks like the static nodes are not assigned > permissions 0660 even if a gid is set (the nodes have perms 0600). > > Cheers, > > Tom :040000 040000 4bc113a62daff05dadc05d3812d66a702d7e1849 d893668f602bb9079b721a26e880333b7e7932f8 M udev [1] http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=c112873
On Mon, Jul 11, 2011 at 6:56 PM, Evangelos Foutras <foutrelis@gmail.com> wrote:
On 11 July 2011 18:41, Dan McGee <dpmcgee@gmail.com> wrote:
On Mon, Jul 11, 2011 at 11:38 AM, Gaetan Bisson <bisson@archlinux.org> wrote:
[2011-07-11 16:02:15 +0200] Thomas Bächler:
Permissions are incorrect here, should be 0666, otherwise a user cannot access it and trigger the module autoloading.
Sorry I was AFK for some time.
You are correct: it was a permission issue on /dev/fuse that I had.
This isn't a permission error you had; it is likely a permission error every single person will have, so it needs to get addressed somehow.
The permissions are wrong here as well.
Below are the results of using 'git bisect' and installing the resulting packages in a VM, rebooting, and seeing if /dev/fuse has 600 or 666 permissions:
(Reverting this commit [1] in the udev 172-1 package fixes the wrong permissions on /dev/fuse. I don't understand the changes in that commit myself, so I'll leave further troubleshooting to Tom and the other experts. :p)
c112873b5bc9ebbae39c32f502bc6211f33546cc is the first bad commit commit c112873b5bc9ebbae39c32f502bc6211f33546cc Author: Kay Sievers <kay.sievers@vrfy.org> Date: Mon May 30 02:12:02 2011 +0200
rules: static_node - use 0660 if group is given to get the cigar
>> On Tue, May 24, 2011 at 15:33, Tom Gundersen <teg@jklm.no> wrote: > > Close, but no cigar. Looks like the static nodes are not assigned > permissions 0660 even if a gid is set (the nodes have perms 0600). > > Cheers, > > Tom
:040000 040000 4bc113a62daff05dadc05d3812d66a702d7e1849 d893668f602bb9079b721a26e880333b7e7932f8 M udev
[1] http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=c112873
Thanks for debugging (and sorry for being late in replying). This does look like an upstream bug introduced when fixing the other upstream bug we found with the last release :-) I'll look into it in more detail and pass it on. Expect a 172-2 in testing once this has been sorted out. Cheers, Tom
On Mon, Jul 11, 2011 at 8:17 PM, Tom Gundersen <teg@jklm.no> wrote:
I'll look into it in more detail and pass it on. Expect a 172-2 in testing once this has been sorted out.
Fix applied upstream, and backported to 172-2, which is in [testing]. No need to signoff as I will wait for 173 before moving to [core] (Kay told me he would release that in a few days). Do report back about any regressions though, so we can get that sorted out for 173. In particular, look out for ownership and permissions on static nodes (such as /dev/fuse and /dev/snd/timer), as this is what we have been having trouble with. Thanks for testing and reporting, Tom
Am 11.07.2011 15:38, schrieb Gaetan Bisson:
[2011-07-11 12:15:59 +0200] Tom Gundersen:
A new udev version is in [testing], please test and signoff.
One thing I noticed: after reboot, the fuse module failed to be autoload when I ran stuff like sshfs; I had to add it to the MODULES array in /etc/rc.conf. That might be something worth mentioning.
Apart from that, signoff both.
The /dev/fuse device should be present with or without 'fuse' being loaded. Can you verify this? Any access to /dev/fuse will then trigger autoloading the fuse module.
On Mon, Jul 11, 2011 at 12:15:59PM +0200, Tom Gundersen wrote:
Hi guys,
A new udev version is in [testing], please test and signoff.
Signoff x86_64.
In addition two bugs were fixed upstream after being found by Arch user James Morris; and support for referencing disks by PARTUUID were added after a suggestion from Arch user Keshav P. R. (this should be useful for mkinitramfs). Well done guys!
Hurray Arch users! The symlinks aren't immediately useful for mkinitcpio (moreso for your bootloader) -- I'm anxious about the addition of PARTUUID resolution to libblkid, hopefully by the end of this year. dave
participants (7)
-
Dan McGee
-
Dave Reisner
-
Evangelos Foutras
-
Gaetan Bisson
-
Stéphane Gaudreault
-
Thomas Bächler
-
Tom Gundersen