[arch-projects] [INITSCRIPTS][PATCH 1/2] Drop old /proc/sys/kernel/hotplug logic
No trace of uevent_helper in udev code. http://git.kernel.org/?p=linux%2Fhotplug%2Fudev.git&a=search&h=HEAD&st=grep&s=uevent_helper No trace of uevent_helper or hotplug in /lib/udev/rules.d/
From http://lwn.net/Articles/166954/ The hotplug helper /sbin/hotplug is now officially deprecated. The control file /proc/sys/kernel/hotplug has moved to /sys/kernel/uevent_helper, but it is expected to be disabled on most systems in favor of udev and the netlink interface.
So this is an old legagy. We should drop it. Signed-off-by: Sebastien Luttringer <seblu@seblu.net> --- rc.sysinit | 2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/rc.sysinit b/rc.sysinit index 93c66cf..575dfbc 100755 --- a/rc.sysinit +++ b/rc.sysinit @@ -71,8 +71,6 @@ if [[ $HWCLOCK_PARAMS ]]; then fi fi -echo > /proc/sys/kernel/hotplug - stat_busy "Starting UDev Daemon" /sbin/udevd --daemon stat_done -- Sebastien "Seblu" Luttringer
This job is done by recent version of udev in /lib/udev/rules.d/64-md-raid.rules. This will also fix FS#20117. Signed-off-by: Sebastien Luttringer <seblu@seblu.net> --- rc.conf | 3 --- rc.sysinit | 5 ----- 2 files changed, 0 insertions(+), 8 deletions(-) diff --git a/rc.conf b/rc.conf index e4751ca..7d03a30 100644 --- a/rc.conf +++ b/rc.conf @@ -42,9 +42,6 @@ MODULES=() # Udev settle timeout (default to 30) UDEV_TIMEOUT=30 -# Scan for SoftRAID (mdadm) Volumes at startup -USEMDADM="no" - # Scan for FakeRAID (dmraid) Volumes at startup USEDMRAID="no" diff --git a/rc.sysinit b/rc.sysinit index 575dfbc..c79f263 100755 --- a/rc.sysinit +++ b/rc.sysinit @@ -109,11 +109,6 @@ run_hook sysinit_udevsettled [[ -d /sys/class/net/lo ]] && \ status "Bringing up loopback interface" /sbin/ifconfig lo 127.0.0.1 up -# SoftRAID devices detection -if [[ $USEMDADM =~ yes|YES && -x /sbin/mdadm ]]; then - status "Activating SoftRAID arrays" /sbin/mdadm --assemble --scan -fi - # FakeRAID devices detection if [[ $USEDMRAID =~ yes|YES && -x /sbin/dmraid ]]; then status "Activating FakeRAID arrays" /sbin/dmraid -i -ay -- Sebastien "Seblu" Luttringer
On Sun, Apr 03, 2011 at 04:55:14PM +0200, Sebastien Luttringer wrote:
This job is done by recent version of udev in /lib/udev/rules.d/64-md-raid.rules.
this comes from mdadm, not udev. It's also only triggered if the partitions are of type linux_raid_member or isw_raid_member. If this were to go through, we'd have a lot of people banging on our doors, so to speak.. dave
This will also fix FS#20117.
Signed-off-by: Sebastien Luttringer <seblu@seblu.net> --- rc.conf | 3 --- rc.sysinit | 5 ----- 2 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/rc.conf b/rc.conf index e4751ca..7d03a30 100644 --- a/rc.conf +++ b/rc.conf @@ -42,9 +42,6 @@ MODULES=() # Udev settle timeout (default to 30) UDEV_TIMEOUT=30
-# Scan for SoftRAID (mdadm) Volumes at startup -USEMDADM="no" - # Scan for FakeRAID (dmraid) Volumes at startup USEDMRAID="no"
diff --git a/rc.sysinit b/rc.sysinit index 575dfbc..c79f263 100755 --- a/rc.sysinit +++ b/rc.sysinit @@ -109,11 +109,6 @@ run_hook sysinit_udevsettled [[ -d /sys/class/net/lo ]] && \ status "Bringing up loopback interface" /sbin/ifconfig lo 127.0.0.1 up
-# SoftRAID devices detection -if [[ $USEMDADM =~ yes|YES && -x /sbin/mdadm ]]; then - status "Activating SoftRAID arrays" /sbin/mdadm --assemble --scan -fi - # FakeRAID devices detection if [[ $USEDMRAID =~ yes|YES && -x /sbin/dmraid ]]; then status "Activating FakeRAID arrays" /sbin/dmraid -i -ay -- Sebastien "Seblu" Luttringer
On Sun, Apr 3, 2011 at 5:04 PM, Dave Reisner <d@falconindy.com> wrote:
On Sun, Apr 03, 2011 at 04:55:14PM +0200, Sebastien Luttringer wrote:
This job is done by recent version of udev in /lib/udev/rules.d/64-md-raid.rules.
this comes from mdadm, not udev. Yes but upstream rules does not match with my current content. I'm searching why.
It's also only triggered if the partitions are of type linux_raid_member or isw_raid_member. partition not strictly. My raid is directly on disk (so without partition type from mbr) and detection is correct. Even after removing /etc/blkid* udev rules detect by /sbin/blkid -o udev -p $dev. As far i test, blkid is based on metadata.
If this were to go through, we'd have a lot of people banging on our doors, so to speak.. I don't see why. Udev, via blikid will detect and assemble.
About isw_raid, line is not in mdadm package upstream 3.1.2 and 3.1.5. Currently all people should come to us because they have an error when mdadm is automatically started at boot. cf bugreport closed by adding USE_MDADM. it does not seem to be the revolution :) -- Sébastien Luttringer www.seblu.net
On Sun, Apr 03, 2011 at 05:39:57PM +0200, Seblu wrote:
On Sun, Apr 3, 2011 at 5:04 PM, Dave Reisner <d@falconindy.com> wrote:
On Sun, Apr 03, 2011 at 04:55:14PM +0200, Sebastien Luttringer wrote:
This job is done by recent version of udev in /lib/udev/rules.d/64-md-raid.rules.
this comes from mdadm, not udev. Yes but upstream rules does not match with my current content. I'm searching why.
It's also only triggered if the partitions are of type linux_raid_member or isw_raid_member. partition not strictly. My raid is directly on disk (so without partition type from mbr) and detection is correct. Even after removing /etc/blkid* udev rules detect by /sbin/blkid -o udev -p $dev. As far i test, blkid is based on metadata.
blkid reads the same metadata that udev does. I misread the rule -- ID_FS_TYPE is a layer above the partition table itself. Thinking back, I recall hearing about this on systemd-devel...
If this were to go through, we'd have a lot of people banging on our doors, so to speak.. I don't see why. Udev, via blikid will detect and assemble.
About isw_raid, line is not in mdadm package upstream 3.1.2 and 3.1.5.
It's in testing (3.2.1): ENV{ID_FS_TYPE}=="isw_raid_member", ACTION=="remove", RUN+="/sbin/mdadm -If $name --path $env{ID_PATH}" ENV{ID_FS_TYPE}=="isw_raid_member", ACTION=="add", RUN+="/sbin/mdadm --incremental $env{DEVNAME}"
Currently all people should come to us because they have an error when mdadm is automatically started at boot. cf bugreport closed by adding USE_MDADM. it does not seem to be the revolution :)
Indeed, that error's been there as long as I've been using Arch. dave
On Sun, Apr 3, 2011 at 6:05 PM, Dave Reisner <d@falconindy.com> wrote:
On Sun, Apr 03, 2011 at 05:39:57PM +0200, Seblu wrote:
On Sun, Apr 3, 2011 at 5:04 PM, Dave Reisner <d@falconindy.com> wrote:
On Sun, Apr 03, 2011 at 04:55:14PM +0200, Sebastien Luttringer wrote:
This job is done by recent version of udev in /lib/udev/rules.d/64-md-raid.rules.
this comes from mdadm, not udev. Yes but upstream rules does not match with my current content. I'm searching why.
It's also only triggered if the partitions are of type linux_raid_member or isw_raid_member. partition not strictly. My raid is directly on disk (so without partition type from mbr) and detection is correct. Even after removing /etc/blkid* udev rules detect by /sbin/blkid -o udev -p $dev. As far i test, blkid is based on metadata.
blkid reads the same metadata that udev does. I misread the rule -- ID_FS_TYPE is a layer above the partition table itself. Thinking back, I recall hearing about this on systemd-devel...
If this were to go through, we'd have a lot of people banging on our doors, so to speak.. I don't see why. Udev, via blikid will detect and assemble.
About isw_raid, line is not in mdadm package upstream 3.1.2 and 3.1.5.
It's in testing (3.2.1): I'm fucked up alone. I download 3.1.2 manually instead of 3.2.1...
ENV{ID_FS_TYPE}=="isw_raid_member", ACTION=="remove", RUN+="/sbin/mdadm -If $name --path $env{ID_PATH}" ENV{ID_FS_TYPE}=="isw_raid_member", ACTION=="add", RUN+="/sbin/mdadm --incremental $env{DEVNAME}"
This doesnt work on my test machine. probably because mdadm is not dmraid. -- Sébastien Luttringer www.seblu.net
On Mon, Apr 4, 2011 at 12:13 AM, Seblu <seblu@seblu.net> wrote:
On Sun, Apr 3, 2011 at 6:05 PM, Dave Reisner <d@falconindy.com> wrote:
ENV{ID_FS_TYPE}=="isw_raid_member", ACTION=="remove", RUN+="/sbin/mdadm -If $name --path $env{ID_PATH}" ENV{ID_FS_TYPE}=="isw_raid_member", ACTION=="add", RUN+="/sbin/mdadm --incremental $env{DEVNAME}" This doesnt work on my test machine. probably because mdadm is not dmraid.
What's the conclusion here? Did you get it to work, Dave do you agree with the patch in the end? Cheers, Tom
On Sunday 03 April 2011 16:55:13 Sebastien Luttringer wrote:
No trace of uevent_helper in udev code. http://git.kernel.org/?p=linux%2Fhotplug%2Fudev.git&a=search&h=HEAD&st=grep& s=uevent_helper
No trace of uevent_helper or hotplug in /lib/udev/rules.d/
From http://lwn.net/Articles/166954/ The hotplug helper /sbin/hotplug is now officially deprecated. The control file /proc/sys/kernel/hotplug has moved to /sys/kernel/uevent_helper, but it is expected to be disabled on most systems in favor of udev and the netlink interface.
So this is an old legagy. We should drop it.
I agree with both these patches in principle. I'll just wait a bit before pushing them out to let others give their opinion. -t
participants (4)
-
Dave Reisner
-
Sebastien Luttringer
-
Seblu
-
Tom Gundersen