This problem seemed to have intensified for me in my test system in
Oneiric and we were finally able to track it down to /usr/share
/initramfs-tools/scripts/init-bottom/udev. In there the boot process
tries to stop udevd and then move all the special filesystems (/dev,
/proc, and /sys) over to the new rootfs and finally switching to that
before restarting udevd. However udevd is still launching processes to
create devnodes at that point. And it seems in some rare cases the pkill
(SIGTERM) fails to really kill all of the udevd processes, which leads
to situation were the initramfs cannot be completely nuked and that
triggers a panic.
In Oneiric udevadm has a way to stop udevd in a more sensible way which
also waits until udev actually stopped (udevadm control --exit). Thought
this is not possible with the versions of udev in Natty and Maverick.
Making udevd at least not starting new processes (udevadm control
--stop-exec-queue). Using that before the pkill would prevent a lot of
those ugly "workers have been killed" and "/dev/null not found"
messages. Unfortunately there still seemed to be a (much smaller) chance
to hit the problem where udevd does not stop on SIGTERM.
So I am not sure which path is the better / simpler to implement one.
Have the ability of using a --exit backported from newer udev packages
or possibly retry the pkill a few times and if that does not remove the
udev processes, switch to a more brutal signal before finally giving
up... But either way it is not a kernel problem but udev or initramfs-
tools side.
** Changed in: linux (Ubuntu)
Status: Triaged => Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/613273
Title:
kernel panic on ec2 in system_call_fastpath
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/613273/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
