Bug#586404: udev-udeb: Very slow installation in Squeeze caused by udevadm settle
reassign 586404 debian-installer retitle 586404 d-i must not mix udev packages from different releases thanks On Jul 06, Otavio Salvador ota...@ossystems.com.br wrote: I agree with you; this shouldn't be fixed on udev but a new installer version to be released. Looks like there are no objections about this. Now the package will log a warning when messages from udevadm are ignored. -- ciao, Marco signature.asc Description: Digital signature
Bug#586404: udev-udeb: Very slow installation in Squeeze caused by udevadm settle
Hello, On Sun, Jul 4, 2010 at 4:30 PM, Frans Pop elen...@planet.nl wrote: On Sunday 04 July 2010, Petter Reinholdtsen wrote: Looks so, I never expected that the two packages could get out of sync. Is there some way to get the udevadm settle command work also with older udevd versions? Can the protocol be changed? This is a D-I release management problem and should IMO not be fixed any other way. I agree with you; this shouldn't be fixed on udev but a new installer version to be released. -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#586404: udev-udeb: Very slow installation in Squeeze caused by udevadm settle
[Marco d'Itri] Looks so, I never expected that the two packages could get out of sync. Is there some way to get the udevadm settle command work also with older udevd versions? Can the protocol be changed? But I have no idea about how to restart the daemon from the udeb. I do not know either, but suspect a empty postinst script to get a main-menu entry and a isinstallable script with the reloading might solve it. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#586404: udev-udeb: Very slow installation in Squeeze caused by udevadm settle
On Sunday 04 July 2010, Petter Reinholdtsen wrote: Looks so, I never expected that the two packages could get out of sync. Is there some way to get the udevadm settle command work also with older udevd versions? Can the protocol be changed? This is a D-I release management problem and should IMO not be fixed any other way. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#586404: udev-udeb: Very slow installation in Squeeze caused by udevadm settle
On Jul 04, Petter Reinholdtsen p...@hungry.com wrote: Looks so, I never expected that the two packages could get out of sync. Is there some way to get the udevadm settle command work also with older udevd versions? Can the protocol be changed? No. -- ciao, Marco signature.asc Description: Digital signature
Bug#586404: udev-udeb: Very slow installation in Squeeze caused by udevadm settle
[Petter Reinholdtsen] This make me suspect the problem is caused by the upgrade of udev-udeb. Perhaps the udev daemons is not restarted during upgrades, and the daemon and udevsettle binary end up using different protocols? I tried to restart udevd when udevadm settle started to hang for 3 minutes with my PXE installs, and after killing and restarting udevd the problem went away. After the restart, 'udevadm settle' started to return in a fraction of a second again. Perhaps the udeb should be written to handle upgrades and restart udevd when it is? Not quite sure how to do that, as the postinst script is not executed for packages without a main-menu entry. Perhaps udev-udeb need a main-menu entry to get it working? Or perhaps some isinstallable script can be used instead? A workaround would be to rebuild the d-i images in Squeeze to use the new udev-udeb, but the problem will probably resurface every time a new version of udev enter testing. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#586404: udev-udeb: Very slow installation in Squeeze caused by udevadm settle
On Jul 02, Petter Reinholdtsen p...@hungry.com wrote: Perhaps the udeb should be written to handle upgrades and restart udevd when it is? Not quite sure how to do that, as the postinst Looks so, I never expected that the two packages could get out of sync. But I have no idea about how to restart the daemon from the udeb. script is not executed for packages without a main-menu entry. Perhaps udev-udeb need a main-menu entry to get it working? Or perhaps some isinstallable script can be used instead? -- ciao, Marco signature.asc Description: Digital signature
Bug#586404: udev-udeb: Very slow installation in Squeeze caused by udevadm settle
Just a quick note from a DVD test I do at the moment. The slow udevadm settle problem do not show up with a DVD build, where the udev-udeb package is not on the DVD. Because of this the udev-udeb package is not upgraded within d-i, and the installation is not slowed down like it is when I do PXE installations. This make me suspect the problem is caused by the upgrade of udev-udeb. Perhaps the udev daemons is not restarted during upgrades, and the daemon and udevsettle binary end up using different protocols? Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#586404: udev-udeb: Very slow installation in Squeeze caused by udevadm settle
On Jun 24, Petter Reinholdtsen p...@hungry.com wrote: There are three udevd processes running. stracing two of them show ppoll(), while the last one with the lowest pid number do not show which system call it is doing. Not quite sure what is going on here. You need to strace the parent process for the whole time udevadm settle is running. -- ciao, Marco signature.asc Description: Digital signature
Bug#586404: udev-udeb: Very slow installation in Squeeze caused by udevadm settle
Hello Marco, Petter, You need to strace the parent process for the whole time udevadm settle is running. I spent some time today doing the above. Please find several strace files attached. The files have their original mtimes, so you'll be able to deduce easily which of the files came first or last :) Strange thing is that three of the strace files are empty. No output for *strace -v -s 400 -ff -o /tmp/udevadm.$$.log*. Regards, Allard udevadm.tar.gz Description: GNU Zip compressed data
Bug#586404: udev-udeb: Very slow installation in Squeeze caused by udevadm settle
On Jun 25, Allard Hoeve all...@byte.nl wrote: You need to strace the parent process for the whole time udevadm settle is running. This is useful, but we were talking about the parent udevd process. -- ciao, Marco signature.asc Description: Digital signature
Bug#586404: udev-udeb: Very slow installation in Squeeze caused by udevadm settle
This is useful, but we were talking about the parent udevd process. Right :) Will try to strace. Regards, Allard
Bug#586404: udev-udeb: Very slow installation in Squeeze caused by udevadm settle
Can you try rebuilding your initramfs, just to be sure that udevd and udevadm are from the same version. -- ciao, Marco signature.asc Description: Digital signature
Bug#586404: udev-udeb: Very slow installation in Squeeze caused by udevadm settle
Marco, Thanks for the feedback. I should've added that it's reproducable using the d-i daily build. Will check versions tomorrow. But I issue they're the same version in testing so will also be the same version in d-i. Regards, Allard On Jun 24, 2010 9:06 PM, Marco dapos;Itri m...@linux.it wrote: Can you try rebuilding your initramfs, just to be sure that udevd and udevadm are from the same version. -- ciao, Marco -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkwjrIsACgkQFGfw2OHuP7EAqwCaAyZx7zs920nl6zssxZhvxn8S HD8An1gy0Ugl4Sl25QI3OPPlQZU5fNIb =F10a -END PGP SIGNATURE-
Bug#586404: udev-udeb: Very slow installation in Squeeze caused by udevadm settle
On Jun 24, Allard Hoeve all...@byte.nl wrote: Thanks for the feedback. I should've added that it's reproducable using the d-i daily build. Will check versions tomorrow. But I issue they're the same version in testing so will also be the same version in d-i. If it happens while installing it has to be the same version, so we still do not know. Can somebody provide the strace (-v -s 400 -ff) output of the waiting udev and udevadm? -- ciao, Marco signature.asc Description: Digital signature
Bug#586404: udev-udeb: Very slow installation in Squeeze caused by udevadm settle
[Marco d'Itri] Can you try rebuilding your initramfs, just to be sure that udevd and udevadm are from the same version. Not easily. Is there a way to figure out which version of udevd and udevadm I got by looking inside the binaries? Where can I see the udev entries currently in the queue? I can see that the udev-udeb package is upgraded from version 150-2 to version 157-1 when the installer runs. Is this a problem? Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#586404: udev-udeb: Very slow installation in Squeeze caused by udevadm settle
On Jun 24, Petter Reinholdtsen p...@hungry.com wrote: Where can I see the udev entries currently in the queue? Run udevadm settle --timeout=0. I can see that the udev-udeb package is upgraded from version 150-2 to version 157-1 when the installer runs. Is this a problem? In theory, it should not be. -- ciao, Marco signature.asc Description: Digital signature
Bug#586404: udev-udeb: Very slow installation in Squeeze caused by udevadm settle
[Marco d'Itri] Where can I see the udev entries currently in the queue? Run udevadm settle --timeout=0. After the udev-udeb package is upgraded, this call hang the same way as 'udevadm settle', for 180 seconds before its alarm trigger. Did not test before the upgrade. There are three udevd processes running. stracing two of them show ppoll(), while the last one with the lowest pid number do not show which system call it is doing. Not quite sure what is going on here. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#586404: udev-udeb: Very slow installation in Squeeze caused by udevadm settle
Package: udev-udeb
Version: 157-1
Severity: important
User: debian-...@lists.debian.org
UserTags: debian-edu
Since some days ago, the debian-installer run in Squeeze is very slow
some times. Looking at the process list, I was able to trace it to
the calls to 'udevadm settle' being done several times during
installation. For example removing lvm partitions currently take 3
minutes _each_ because of this.
I did an strace of such udevadm run to try to figure out what is going
on. Here is the full strace log:
execve(/sbin/udevadm, [udevadm, settle], [/* 14 vars */]) = 0
brk(0) = 0x8fa
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb8095000
access(/etc/ld.so.preload, R_OK) = -1 ENOENT (No such file or directory)
open(/etc/ld.so.cache, O_RDONLY) = -1 ENOENT (No such file or directory)
open(/lib/tls/i686/sse2/cmov/libc.so.6, O_RDONLY) = -1 ENOENT (No such file
or directory)
stat64(/lib/tls/i686/sse2/cmov, 0xbfcedf4c) = -1 ENOENT (No such file or
directory)
open(/lib/tls/i686/sse2/libc.so.6, O_RDONLY) = -1 ENOENT (No such file or
directory)
stat64(/lib/tls/i686/sse2, 0xbfcedf4c) = -1 ENOENT (No such file or directory)
open(/lib/tls/i686/cmov/libc.so.6, O_RDONLY) = -1 ENOENT (No such file or
directory)
stat64(/lib/tls/i686/cmov, 0xbfcedf4c) = -1 ENOENT (No such file or directory)
open(/lib/tls/i686/libc.so.6, O_RDONLY) = -1 ENOENT (No such file or
directory)
stat64(/lib/tls/i686, 0xbfcedf4c) = -1 ENOENT (No such file or directory)
open(/lib/tls/sse2/cmov/libc.so.6, O_RDONLY) = -1 ENOENT (No such file or
directory)
stat64(/lib/tls/sse2/cmov, 0xbfcedf4c) = -1 ENOENT (No such file or directory)
open(/lib/tls/sse2/libc.so.6, O_RDONLY) = -1 ENOENT (No such file or
directory)
stat64(/lib/tls/sse2, 0xbfcedf4c) = -1 ENOENT (No such file or directory)
open(/lib/tls/cmov/libc.so.6, O_RDONLY) = -1 ENOENT (No such file or
directory)
stat64(/lib/tls/cmov, 0xbfcedf4c) = -1 ENOENT (No such file or directory)
open(/lib/tls/libc.so.6, O_RDONLY)= -1 ENOENT (No such file or directory)
stat64(/lib/tls, 0xbfcedf4c) = -1 ENOENT (No such file or directory)
open(/lib/i686/sse2/cmov/libc.so.6, O_RDONLY) = -1 ENOENT (No such file or
directory)
stat64(/lib/i686/sse2/cmov, 0xbfcedf4c) = -1 ENOENT (No such file or
directory)
open(/lib/i686/sse2/libc.so.6, O_RDONLY) = -1 ENOENT (No such file or
directory)
stat64(/lib/i686/sse2, 0xbfcedf4c)= -1 ENOENT (No such file or directory)
open(/lib/i686/cmov/libc.so.6, O_RDONLY) = -1 ENOENT (No such file or
directory)
stat64(/lib/i686/cmov, 0xbfcedf4c)= -1 ENOENT (No such file or directory)
open(/lib/i686/libc.so.6, O_RDONLY) = -1 ENOENT (No such file or directory)
stat64(/lib/i686, 0xbfcedf4c) = -1 ENOENT (No such file or directory)
open(/lib/sse2/cmov/libc.so.6, O_RDONLY) = -1 ENOENT (No such file or
directory)
stat64(/lib/sse2/cmov, 0xbfcedf4c)= -1 ENOENT (No such file or directory)
open(/lib/sse2/libc.so.6, O_RDONLY) = -1 ENOENT (No such file or directory)
stat64(/lib/sse2, 0xbfcedf4c) = -1 ENOENT (No such file or directory)
open(/lib/cmov/libc.so.6, O_RDONLY) = -1 ENOENT (No such file or directory)
stat64(/lib/cmov, 0xbfcedf4c) = -1 ENOENT (No such file or directory)
open(/lib/libc.so.6, O_RDONLY)= 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320m\1\0004\0\0\0...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1315008, ...}) = 0
mmap2(NULL, 1325384, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xb7f51000
mmap2(0xb808f000, 12288, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x13d) = 0xb808f000
mmap2(0xb8092000, 10568, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb8092000
close(3)= 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7f5
set_thread_area({entry_number:-1 - 6, base_addr:0xb7f508d0, limit:1048575,
seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0,
useable:1}) = 0
mprotect(0xb808f000, 8192, PROT_READ) = 0
mprotect(0xb80b3000, 4096, PROT_READ) = 0
brk(0) = 0x8fa
brk(0x8fc1000) = 0x8fc1000
open(/etc/udev/udev.conf, O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=15, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7f4f000
read(3, udev_log=\err\\n, 4096) = 15
read(3, , 4096) = 0
close(3)= 0
munmap(0xb7f4f000, 4096)= 0
rt_sigaction(SIGALRM, {0x8051df8, [], 0}, NULL, 8) = 0
rt_sigaction(SIGUSR1, {0x8051df8, [], 0}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [USR1 ALRM], NULL, 8) = 0
alarm(180) = 0
getuid32() =
Bug#586404: udev-udeb: Very slow installation in Squeeze caused by udevadm settle
On Jun 19, Petter Reinholdtsen p...@hungry.com wrote: The process hang after the sendto() call and the rt_sigsuspend() call, and time out with SIGALRM after what I suspect is 3 minutes. It does not hang, unless you can prove the contrary it is waiting for completion of pending events. Check /dev/.udev/queue/ while it is waiting, for a start. Maybe some package caused an events deadlock. You should also investigate the packages calling udevadm settle to be really sure that this is actually needed, often it is not. -- ciao, Marco signature.asc Description: Digital signature
Bug#586404: udev-udeb: Very slow installation in Squeeze caused by udevadm settle
[Marco d'Itri] It does not hang, unless you can prove the contrary it is waiting for completion of pending events. How can I prove the contrary? Have in mind that I do not really know much about the inner workings of udev. Check /dev/.udev/queue/ while it is waiting, for a start. That directory is empty while it is waiting. How can I find the list of pending events? Maybe some package caused an events deadlock. How can I test this idea? You should also investigate the packages calling udevadm settle to be really sure that this is actually needed, often it is not. How can this idea be tested? Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
