Bug#357450: udev: timeout in initramfs-tools/scripts/init-premount/udev to short for 17 scsi disks
On Fri, Mar 17, 2006 at 04:34:06PM +0100, maximilian attems wrote:
> On Fri, 17 Mar 2006, Maurice Massar wrote:
> > On Fri, Mar 17, 2006 at 04:08:20PM +0100, maximilian attems wrote:
> > > which initramfs-tools version are you using?
> > ii initramfs-tools 0.55b tools for generating an initramfs
> that puzzles me, please post
> ls -l /boot/initrd.img-2.6.1*
-rw-r--r-- 1 root root 4848805 2006-03-17 13:56 /boot/initrd.img-2.6.15-1-k7
(I only have one kernel installed, new machine)
If you want a closer look:
(this is my version without timeout in scripts/init-premount/udev)
> 0.55b should not drop you into the busyboxshell on scsi/usb boots,
> as it should handle those longer timeouts of scsi device just fine.
> the boot you pasted could be possible with 0.53c
> are you sure that the initrd.img your booting is up2date,
> if not try
> update-initramfs -u -k <kernelversion>
I am. Somehow I had this initrd broken (did not load any modules at all)
so after manually booting (modprobe, mknod, ..) I did a dist-upgrade
first, then removed the initrd and rebuild it with update-initramfs.
Rerunning update-initramfs and comparing the files (with zcat | cpio; diff)
shows that it stays the same.
> > this timeout-code is inside
> > /usr/share/initramfs-tools/scripts/init-premount/udev
> > which is provided by udev, not initramfs-tools.
> > So I assumed this bug belonged to udev.
> np watching both bug reports,
> please explain in more details what you did with
> "Disabling the timeout-code worked for me."
--- u/usr/share/initramfs-tools/scripts/init-premount/udev 2006-03-14 12:22:24.000000000 +0100
+++ /usr/share/initramfs-tools/scripts/init-premount/udev 2006-03-17 13:55:39.000000000 +0100
@@ -24,9 +24,9 @@
while [ -d /dev/.udev/queue/ ]; do
udevd_timeout=$(($udevd_timeout - 1))
- if [ $udevd_timeout -eq 0 ]; then
+# if [ $udevd_timeout -eq 0 ]; then
# Leave udev running to process events that come in out-of-band (like USB