2008/2/21, Roman Kyrylych :

2008/2/21, Roman Kyrylych :

...

2008/2/21, Aaron Griffin :

...

This superseeds Dan's previous signoff for the 118 version bump. Included are the following changes: FS#8702 - Fix persistant input devices FS#8878 - Attempted speed up of load-modules.sh FS#8591 - Fix loading of RTC devices

Additionally, this package is required for the new initscripts which are required for the new ISOs. Please sign off

Sorry, won't signoff until http://bugs.archlinux.org/task/9636 will be checked.

Actually, it turned out that the bug is in initscripts, not in udev.

I've just rendered my system unusable after installing udev-118-2 but not the latest initscripts, because initscripts in core check for start_udev, and when it's not available - falls back to static /dev which obviously has only a couple of files, and no /dev/sda*. User has to remount / in rw mode (to make changes to local db possible), then downgrade udev or update initscripts. This happens only when user upgrades udev without upgrading to initscripts first. I don't know how this should be solved in a clean way. Will a big fat warning in udev's pre_upgrade with 'read' command and Ctrl-C possibility be enought? The situation when upgrading initscripts and using older udev is already covered by depends=(... udev>=118 ...) in initscripts' PKGBUILD. -- Roman Kyrylych (Роман Кирилич)

2008/2/21, Dan McGee :

On Thu, Feb 21, 2008 at 9:33 AM, Roman Kyrylych wrote:

...

I've just rendered my system unusable after installing udev-118-2 but not the latest initscripts, because initscripts in core check for start_udev, and when it's not available - falls back to static /dev which obviously has only a couple of files, and no /dev/sda*. User has to remount / in rw mode (to make changes to local db possible), then downgrade udev or update initscripts.

This happens only when user upgrades udev without upgrading to initscripts first. I don't know how this should be solved in a clean way. Will a big fat warning in udev's pre_upgrade with 'read' command and Ctrl-C possibility be enought? The situation when upgrading initscripts and using older udev is already covered by depends=(... udev>=118 ...) in initscripts' PKGBUILD.

This is exactly why I wanted to do the udev upgrade a bit more gradually...

start_udev sucks, but we can leave it in for an iteration or two.

I think we could release udev-118-3 with start_udev in it. Older initscripts would use that and don't fail to static /dev, newer initscripts would use udevadm. Then in next version of udev we can safely remove it, I think. -- Roman Kyrylych (Роман Кирилич)

On Thu, Feb 21, 2008 at 9:33 AM, Roman Kyrylych wrote:

2008/2/21, Roman Kyrylych :

...

2008/2/21, Roman Kyrylych :

...

2008/2/21, Aaron Griffin :

...

This superseeds Dan's previous signoff for the 118 version bump. Included are the following changes: FS#8702 - Fix persistant input devices FS#8878 - Attempted speed up of load-modules.sh FS#8591 - Fix loading of RTC devices

Additionally, this package is required for the new initscripts which are required for the new ISOs. Please sign off

Sorry, won't signoff until http://bugs.archlinux.org/task/9636 will be checked.

Actually, it turned out that the bug is in initscripts, not in udev.

I've just rendered my system unusable after installing udev-118-2 but not the latest initscripts, because initscripts in core check for start_udev, and when it's not available - falls back to static /dev which obviously has only a couple of files, and no /dev/sda*. User has to remount / in rw mode (to make changes to local db possible), then downgrade udev or update initscripts.

This happens only when user upgrades udev without upgrading to initscripts first. I don't know how this should be solved in a clean way. Will a big fat warning in udev's pre_upgrade with 'read' command and Ctrl-C possibility be enought? The situation when upgrading initscripts and using older udev is already covered by depends=(... udev>=118 ...) in initscripts' PKGBUILD.

This is exactly why I wanted to do the udev upgrade a bit more gradually... start_udev sucks, but we can leave it in for an iteration or two. -Dan

2008/2/21, Aaron Griffin :

On Thu, Feb 21, 2008 at 2:26 PM, Pierre Schmitz wrote:

...

Am Donnerstag, 21. Februar 2008 08:10:19 schrieb Aaron Griffin:

...

Additionally, this package is required for the new initscripts which are required for the new ISOs. Please sign off

On my laptop udev needs 20s to load the modules. That's way too much. Was there any change which decreases performance that much?

Mine has always been slow. I attempted to improve performance in the load-modules script, but I believe this is actually a udev issue at this point... is the change significant from udev 116 and 118? I noticed little change but I never timed it.

See the new initscripts package which outputs timing stats in ms.

See http://bugs.archlinux.org/task/9648 Users did notice the slowdown too. And there is some nice bootchart. I guess udev developers did something wrong in 118. *shrugs* -- Roman Kyrylych (Роман Кирилич)

On Thu, Feb 21, 2008 at 4:08 PM, Aaron Griffin wrote:

On Thu, Feb 21, 2008 at 3:15 PM, Roman Kyrylych

wrote:

...

2008/2/21, Aaron Griffin :

...

On Thu, Feb 21, 2008 at 2:26 PM, Pierre Schmitz wrote:

...

Am Donnerstag, 21. Februar 2008 08:10:19 schrieb Aaron Griffin:

...

Additionally, this package is required for the new initscripts which are required for the new ISOs. Please sign off

On my laptop udev needs 20s to load the modules. That's way too much. Was there any change which decreases performance that much?

Mine has always been slow. I attempted to improve performance in the load-modules script, but I believe this is actually a udev issue at this point... is the change significant from udev 116 and 118? I noticed little change but I never timed it.

See the new initscripts package which outputs timing stats in ms.

See http://bugs.archlinux.org/task/9648 Users did notice the slowdown too. And there is some nice bootchart. I guess udev developers did something wrong in 118. *shrugs*

Oh crapshit.... this is my fault... Ok, throwing this one out to the gallery: Take a look at the new 00 rule in the udev package. The point is to export the blacklist to the udev environment for use in load-modules (it should only be computer once). Apparently, that rule is done poorly and it runs for every rule run-through.

See mod-blacklist here: http://privat.archlinux.dk/bootchart.png That should only be done once instead of the 28902373089434098 times it's run 8)

Idea #1: $ cat /etc/udev/rules.d/00-load-blacklist.rules ENV{MOD_AUTOLOAD} == "", IMPORT{program} = "/lib/udev/mod-blacklist.sh" This should only execute it when the env var isn't set. Would someone mind testing, I won't be home to watch a boot process for a bit

On Fri, Feb 22, 2008 at 1:45 AM, Xavier wrote:

Aaron Griffin wrote:

...

On Thu, Feb 21, 2008 at 4:08 PM, Aaron Griffin wrote:

...

Idea #1: $ cat /etc/udev/rules.d/00-load-blacklist.rules ENV{MOD_AUTOLOAD} == "", IMPORT{program} = "/lib/udev/mod-blacklist.sh"

This should only execute it when the env var isn't set. Would someone mind testing, I won't be home to watch a boot process for a bit

What is idea #2? ;) I tried this, and it didn't seem to work. Don't ask me why, I don't have the slightest idea how to debug this stuff.

Idea #2: $ mv /etc/udev/rules.d/00-load-blacklist.rules /etc/udev/rules.d/00-load-blacklist.rules.disabled in /etc/rc.sysinit, add ". /lib/udev/mod-blacklist.sh" and "export BLACKLSIT MOD_AUTOLOAD" right before the udevd --daemon call comment out the echo lines in the mod-blacklist script if you care Hopefully the environment vars that udev sees are also seen by scripts that it executes...

On Fri, Feb 22, 2008 at 1:43 PM, Xavier wrote:

I liked this solution more, no need to use an udev rule for something that just needs to be run once (and on every boot)

Quick comment here. This is *not* something that needs to be done once. It needs to be done once _for every time udev is started_. The only safe and sane way to do that is by using a udev rule that executes when udev starts.

On Fri, Feb 22, 2008 at 1:18 PM, Aaron Griffin wrote:

On Fri, Feb 22, 2008 at 1:45 AM, Xavier wrote:

...

Aaron Griffin wrote:

...

On Thu, Feb 21, 2008 at 4:08 PM, Aaron Griffin wrote:

...

Idea #1: $ cat /etc/udev/rules.d/00-load-blacklist.rules ENV{MOD_AUTOLOAD} == "", IMPORT{program} = "/lib/udev/mod-blacklist.sh"

This should only execute it when the env var isn't set. Would someone mind testing, I won't be home to watch a boot process for a bit

What is idea #2? ;) I tried this, and it didn't seem to work. Don't ask me why, I don't have the slightest idea how to debug this stuff.

Idea #2: $ mv /etc/udev/rules.d/00-load-blacklist.rules /etc/udev/rules.d/00-load-blacklist.rules.disabled in /etc/rc.sysinit, add ". /lib/udev/mod-blacklist.sh" and "export BLACKLSIT MOD_AUTOLOAD" right before the udevd --daemon call comment out the echo lines in the mod-blacklist script if you care

Hopefully the environment vars that udev sees are also seen by scripts that it executes...

Idea #3: The terrible one, but we ARE trying to shoot for speed here. In rc.sysinit, add "/lib/udev/mod-blacklist.sh > /var/run/module_loading" before udevd Add ". /var/run/module_loading" to the top of /lib/udev/load-modules.sh Modify mod-blacklist to output to a file in /tmp

Am Donnerstag, 21. Februar 2008 22:06:01 schrieb Aaron Griffin:

is the change significant from udev 116 and 118?

yes, the whole boot-up to X should be about 20s :-) -- archlinux.de