Bug#498645: initramfs-tools: Boot takes three minutes to finish (!)
On Thu, Sep 11, 2008 at 08:40:30PM +0200, Santiago Vila wrote:
> Package: initramfs-tools
> Version: 0.92i
>
> After installing a lenny system today, it happened that the boot
> process takes more than 3 minutes to finish. Needless to say, I first
> believed it was frozen and didn't work at all. I was lucky to discover
> (by accident) that it was a very long waiting time instead.
>
> After a bit of investigation, it happened that this value, 180 seconds,
> is the default timeout for "udevadm settle", according to udevadm(8).
>
> Unfortunately, there is not a simple way to change this. First I tried
> changing "udevadm settle" invocation in /etc/init.d/udev but this only
> worked for linux images not using a ramdisk (I built several of those as
> I first suspected to be a kernel problem).
your hardware must be seriously broken,
never seen any box reaching that timeout.
> What worked finally was to change "udevadm settle" invocation at
>
> /usr/share/initramfs-tools/scripts/init-premount/udev
>
> and then rebuilding the initramfs via dpkg-reconfigure linux-image-etc-etc.
>
> While doing this I noticed that "udevadm settle" is called three times
> in /usr/share/initramfs-tools/*. Two of them are wrapped via wait_for_udev()
> from /usr/share/initramfs-tools/scripts/functions and they have 10 seconds
> as the timeout value. The other one is the one I had to hardcode by hand.
>
> To summarize: No matter how faulty my hardware might be (the boot
> never took so long with etch), I don't think it is reasonable at all
> that a user has to do this in order for the boot process not to take
> more than three minutes.
>
> Maybe every "udevadm settle" invocation should be wrapped via wait_for_udev(),
> not just two of them. Or maybe this is a bug in udev for having such a long
> waiting time. Feel free to reassign.
>
> Note: I see this as a serious bug, but as I don't know the number of
> people having this problem, I prefer not to use a severity at all.
this looks more like a kernel bug,
please provide lspci and dmesg of that box.
--
maks
Reply to: