[arch-dev-public] [signoff] udev 118-2
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
2008/2/21, Aaron Griffin <aaronmgriffin@gmail.com>:
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. -- Roman Kyrylych (Роман Кирилич)
2008/2/21, Roman Kyrylych <roman.kyrylych@gmail.com>:
2008/2/21, Aaron Griffin <aaronmgriffin@gmail.com>:
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. -- Roman Kyrylych (Роман Кирилич)
2008/2/21, Roman Kyrylych <roman.kyrylych@gmail.com>:
2008/2/21, Roman Kyrylych <roman.kyrylych@gmail.com>:
2008/2/21, Aaron Griffin <aaronmgriffin@gmail.com>:
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 (Роман Кирилич)
On Thu, Feb 21, 2008 at 9:33 AM, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
2008/2/21, Roman Kyrylych <roman.kyrylych@gmail.com>:
2008/2/21, Roman Kyrylych <roman.kyrylych@gmail.com>:
2008/2/21, Aaron Griffin <aaronmgriffin@gmail.com>:
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, Dan McGee <dpmcgee@gmail.com>:
On Thu, Feb 21, 2008 at 9:33 AM, Roman Kyrylych <roman.kyrylych@gmail.com> 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 10:15 AM, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
2008/2/21, Dan McGee <dpmcgee@gmail.com>:
On Thu, Feb 21, 2008 at 9:33 AM, Roman Kyrylych <roman.kyrylych@gmail.com> 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.
Ugh, good catch. It's annoying that we have to do this, but meh. I don't have a problem with it for a few versions. I will fix this at some point today, and rebuild for x86_64 - I will need someone else to build for i686 though.
On Thu, Feb 21, 2008 at 9:33 AM, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
2008/2/21, Roman Kyrylych <roman.kyrylych@gmail.com>:
2008/2/21, Roman Kyrylych <roman.kyrylych@gmail.com>:
2008/2/21, Aaron Griffin <aaronmgriffin@gmail.com>:
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
On Thu, 2008-02-21 at 10:04 -0600, Dan McGee wrote:
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.
Don't we have versioned conflicts since pacman 3.1.1? Make the next udev that doesn't include this start_udev script conflict with any initscripts version that is older than the one that doesn't use it anymore.
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? -- archlinux.de
On Thu, Feb 21, 2008 at 2:26 PM, Pierre Schmitz <pierre@archlinux.de> 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.
2008/2/21, Aaron Griffin <aaronmgriffin@gmail.com>:
On Thu, Feb 21, 2008 at 2:26 PM, Pierre Schmitz <pierre@archlinux.de> 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 3:15 PM, Roman Kyrylych <roman.kyrylych@gmail.com> wrote:
2008/2/21, Aaron Griffin <aaronmgriffin@gmail.com>:
On Thu, Feb 21, 2008 at 2:26 PM, Pierre Schmitz <pierre@archlinux.de> 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)
On Thu, Feb 21, 2008 at 4:08 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Thu, Feb 21, 2008 at 3:15 PM, Roman Kyrylych
<roman.kyrylych@gmail.com> wrote:
2008/2/21, Aaron Griffin <aaronmgriffin@gmail.com>:
On Thu, Feb 21, 2008 at 2:26 PM, Pierre Schmitz <pierre@archlinux.de> 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
Aaron Griffin wrote:
On Thu, Feb 21, 2008 at 4:08 PM, Aaron Griffin <aaronmgriffin@gmail.com> 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.
On Fri, Feb 22, 2008 at 1:45 AM, Xavier <shiningxc@gmail.com> wrote:
Aaron Griffin wrote:
On Thu, Feb 21, 2008 at 4:08 PM, Aaron Griffin <aaronmgriffin@gmail.com> 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 01:18:38PM -0600, Aaron Griffin wrote:
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...
No, they apparently aren't :( 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), but sadly, the load-modules script doesn't see the vars. So the boot was quick, but no autoloading was done. I manually added "MOD_AUTOLOAD=yes" at the top of load-modules script, and it worked. (obviously that's not a solution, it was just a check).
On Fri, Feb 22, 2008 at 1:43 PM, Xavier <shiningxc@gmail.com> 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 01:51:44PM -0600, Aaron Griffin wrote:
On Fri, Feb 22, 2008 at 1:43 PM, Xavier <shiningxc@gmail.com> 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.
Oh right, good point, I didn't think about this. So right, an udev rule is not that bad. If only the ENV stuff worked.. It would be good if others checked it though, to be sure it's not some stupid mistake of my part (or on my system).
On Fri, Feb 22, 2008 at 1:18 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Fri, Feb 22, 2008 at 1:45 AM, Xavier <shiningxc@gmail.com> wrote:
Aaron Griffin wrote:
On Thu, Feb 21, 2008 at 4:08 PM, Aaron Griffin <aaronmgriffin@gmail.com> 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
On Fri, Feb 22, 2008 at 02:08:52PM -0600, Aaron Griffin wrote:
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
Hm, I tried to do that, but it complained about read only filesystem. Looks like there is no place where we can create a file on the filesystem at this point.
Modify mod-blacklist to output to a file in /tmp
Why? You alredy redirected mod-blacklist output to /var/run/module_loading above.
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
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?
An user reported the same problem on irc. Here is the bug report : http://bugs.archlinux.org/task/9648
participants (6)
-
Aaron Griffin
-
Dan McGee
-
Jan de Groot
-
Pierre Schmitz
-
Roman Kyrylych
-
Xavier