* Re: kernel.org udev tarballs
From: Kay Sievers @ 2011-11-02 14:46 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <7a04ec9f-f4d4-4214-b408-8419ed2125d1@zose-store-12>
2011/11/2 Greg KH <greg@kroah.com>:
> On Wed, Nov 02, 2011 at 03:05:52PM +0100, Benoît THÉBAUDEAU wrote:
>> Does anyone know if the udev tarballs will be put back on
>> http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev/
The current release is just here:
http://people.freedesktop.org/~kay/
>> or should we rely only on git snapshots from now on?
You can always just check out a git tag and do:
./autogen
make
make distcheck
to get any tarball you need.
> They will be put back there, please give us time.
Not sure if all the old release tarballs will ever come back to kernel
org. Git is the better archive for that anyway.
The new releases will be there for sure when the infrastructure is
ready. In the meantime, you can just get old releases from any of the
distros archives who stored them in their build systems with proper
checksums.
Kay
^ permalink raw reply
* Re: kernel.org udev tarballs
From: Michael Olbrich @ 2011-11-03 10:00 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <7a04ec9f-f4d4-4214-b408-8419ed2125d1@zose-store-12>
On Wed, Nov 02, 2011 at 03:46:26PM +0100, Kay Sievers wrote:
> 2011/11/2 Greg KH <greg@kroah.com>:
> > On Wed, Nov 02, 2011 at 03:05:52PM +0100, Benoît THÉBAUDEAU wrote:
> >> Does anyone know if the udev tarballs will be put back on
> >> http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev/
>
> The current release is just here:
> http://people.freedesktop.org/~kay/
>
> >> or should we rely only on git snapshots from now on?
>
> You can always just check out a git tag and do:
> ./autogen
> make
> make distcheck
> to get any tarball you need.
>
> > They will be put back there, please give us time.
>
> Not sure if all the old release tarballs will ever come back to kernel
> org. Git is the better archive for that anyway.
>
> The new releases will be there for sure when the infrastructure is
> ready. In the meantime, you can just get old releases from any of the
> distros archives who stored them in their build systems with proper
> checksums.
That really depends on the use-case. All embedded Linux distributions that
I know of rely on upstream to provide the tarballs.
And the big distributions only keep the versions they actually use and that
changes all the time.
So please upload the old tarballs again, once the infrastructure is ready.
Regards,
Michael
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: kernel.org udev tarballs
From: Greg KH @ 2011-11-03 12:09 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <7a04ec9f-f4d4-4214-b408-8419ed2125d1@zose-store-12>
On Thu, Nov 03, 2011 at 11:00:40AM +0100, Michael Olbrich wrote:
> On Wed, Nov 02, 2011 at 03:46:26PM +0100, Kay Sievers wrote:
> > 2011/11/2 Greg KH <greg@kroah.com>:
> > > On Wed, Nov 02, 2011 at 03:05:52PM +0100, Benoît THÉBAUDEAU wrote:
> > >> Does anyone know if the udev tarballs will be put back on
> > >> http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev/
> >
> > The current release is just here:
> > http://people.freedesktop.org/~kay/
> >
> > >> or should we rely only on git snapshots from now on?
> >
> > You can always just check out a git tag and do:
> > ./autogen
> > make
> > make distcheck
> > to get any tarball you need.
> >
> > > They will be put back there, please give us time.
> >
> > Not sure if all the old release tarballs will ever come back to kernel
> > org. Git is the better archive for that anyway.
> >
> > The new releases will be there for sure when the infrastructure is
> > ready. In the meantime, you can just get old releases from any of the
> > distros archives who stored them in their build systems with proper
> > checksums.
>
> That really depends on the use-case. All embedded Linux distributions that
> I know of rely on upstream to provide the tarballs.
Why do they do this? If they are expecting that upstream's tarballs
will always be there to abide by the GPL, then they might wish to
reconsider that :)
> And the big distributions only keep the versions they actually use and that
> changes all the time.
> So please upload the old tarballs again, once the infrastructure is ready.
You can always create the old tarball yourself automatically from git if
needed.
Anyway, it's being worked on, there's lots of other things to address
with kernel.org first, please be patient.
greg k-h
^ permalink raw reply
* Re: kernel.org udev tarballs
From: Kay Sievers @ 2011-11-03 13:08 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <7a04ec9f-f4d4-4214-b408-8419ed2125d1@zose-store-12>
On Thu, Nov 3, 2011 at 13:09, Greg KH <greg@kroah.com> wrote:
> On Thu, Nov 03, 2011 at 11:00:40AM +0100, Michael Olbrich wrote:
>> On Wed, Nov 02, 2011 at 03:46:26PM +0100, Kay Sievers wrote:
>> > 2011/11/2 Greg KH <greg@kroah.com>:
>> > > On Wed, Nov 02, 2011 at 03:05:52PM +0100, Benoît THÉBAUDEAU wrote:
>> > >> Does anyone know if the udev tarballs will be put back on
>> > >> http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev/
>> >
>> > The current release is just here:
>> > http://people.freedesktop.org/~kay/
>> >
>> > >> or should we rely only on git snapshots from now on?
>> >
>> > You can always just check out a git tag and do:
>> > ./autogen
>> > make
>> > make distcheck
>> > to get any tarball you need.
>> >
>> > > They will be put back there, please give us time.
>> >
>> > Not sure if all the old release tarballs will ever come back to kernel
>> > org. Git is the better archive for that anyway.
>> >
>> > The new releases will be there for sure when the infrastructure is
>> > ready. In the meantime, you can just get old releases from any of the
>> > distros archives who stored them in their build systems with proper
>> > checksums.
>>
>> That really depends on the use-case. All embedded Linux distributions that
>> I know of rely on upstream to provide the tarballs.
They should probably switch to build-from-git, if they rely on
anything like that.
> Why do they do this? If they are expecting that upstream's tarballs
> will always be there to abide by the GPL, then they might wish to
> reconsider that :)
>
>> And the big distributions only keep the versions they actually use and that
>> changes all the time.
>> So please upload the old tarballs again, once the infrastructure is ready.
>
> You can always create the old tarball yourself automatically from git if
> needed.
>
> Anyway, it's being worked on, there's lots of other things to address
> with kernel.org first, please be patient.
Michael, honestly, I don't expect all the old 173 tarballs to come
back anytime soon. I don't even know if the recent autotools do the
right thing with the very old sources. It's more complicated with
pre-built stuff in tarballs than it is with the simple git-tar export
the kernel uses. Earlier versions we even build the tar by hand and
not with 'make dist', I doubt that someone wants to go through
rebuilding all that by hand.
I don't have a trusted copy of any of the old tarballs, only git. We
require PGP signing for all new tarballs on kernel.org and can
probably not just restore the old ones, I can definitely not sign them
for uploading unless there is something that makes absolutely sure
they are not manipulated.
Kay
^ permalink raw reply
* Re: kernel.org udev tarballs
From: Michael Olbrich @ 2011-11-04 10:01 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <7a04ec9f-f4d4-4214-b408-8419ed2125d1@zose-store-12>
On Thu, Nov 03, 2011 at 05:09:32AM -0700, Greg KH wrote:
> On Thu, Nov 03, 2011 at 11:00:40AM +0100, Michael Olbrich wrote:
> > On Wed, Nov 02, 2011 at 03:46:26PM +0100, Kay Sievers wrote:
> > > 2011/11/2 Greg KH <greg@kroah.com>:
> > > > On Wed, Nov 02, 2011 at 03:05:52PM +0100, Benoît THÉBAUDEAU wrote:
> > > >> Does anyone know if the udev tarballs will be put back on
> > > >> http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev/
> > >
> > > The current release is just here:
> > > http://people.freedesktop.org/~kay/
> > >
> > > >> or should we rely only on git snapshots from now on?
> > >
> > > You can always just check out a git tag and do:
> > > ./autogen
> > > make
> > > make distcheck
> > > to get any tarball you need.
> > >
> > > > They will be put back there, please give us time.
> > >
> > > Not sure if all the old release tarballs will ever come back to kernel
> > > org. Git is the better archive for that anyway.
> > >
> > > The new releases will be there for sure when the infrastructure is
> > > ready. In the meantime, you can just get old releases from any of the
> > > distros archives who stored them in their build systems with proper
> > > checksums.
> >
> > That really depends on the use-case. All embedded Linux distributions that
> > I know of rely on upstream to provide the tarballs.
>
> Why do they do this? If they are expecting that upstream's tarballs
> will always be there to abide by the GPL, then they might wish to
> reconsider that :)
There are no binaries here. It's just rules how to build things. With
downloading the tarball as a first step.
> > And the big distributions only keep the versions they actually use and that
> > changes all the time.
> > So please upload the old tarballs again, once the infrastructure is ready.
>
> You can always create the old tarball yourself automatically from git if
> needed.
Really? Different versions for autoconf/automake/libtool etc. introduce an
amount of uncertainty I'm not really comfortable with.
Michael
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* optical devices now in disk group instead of cdrom
From: William Hubbs @ 2011-11-06 20:45 UTC (permalink / raw)
To: linux-hotplug
[-- Attachment #1: Type: text/plain, Size: 367 bytes --]
All,
someone on gentoo just reported to me that the following rule has been
deleted from udev-174, which is leaving his optical devices in the
standard "disk" group. He does not want to add his users to this group.
SUBSYSTEM=="block", KERNEL=="sr[0-9]*", SYMLINK+="scd%n", GROUP="cdrom"
Did you intend to move optical devices to the disk group?
Thanks,
William
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: optical devices now in disk group instead of cdrom
From: Tom Gundersen @ 2011-11-06 22:25 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20111106204550.GA31921@linux1>
On Mon, Nov 7, 2011 at 7:45 AM, William Hubbs <w.d.hubbs@gmail.com> wrote:
> someone on gentoo just reported to me that the following rule has been
> deleted from udev-174, which is leaving his optical devices in the
> standard "disk" group. He does not want to add his users to this group.
>
> SUBSYSTEM="block", KERNEL="sr[0-9]*", SYMLINK+="scd%n", GROUP="cdrom"
>
> Did you intend to move optical devices to the disk group?
I'm having similar questions from Arch users, so would also be
interested in an explanation. Especially, why /dev/srX is not assigned
the same group as the corresponding /dev/sgX.
On a (possibly) related note: The 'sg' module is no longer loaded
explicitly (as of 'rules: do not load sg module'). Why is this no
longer needed, and how is it supposed to work? I have heard of
problems with missing /dev/sgX devices, but have not yet figured out
exactly what the problem was (too many weird things going on).
Cheers,
Tom
^ permalink raw reply
* Re: optical devices now in disk group instead of cdrom
From: Kay Sievers @ 2011-11-06 22:33 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20111106204550.GA31921@linux1>
On Sun, Nov 6, 2011 at 21:45, William Hubbs <w.d.hubbs@gmail.com> wrote:
> someone on gentoo just reported to me that the following rule has been
> deleted from udev-174, which is leaving his optical devices in the
> standard "disk" group. He does not want to add his users to this group.
>
> SUBSYSTEM="block", KERNEL="sr[0-9]*", SYMLINK+="scd%n", GROUP="cdrom"
>
> Did you intend to move optical devices to the disk group?
No, that wasn't intentional, only the symlinks were meant to be
removed. Added the permissions setting back now.
Thanks,
Kay
^ permalink raw reply
* Re: optical devices now in disk group instead of cdrom
From: Kay Sievers @ 2011-11-06 22:37 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20111106204550.GA31921@linux1>
On Sun, Nov 6, 2011 at 23:25, Tom Gundersen <teg@jklm.no> wrote:
> On a (possibly) related note: The 'sg' module is no longer loaded
> explicitly (as of 'rules: do not load sg module'). Why is this no
> longer needed, and how is it supposed to work? I have heard of
> problems with missing /dev/sgX devices, but have not yet figured out
> exactly what the problem was (too many weird things going on).
The sg devices are replaced by the bsg devices or by the SG_IO
commands on the block device. The few people who rely on the legacy
ones should just force-load the module, udev does no longer
unconditionally load it.
Kay
^ permalink raw reply
* [PATCH] extras/keymap/findkeyboards: beautify shell code and get rid of grep
From: harald @ 2011-11-07 10:44 UTC (permalink / raw)
To: linux-hotplug
From: Harald Hoyer <harald@redhat.com>
---
| 37 ++++++++++++++++++++++++++-----------
1 files changed, 26 insertions(+), 11 deletions(-)
--git a/extras/keymap/findkeyboards b/extras/keymap/findkeyboards
index 5d636de..537d163 100755
--- a/extras/keymap/findkeyboards
+++ b/extras/keymap/findkeyboards
@@ -14,6 +14,20 @@
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
+# returns OK if $1 contains $2
+strstr() {
+ [ "${1#*$2*}" != "$1" ]
+}
+
+# returns OK if $1 contains $2 at the beginning
+str_starts() {
+ [ "${1#$2*}" != "$1" ]
+}
+
+str_line_starts() {
+ while read a; do str_starts "$a" "$1" && return 0;done
+ return 1;
+}
# print a list of input devices which are keyboard-like
keyboard_devices() {
@@ -23,12 +37,12 @@ keyboard_devices() {
env=`udevadm info --query=env --path=$dev`
# filter out non-event devices, such as the parent input devices which
# have no devnode
- if ! echo "$env" | grep -q '^DEVNAME='; then
+ if ! echo "$env" | str_line_starts 'DEVNAME='; then
continue
fi
- if echo "$walk" | grep -q 'DRIVERS="atkbd"'; then
+ if strstr "$walk" 'DRIVERS="atkbd"'; then
echo -n 'AT keyboard: '
- elif echo "$env" | grep -q '^ID_USB_DRIVER=usbhid'; then
+ elif echo "$env" | str_line_starts 'ID_USB_DRIVER=usbhid'; then
echo -n 'USB keyboard: '
else
echo -n 'Unknown type: '
@@ -37,17 +51,18 @@ keyboard_devices() {
done
# modules
- module=`udevadm trigger --verbose --dry-run --subsystem-match=input --attr-match=name='*Extra Buttons'`
+ module=$(udevadm trigger --verbose --dry-run --subsystem-match=input --attr-match=name='*Extra Buttons')
module="$module
-`udevadm trigger --verbose --dry-run --subsystem-match=input --attr-match=name='*extra buttons'`"
+$(udevadm trigger --verbose --dry-run --subsystem-match=input --attr-match=name='*extra buttons')"
module="$module
-`udevadm trigger --verbose --dry-run --subsystem-match=input --attr-match=name='Sony Vaio Keys'`"
+$(udevadm trigger --verbose --dry-run --subsystem-match=input --attr-match=name='Sony Vaio Keys')"
for m in $module; do
- evdev=`ls -d $m/event* 2>/dev/null`
- if [ -e "$evdev/dev" ]; then
- echo -n 'module: '
- udevadm info --query=name --path=$evdev
- fi
+ for evdev in $m/event*/dev; do
+ if [ -e "$evdev" ]; then
+ echo -n 'module: '
+ udevadm info --query=name --path=${evdev%%/dev}
+ fi
+ done
done
}
--
1.7.6.4
^ permalink raw reply related
* [PATCH] extras/keymap/findkeyboards: beautify shell code and get rid of grep
From: harald @ 2011-11-07 13:54 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1320662666-27558-1-git-send-email-harald@redhat.com>
From: Harald Hoyer <harald@redhat.com>
- save some extra forks and grep with shell code instead of calling
grep
- use $() instead of backticks (improves readability and addes
nesting capabilities)
Signed-off-by: Harald Hoyer <harald@redhat.com>
---
| 37 ++++++++++++++++++++++++++-----------
1 files changed, 26 insertions(+), 11 deletions(-)
--git a/extras/keymap/findkeyboards b/extras/keymap/findkeyboards
index 5d636de..537d163 100755
--- a/extras/keymap/findkeyboards
+++ b/extras/keymap/findkeyboards
@@ -14,6 +14,20 @@
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
+# returns OK if $1 contains $2
+strstr() {
+ [ "${1#*$2*}" != "$1" ]
+}
+
+# returns OK if $1 contains $2 at the beginning
+str_starts() {
+ [ "${1#$2*}" != "$1" ]
+}
+
+str_line_starts() {
+ while read a; do str_starts "$a" "$1" && return 0;done
+ return 1;
+}
# print a list of input devices which are keyboard-like
keyboard_devices() {
@@ -23,12 +37,12 @@ keyboard_devices() {
env=`udevadm info --query=env --path=$dev`
# filter out non-event devices, such as the parent input devices which
# have no devnode
- if ! echo "$env" | grep -q '^DEVNAME='; then
+ if ! echo "$env" | str_line_starts 'DEVNAME='; then
continue
fi
- if echo "$walk" | grep -q 'DRIVERS="atkbd"'; then
+ if strstr "$walk" 'DRIVERS="atkbd"'; then
echo -n 'AT keyboard: '
- elif echo "$env" | grep -q '^ID_USB_DRIVER=usbhid'; then
+ elif echo "$env" | str_line_starts 'ID_USB_DRIVER=usbhid'; then
echo -n 'USB keyboard: '
else
echo -n 'Unknown type: '
@@ -37,17 +51,18 @@ keyboard_devices() {
done
# modules
- module=`udevadm trigger --verbose --dry-run --subsystem-match=input --attr-match=name='*Extra Buttons'`
+ module=$(udevadm trigger --verbose --dry-run --subsystem-match=input --attr-match=name='*Extra Buttons')
module="$module
-`udevadm trigger --verbose --dry-run --subsystem-match=input --attr-match=name='*extra buttons'`"
+$(udevadm trigger --verbose --dry-run --subsystem-match=input --attr-match=name='*extra buttons')"
module="$module
-`udevadm trigger --verbose --dry-run --subsystem-match=input --attr-match=name='Sony Vaio Keys'`"
+$(udevadm trigger --verbose --dry-run --subsystem-match=input --attr-match=name='Sony Vaio Keys')"
for m in $module; do
- evdev=`ls -d $m/event* 2>/dev/null`
- if [ -e "$evdev/dev" ]; then
- echo -n 'module: '
- udevadm info --query=name --path=$evdev
- fi
+ for evdev in $m/event*/dev; do
+ if [ -e "$evdev" ]; then
+ echo -n 'module: '
+ udevadm info --query=name --path=${evdev%%/dev}
+ fi
+ done
done
}
--
1.7.6.4
^ permalink raw reply related
* Re: [PATCH] extras/keymap/findkeyboards: beautify shell code and
From: Harald Hoyer @ 2011-11-07 13:56 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1320662666-27558-1-git-send-email-harald@redhat.com>
On 07.11.2011 14:54, harald@redhat.com wrote:
> From: Harald Hoyer <harald@redhat.com>
>
> - save some extra forks and grep with shell code instead of calling
> grep
> - use $() instead of backticks (improves readability and addes
> nesting capabilities)
>
> Signed-off-by: Harald Hoyer <harald@redhat.com>
resent with more commit info
^ permalink raw reply
* Re: [PATCH] extras/keymap/findkeyboards: beautify shell code and get
From: Martin Pitt @ 2011-11-07 16:54 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1320662666-27558-1-git-send-email-harald@redhat.com>
Hello Harald,
harald@redhat.com [2011-11-07 14:54 +0100]:
> - save some extra forks and grep with shell code instead of calling
> grep
> - use $() instead of backticks (improves readability and addes
> nesting capabilities)
Thanks! Applied.
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
^ permalink raw reply
* [ANNOUNCE] udev 175
From: Kay Sievers @ 2011-11-08 2:04 UTC (permalink / raw)
To: linux-hotplug
Here comes a new udev version. Thanks to all who have contributed to
this release.
Until ftp.kernel.org comes back, the signed tarball is here:
http://people.freedesktop.org/~kay/udev/
(This is just a temporary location and the files will be deleted at the moment
ftp.kernel.org server is back online)
The tarball can be found here:
ftp://ftp.kernel.org/pub/linux/utils/kernel/hotplug/
The development repository can be found here:
http://www.kernel.org/git/?p=linux/hotplug/udev.git;a=summary
The ChangeLog can be found here:
http://www.kernel.org/git/?p=linux/hotplug/udev.git;a=blob;hb=HEAD;f=ChangeLog
udev 175
====
Bugfixes.
udev 174
====
Bugfixes.
The udev daemon moved to /lib/udev/udevd. Non-systemd init systems
and non-dracut initramfs image generators need to change the init
scripts. Alternatively the udev build needs to move udevd back to
/sbin or create a symlink in /sbin, which is not done by default.
The path_id, usb_id, input_id tools are built-in commands now and
the stand-alone tools do not exist anymore. Static lists of file in
initramfs generators need to be updated. For testing, the commands
can still be executed standalone with 'udevadm test-builtin <cmd>'.
The fusectl filesystem is no longer mounted directly from udev.
Systemd systems will take care of mounting fusectl and configfs
now. Non-systemd systems need to ship their own rule if they
need these filesystems auto-mounted.
The long deprecated keys: SYSFS=, ID=, BUS= have been removed.
The support for 'udevadm trigger --typeúiled, and the
RUN{fail_event_on_error} attribute was removed.
The udev control socket is now created in /run/udev/control
and no longer as an abstract namespace one.
The rules to create persistent network interface and cdrom link
rules automatically in /etc/udev/rules.d/ have been disabled by
default. Explicit configuration will be required for these use
cases, udev will no longer try to write any persistent system
configuration from a device hotplug path.
^ permalink raw reply
* /var on a separate partition
From: William Hubbs @ 2011-11-08 18:38 UTC (permalink / raw)
To: linux-hotplug
[-- Attachment #1: Type: text/plain, Size: 349 bytes --]
All,
I know that having /usr on a separate file system with the latest udev
doesn't work without using an initramfs.
Are there any other file systems that should be pre-mounted by the
initramfs, such as /var? It looks like /var has to be pre-mounted if you
have alsa installed, but I want to confirm whether folkson this list
know this.
William
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: /var on a separate partition
From: Kay Sievers @ 2011-11-08 19:35 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20111108183853.GA18064@linux1>
On Tue, Nov 8, 2011 at 19:38, William Hubbs <w.d.hubbs@gmail.com> wrote:
> I know that having /usr on a separate file system with the latest udev
> doesn't work without using an initramfs.
>
> Are there any other file systems that should be pre-mounted by the
> initramfs, such as /var? It looks like /var has to be pre-mounted if you
> have alsa installed, but I want to confirm whether folkson this list
> know this.
There is no need for that. Systemd can bring up the box without /var,
and sort the services which need that after /var is mounted.
Alsa has its own systemd service which initializes hardware at that
point, in case the coldplug run did not do it already from udev.
Kay
^ permalink raw reply
* Re: /var on a separate partition
From: William Hubbs @ 2011-11-08 22:39 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20111108183853.GA18064@linux1>
[-- Attachment #1: Type: text/plain, Size: 922 bytes --]
On Tue, Nov 08, 2011 at 08:35:53PM +0100, Kay Sievers wrote:
> On Tue, Nov 8, 2011 at 19:38, William Hubbs <w.d.hubbs@gmail.com> wrote:
> > I know that having /usr on a separate file system with the latest udev
> > doesn't work without using an initramfs.
> >
> > Are there any other file systems that should be pre-mounted by the
> > initramfs, such as /var? It looks like /var has to be pre-mounted if you
> > have alsa installed, but I want to confirm whether folkson this list
> > know this.
>
> There is no need for that. Systemd can bring up the box without /var,
> and sort the services which need that after /var is mounted.
>
> Alsa has its own systemd service which initializes hardware at that
> point, in case the coldplug run did not do it already from udev.
In that case, shouldn't we have the alsa-utils folks drop
/lib/udev/rules.d/90-alsa-restore.rules from their package?
William
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: /var on a separate partition
From: Kay Sievers @ 2011-11-08 22:46 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20111108183853.GA18064@linux1>
On Tue, Nov 8, 2011 at 23:39, William Hubbs <w.d.hubbs@gmail.com> wrote:
> On Tue, Nov 08, 2011 at 08:35:53PM +0100, Kay Sievers wrote:
>> On Tue, Nov 8, 2011 at 19:38, William Hubbs <w.d.hubbs@gmail.com> wrote:
>> > I know that having /usr on a separate file system with the latest udev
>> > doesn't work without using an initramfs.
>> >
>> > Are there any other file systems that should be pre-mounted by the
>> > initramfs, such as /var? It looks like /var has to be pre-mounted if you
>> > have alsa installed, but I want to confirm whether folkson this list
>> > know this.
>>
>> There is no need for that. Systemd can bring up the box without /var,
>> and sort the services which need that after /var is mounted.
>>
>> Alsa has its own systemd service which initializes hardware at that
>> point, in case the coldplug run did not do it already from udev.
>
> In that case, shouldn't we have the alsa-utils folks drop
> /lib/udev/rules.d/90-alsa-restore.rules from their package?
Udev still takes care for hardware you connect later. Udev does the
hotplug path, the systemd service does the initial init during bootup.
Both are needed.
But the ACTION="remove" rule in that file can surely be killed, not
sure who expected saving the state of a device that is already removed
to work. :)
Kay
^ permalink raw reply
* Re: /var on a separate partition
From: William Hubbs @ 2011-11-08 23:37 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20111108183853.GA18064@linux1>
[-- Attachment #1: Type: text/plain, Size: 1879 bytes --]
On Tue, Nov 08, 2011 at 11:46:10PM +0100, Kay Sievers wrote:
> On Tue, Nov 8, 2011 at 23:39, William Hubbs <w.d.hubbs@gmail.com> wrote:
> > On Tue, Nov 08, 2011 at 08:35:53PM +0100, Kay Sievers wrote:
> >> On Tue, Nov 8, 2011 at 19:38, William Hubbs <w.d.hubbs@gmail.com> wrote:
> >> > I know that having /usr on a separate file system with the latest udev
> >> > doesn't work without using an initramfs.
> >> >
> >> > Are there any other file systems that should be pre-mounted by the
> >> > initramfs, such as /var? It looks like /var has to be pre-mounted if you
> >> > have alsa installed, but I want to confirm whether folkson this list
> >> > know this.
> >>
> >> There is no need for that. Systemd can bring up the box without /var,
> >> and sort the services which need that after /var is mounted.
> >>
> >> Alsa has its own systemd service which initializes hardware at that
> >> point, in case the coldplug run did not do it already from udev.
> >
> > In that case, shouldn't we have the alsa-utils folks drop
> > /lib/udev/rules.d/90-alsa-restore.rules from their package?
>
> Udev still takes care for hardware you connect later. Udev does the
> hotplug path, the systemd service does the initial init during bootup.
> Both are needed.
>
> But the ACTION=="remove" rule in that file can surely be killed, not
> sure who expected saving the state of a device that is already removed
> to work. :)
I'm not sure we are talking about the same file, so I will include the
one I have for reference, this is from alsa-utils-1.0.24.2.
ACTION=="add", SUBSYSTEM=="sound", KERNEL=="controlC*", KERNELS=="card*", \
RUN+="/usr/sbin/alsactl restore $attr{number}"
The problem is the run+= portion. "alsactl restore" reads state
information from /var/lib/alsa by default, so it will fail if
/var is not mounted.
William
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: /var on a separate partition
From: Kay Sievers @ 2011-11-08 23:45 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20111108183853.GA18064@linux1>
On Wed, Nov 9, 2011 at 00:37, William Hubbs <w.d.hubbs@gmail.com> wrote:
> On Tue, Nov 08, 2011 at 11:46:10PM +0100, Kay Sievers wrote:
>> On Tue, Nov 8, 2011 at 23:39, William Hubbs <w.d.hubbs@gmail.com> wrote:
>> > On Tue, Nov 08, 2011 at 08:35:53PM +0100, Kay Sievers wrote:
>> >> On Tue, Nov 8, 2011 at 19:38, William Hubbs <w.d.hubbs@gmail.com> wrote:
>> >> > I know that having /usr on a separate file system with the latest udev
>> >> > doesn't work without using an initramfs.
>> >> >
>> >> > Are there any other file systems that should be pre-mounted by the
>> >> > initramfs, such as /var? It looks like /var has to be pre-mounted if you
>> >> > have alsa installed, but I want to confirm whether folkson this list
>> >> > know this.
>> >>
>> >> There is no need for that. Systemd can bring up the box without /var,
>> >> and sort the services which need that after /var is mounted.
>> >>
>> >> Alsa has its own systemd service which initializes hardware at that
>> >> point, in case the coldplug run did not do it already from udev.
>> >
>> > In that case, shouldn't we have the alsa-utils folks drop
>> > /lib/udev/rules.d/90-alsa-restore.rules from their package?
>>
>> Udev still takes care for hardware you connect later. Udev does the
>> hotplug path, the systemd service does the initial init during bootup.
>> Both are needed.
>>
>> But the ACTION="remove" rule in that file can surely be killed, not
>> sure who expected saving the state of a device that is already removed
>> to work. :)
>
> I'm not sure we are talking about the same file, so I will include the
> one I have for reference, this is from alsa-utils-1.0.24.2.
We do. The ACTION="remove" in there makes no sense.
> ACTION="add", SUBSYSTEM="sound", KERNEL="controlC*", KERNELS="card*", \
> RUN+="/usr/sbin/alsactl restore $attr{number}"
>
> The problem is the run+= portion. "alsactl restore" reads state
> information from /var/lib/alsa by default, so it will fail if
> /var is not mounted.
That does not matter. The rule is meant to run and will work fine in
hotplug cases. During bootup it can gracefully fail without causing
any problems, the systemd service, started later, will take care that
/var is there, when the formerly failed device inits, are applied.
Kay
^ permalink raw reply
* udev to obtain hard drive serial number
From: Brad Tilley @ 2011-11-10 15:06 UTC (permalink / raw)
To: linux-hotplug
What's the most stable way in which to obtain a hard drive serial number
using recent Linux kernels and udev. Normal users may call udevadm like
this to get the serial number:
/sbin/udevadm info --query=property --name /dev/sda | grep ID_SERIAL_SHORT
| tr = " " | awk '{print $2}'
output looks like this:
E3834563JPSNTN
How stable/reliable is this approach compared to other tools such as
hdparm, etc. Is there a better way to do this with udev?
Thanks for any advice,
Brad
^ permalink raw reply
* udisks --eject problem
From: Allin Cottrell @ 2011-11-15 20:01 UTC (permalink / raw)
To: linux-hotplug
I recently updated from sysvinit to systemd, and in the
process updated various components to latest stable:
dbus-1.4.16, polkit-0.102, udev-175, udisks-1.0.4, systemd-37.
Before the updates "udisks --eject /dev/sr0" was working but
now it's not. The log looks like this
dbus-daemon[265]: helper(pid 6166): launched job eject on
/dev/sr0
dbus-daemon[265]: helper(pid 6166): launched job eject on
/dev/sr0
dbus-daemon[265]: ** (polkitd:477): DEBUG:
system-bus-name::1.4 is inquiring whether
system-bus-name::1.16 is authorized for
org.freedesktop.udisks.drive-eject
dbus-daemon[265]: ** (polkitd:477): DEBUG:
system-bus-name::1.4 is inquiring whether
system-bus-name::1.16 is authorized for
org.freedesktop.udisks.drive-eject
dbus-daemon[265]: ** (polkitd:477): DEBUG: user of caller is
unix-user:root
dbus-daemon[265]: ** (polkitd:477): DEBUG: user of caller is
unix-user:root
dbus-daemon[265]: ** (polkitd:477): DEBUG: user of subject is
unix-user:root
dbus-daemon[265]: ** (polkitd:477): DEBUG: user of subject is
unix-user:root
dbus-daemon[265]: ** (polkitd:477): DEBUG: checking whether
system-bus-name::1.16 is authorized for
org.freedesktop.udisks.drive-eject
dbus-daemon[265]: ** (polkitd:477): DEBUG: checking whether
system-bus-name::1.16 is authorized for
org.freedesktop.udisks.drive-eject
dbus-daemon[265]: ** (polkitd:477): DEBUG:
dbus-daemon[265]: ** (polkitd:477): DEBUG:
dbus-daemon[265]: helper(pid 6166): completed with exit code
0
dbus-daemon[265]: helper(pid 6166): completed with exit code
0
"exit code 0", but the CD tray is not budging. Manually
pressing the latch opens it OK. Any thoughts on what's wrong
here? Thanks.
--
Allin Cottrell
Department of Economics
Wake Forest University, NC
^ permalink raw reply
* [PATCH] keymap: Add Lenovo Thinkpad X220 Tablet
From: Sjoerd Simons @ 2011-11-18 21:37 UTC (permalink / raw)
To: linux-hotplug
The Lenovo Thinkpad X220 Tablet has similar buttons as the previous
generations (circular arrow and rotate screen)
Signed-off-by: Sjoerd Simons <sjoerd@luon.net>
---
| 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
--git a/extras/keymap/95-keymap.rules b/extras/keymap/95-keymap.rules
index 7c2f88c..248c58f 100644
--- a/extras/keymap/95-keymap.rules
+++ b/extras/keymap/95-keymap.rules
@@ -79,7 +79,7 @@ ENV{DMI_VENDOR}="Compaq*", ATTR{[dmi/id]product_name}="*E500*|*Evo N*", RUN+="
ENV{DMI_VENDOR}="LENOVO*", ATTR{[dmi/id]product_version}="*3000*", RUN+="keymap $name lenovo-3000"
ENV{DMI_VENDOR}="LENOVO*", ATTR{[dmi/id]product_version}="ThinkPad X6*", ATTR{[dmi/id]product_version}="* Tablet", RUN+="keymap $name lenovo-thinkpad_x6_tablet"
-ENV{DMI_VENDOR}="LENOVO*", ATTR{[dmi/id]product_version}="ThinkPad X20* Tablet*", ATTR{[dmi/id]product_version}="* Tablet", RUN+="keymap $name lenovo-thinkpad_x200_tablet"
+ENV{DMI_VENDOR}="LENOVO*", ATTR{[dmi/id]product_version}="ThinkPad X2[02]* Tablet*", ATTR{[dmi/id]product_version}="* Tablet", RUN+="keymap $name lenovo-thinkpad_x200_tablet"
ENV{DMI_VENDOR}="LENOVO*", ATTR{[dmi/id]product_version}="*IdeaPad*", RUN+="keymap $name lenovo-ideapad"
ENV{DMI_VENDOR}="LENOVO*", ATTR{[dmi/id]product_name}="S10-*", RUN+="keymap $name lenovo-ideapad"
ENV{DMI_VENDOR}="LENOVO", ATTR{[dmi/id]product_version}="*IdeaPad Y550*", RUN+="keymap $name 0x95 media 0xA3 play"
--
1.7.7.3
^ permalink raw reply related
* Powerfile C200 and udev
From: Jonathan Isom @ 2011-11-19 2:03 UTC (permalink / raw)
To: linux-hotplug
Hi.
I have a Powerfile c200(200 disk firewire dvd changer). When I turn
it on or at boot I get the below dmesg
logs & the device is unusable. If I boot into single user mode
,before udev touches it, I can use it. I don't have
the slightest idea when the problem was introduced however it did work
with udev at one point. Tested with
kernel 2.6.38 2.6.39, and most recently 3.2.0-rc2. Any ideas to get
this working with udev, either correctly
or by some form of blacklist? Using udev 175 currently
Thanks
Jonathan
[ 5790.865607] firewire_core: phy config: card 0, new rootÿc1, gap_count=5
[ 5791.464849] scsi10 : SBP-2 IEEE-1394
[ 5791.464967] firewire_core: created device fw1: GUID 003060f200002759, S400
[ 5791.665892] firewire_sbp2: fw1.0: logged in to LUN 0000 (0 retries)
[ 5791.668838] scsi 10:0:0:0: CD-ROM TOSHIBA DVD-ROM
SD-M1212 1032 PQ: 0 ANSI: 0 CCS
[ 5791.670458] firewire_sbp2: fw1.0: logged in to LUN 0002 (0 retries)
[ 5806.664071] firewire_sbp2: fw1.0: orb reply timed out, rcode=0x11
[ 5806.865691] firewire_sbp2: fw1.0: logged in to LUN 0001 (1 retries)
[ 5821.728060] firewire_sbp2: fw1.0: sbp2_scsi_abort
[ 5831.728095] firewire_sbp2: fw1.0: sbp2_scsi_abort
[ 5831.728290] sr 10:0:0:0: Device offlined - not ready after error recovery
[ 5831.728338] sr 10:0:0:0: rejecting I/O to offline device
[ 5831.728350] sr1: scsi3-mmc drive: 0x/0x caddy
[ 5831.728600] sr 10:0:0:0: Attached scsi CD-ROM sr1
[ 5831.728701] sr 10:0:0:0: Attached scsi generic sg9 type 5
[ 5831.728897] sr 10:0:0:0: rejecting I/O to offline device
[ 5831.731877] sr 10:0:0:0: rejecting I/O to offline device
[ 5831.731900] sr 10:0:0:0: rejecting I/O to offline device
[ 5831.731920] sr 10:0:0:0: rejecting I/O to offline device
[ 5831.734999] sr 10:0:0:0: rejecting I/O to offline device
[ 5831.735047] sr 10:0:0:0: rejecting I/O to offline device
[ 5831.735108] sr 10:0:0:0: rejecting I/O to offline device
[ 5831.735118] sr 10:0:0:0: rejecting I/O to offline device
[ 5831.744801] sr 10:0:0:0: rejecting I/O to offline device
[ 5831.744823] sr 10:0:0:0: rejecting I/O to offline device
[ 5831.748970] sr 10:0:0:0: rejecting I/O to offline device
[ 5831.748993] sr 10:0:0:0: rejecting I/O to offline device
[ 5831.749093] sr 10:0:0:0: rejecting I/O to offline device
[ 5831.749103] sr 10:0:0:0: rejecting I/O to offline device
[ 5832.055687] scsi 10:0:0:2: Medium Changer Escient Powerfile
C200 073 PQ: 0 ANSI: 3
[ 5832.379658] ch0: type #1 (mt): 0x0+1 [medium transport]
[ 5832.379666] ch0: type #2 (st): 0x4+200 [storage]
[ 5832.379672] ch0: type #3 (ie): 0x1+1 [import/export]
[ 5832.379677] ch0: type #4 (dt): 0x2+2 [data transfer]
[ 5832.721333] ch0: dt 0x2: READ ELEMENT STATUS failed
[ 5833.002180] sr 10:0:0:0: rejecting I/O to offline device
[ 5833.002204] sr 10:0:0:0: rejecting I/O to offline device
[ 5833.055034] ch0: dt 0x3: READ ELEMENT STATUS failed
[ 5833.055042] ch0: INITIALIZE ELEMENT STATUS, may take some time ...
[ 5833.099264] ch0: ... finished
[ 5833.099276] ch 10:0:0:2: Attached scsi changer ch0
[ 5833.099429] ch 10:0:0:2: Attached scsi generic sg10 type 8
[ 5833.102387] scsi 10:0:0:1: CD-ROM TOSHIBA DVD-ROM
SD-M1212 1032 PQ: 0 ANSI: 0 CCS
[ 5835.002208] sr 10:0:0:0: rejecting I/O to offline device
[ 5835.002231] sr 10:0:0:0: rejecting I/O to offline device
[ 5835.539113] sr2: scsi3-mmc drive: 32x/32x cd/rw xa/form2 cdda tray
[ 5835.539387] sr 10:0:0:1: Attached scsi CD-ROM sr2
[ 5835.539507] sr 10:0:0:1: Attached scsi generic sg11 type 5
[ 5837.001143] sr 10:0:0:0: rejecting I/O to offline device
[ 5837.001167] sr 10:0:0:0: rejecting I/O to offline device
[ 5839.002201] sr 10:0:0:0: rejecting I/O to offline device
[ 5839.002224] sr 10:0:0:0: rejecting I/O to offline device
[ 5841.002160] sr 10:0:0:0: rejecting I/O to offline device
[ 5841.002182] sr 10:0:0:0: rejecting I/O to offline device
[ 5843.002215] sr 10:0:0:0: rejecting I/O to offline device
[ 5843.002237] sr 10:0:0:0: rejecting I/O to offline device
[ 5845.002178] sr 10:0:0:0: rejecting I/O to offline device
[ 5845.002201] sr 10:0:0:0: rejecting I/O to offline device
[ 5847.002215] sr 10:0:0:0: rejecting I/O to offline device
[ 5847.002238] sr 10:0:0:0: rejecting I/O to offline device
[ 5849.002201] sr 10:0:0:0: rejecting I/O to offline device
[ 5849.002224] sr 10:0:0:0: rejecting I/O to offline device
[ 5851.002170] sr 10:0:0:0: rejecting I/O to offline device
[ 5851.002192] sr 10:0:0:0: rejecting I/O to offline device
[ 5853.002201] sr 10:0:0:0: rejecting I/O to offline device
[ 5853.002223] sr 10:0:0:0: rejecting I/O to offline device
....
[--------------------------------8<---------------------------------------------------]
^ permalink raw reply
* Re: [PATCH] keymap: Add Lenovo Thinkpad X220 Tablet
From: Martin Pitt @ 2011-11-21 6:56 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1321652273-11144-1-git-send-email-sjoerd@luon.net>
Hey Sjoert,
Sjoerd Simons [2011-11-18 21:37 +0000]:
> The Lenovo Thinkpad X220 Tablet has similar buttons as the previous
> generations (circular arrow and rotate screen)
Thanks! Pushed.
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox