Hmmm, I guess the original report of this bug is not for a netbook, but
a server. Still I see this in the BootDmesg.txt attached to this bug:
[3.521410] input: ATEN CS1308 V1.2.114 as
/devices/pci:00/:00:1d.2/usb4/4-1/4-1.1/4-1.1:1.1/input/input4
[3.521587] generic-usb
On Fri, Oct 07, 2011 at 06:12:51AM -, Eduard Hasenleithner wrote:
Hmmm, I guess the original report of this bug is not for a netbook, but
a server. Still I see this in the BootDmesg.txt attached to this bug:
[3.521410] input: ATEN CS1308 V1.2.114 as
Just for the record (I do have an LVM setup): Installing the PPA with
pkill enabled still gives me a read-only root filesystem (after 60s
timeout). Don't know how this will turn out for the cases without LVM
(i.e. without vgscan hanging).
--
You received this bug notification because you are a
Looking through the udev code, I can't really see any reason that pkill
would be more effective than udevadm control --exit (as earlier
reported), except if udevd has somehow lost track of a worker, because
both are supposed to send SIGTERM to all the processes. Furthermore, if
udevadm is doing
** Tags added: iso-testing
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/818177
Title:
boot failures because 'udevadm exit' does not kill udevd worker
threads
To manage notifications about this
Quoting Eduard Hasenleithner (edu...@hasenleithner.at):
Just for the record (I do have an LVM setup): Installing the PPA with
pkill enabled still gives me a read-only root filesystem (after 60s
timeout). Don't know how this will turn out for the cases without LVM
(i.e. without vgscan hanging).
Quoting Steve Langasek (steve.langa...@canonical.com):
Serge,
Picking that log apart, I see one worker thread (pid 94) not exiting
cleanly, whereas all the others do. No clear indication of why this
worker would have failed to exit since its own log output shows it
completely processing an
Another log - the hanging event is again for a tty, but for a different
one.
** Attachment added: udev5.log
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/818177/+attachment/2522595/+files/udev5.log
--
You received this bug notification because you are a member of Ubuntu
Bugs, which
@Steve,
When the hang happens, the ps -ef /run/.initramfs/udevps.log I placed
at the bottom of initrd's /scripts/init-bottom/udev does not appear to
happen. (On a good boot, it does)
Here is the udev log file printing out the info about the hanging worker
and event.
** Attachment added:
Could you (and others) also try the udev from ppa:vorlon/ppa, and see if
this makes a difference in bootability? This adds the pkill after
udevadm control --exit. If it works, we know udevd is losing track of
its worker threads...
The 60 second timeout still happens with udev from your ppa.
Just to be clear, the output in #57 is *before* we attempt to kill udevd
in any shape or form.
Doing some experimentation, I've found that a long-running udev rule
continues to run post-initramfs, so although the workers should be being
killed, the children of them (vgscan et al) shouldn't be.
I've just noticed something odd: if you interrupt the initramfs before
it kills udev and performs the move mount, /root/dev/ contains a ton of
device entries including console, zero, null (I was expecting /root/dev/
to be empty).
As @apw has just suggested, this could well explain why I and other
James Hunt [2011-10-07 16:18 -]:
I've just noticed something odd: if you interrupt the initramfs before
it kills udev and performs the move mount, /root/dev/ contains a ton of
device entries including console, zero, null (I was expecting /root/dev/
to be empty).
That should be the usual
I guess james point is that if you happen to have a rather complete set
of device nodes from a really old installation in root/dev, this might
help you in the case when the devtmpfs cannot be moved.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
On Fri, Oct 07, 2011 at 04:18:09PM -, James Hunt wrote:
I've just noticed something odd: if you interrupt the initramfs before
it kills udev and performs the move mount, /root/dev/ contains a ton of
device entries including console, zero, null (I was expecting /root/dev/
to be empty).
A fresh oneiric server install seems to generally show 88-91 device
entries in /root/dev/. My oneiric system that has been upgraded from
maverick contains 90 device entries.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
@Serge: following on from comments #54 and #57 - could you possibly add
a line after the udevadm control --exit so we can see the ps output at
that point?
echo XXX: POST udevd: ps=`ps -ef`, /dev=`ls -l /dev` /dev/kmsg
--
You received this bug notification because you are a member of Ubuntu
Quoting James Hunt (818...@bugs.launchpad.net):
@Serge: following on from comments #54 and #57 - could you possibly add
a line after the udevadm control --exit so we can see the ps output at
that point?
echo XXX: POST udevd: ps=`ps -ef`, /dev=`ls -l /dev` /dev/kmsg
I already had that:
I have to withdraw my Comment #71. At that time I did not have yet the
new initial-ramdisk installed. Having it installed, gives me always an
read-only rootfs.
And I think, I have also found the reason. The scripts in the initial
ramdisk are executed with set -e. In this case your pkill fails and
I've just pushed a new udev package to ppa:vorlon/ppa which should
provide better debugging capabilities. It unconditionally runs 'udevadm
monitor -e' before starting udevd, and spits out the complete list of
kernel/udev events after udevd is stopped in the initramfs - as well as
spitting out a
On Fri, Oct 07, 2011 at 09:55:52PM -, Eduard Hasenleithner wrote:
And I think, I have also found the reason. The scripts in the initial
ramdisk are executed with set -e. In this case your pkill fails and
aborts the execution of init-bottom/udev. And in the normal case,
init-bottom/udev
So, maybe we just put a
udevadm control --exit || pkill udevd || true
in the init-bottom/udev and close this bug ;)
The occasional 60s boot delay will stay, some stray udev RUN commands might
remain in memory, but Oneiric is at least supposed to start properly.
Nevertheless, I'd be very
** Attachment added: udev log
https://bugs.launchpad.net/ubuntu/oneiric/+source/udev/+bug/818177/+attachment/2525702/+files/udev.initramfs.log
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/818177
** Attachment added: ps -ef output at bottom of scripts/init-bottom/udev
https://bugs.launchpad.net/ubuntu/oneiric/+source/udev/+bug/818177/+attachment/2525703/+files/udev.initramfs.log2
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
** Attachment added: output of 'udevd -D --daemon ...
/dev/.udev.initramfs.log3 21
https://bugs.launchpad.net/ubuntu/oneiric/+source/udev/+bug/818177/+attachment/2525704/+files/udev.initramfs.log3
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
I'm able to reproduce the same behavior that Serge sees when running in
a VM, and now have a clear understanding of what's happening here at the
top level.
The init-bottom script, as noted earlier, is set -e; and udevadm control
exits non-zero if it hits its timeout. These two factors combined
** Summary changed:
- boot failures caused by udev race
+ boot failures because 'udevadm exit' does not kill udevd worker threads
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/818177
Title:
boot
The output in comment #57 is pretty conclusive. The call to 'udevadm
exit' is killing the parent process, but leaving all the worker threads
running... and these worker threads are holding /dev open, preventing
the mount -o move from working.
The use of 'udevadm exit' is a recent (oneiric-cycle)
All of this should land in oneiric-updates now, rather than trying to
squeeze it in before release. It's an annoying boot-time race
condition, but doesn't affect installation itself (if the race hits on
the first reboot after install, well reboot again). So we should
aim for this to be a
I've read all the comments in this bug thoroughly, and for every log
file which has timestamps in it, there appears to be the 60s delay
caused by the udev exit timeout on hanging children. If that is true,
then even when adding pkill to the initrd scripts, there will still be
the 60s delay on
** Also affects: ubuntu-release-notes
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/818177
Title:
boot failures because 'udevadm exit' does not kill
** Also affects: linux (Ubuntu Precise)
Importance: Undecided
Status: New
** Also affects: udev (Ubuntu Precise)
Importance: Undecided
Status: New
** Changed in: linux (Ubuntu Precise)
Status: New = Invalid
** Changed in: udev (Ubuntu Precise)
Status: New =
If we can't get this fix in for release, it definitely needs to be
release-noted.
** Changed in: ubuntu-release-notes
Status: New = Triaged
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/818177
On Thu, Oct 06, 2011 at 09:12:50PM -, Eduard Hasenleithner wrote:
I've read all the comments in this bug thoroughly, and for every log
file which has timestamps in it, there appears to be the 60s delay
caused by the udev exit timeout on hanging children.
In fact I only see *one* such log
Based on additional feedback from Daviey regarding the possible urgency
of getting this in before release, I've reviewed the upstream changes
since the 173 release. Of course, with kernel.org down for the past
month, there's not really much of it. No indication of an upstream fix
for udevadm
With initrd's scripts/init-top/udev changed to run udev with -D and
/run/initrd/udev.log 21, I get this output. I also added to
udev/udevd.c the following patch. Note that IIUC there are both workers
and events on the list. Every time that I've tried to print out info
about the remaining
@Steve,
well there *is* the kernel patch https://lkml.org/lkml/2011/8/22/155,
which doesn't seem to be upstream yet.
Hard to believe anything is doing clone(CLONE_NEWNET) during boot
(though not impossible), but I wonder if udevd stopping reading events
could trigger this.
--
You received this
** Tags added: rls-mgr-o-tracking
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/818177
Title:
boot failures because 'udevadm exit' does not kill udevd worker
threads
To manage notifications
Serge,
Picking that log apart, I see one worker thread (pid 94) not exiting
cleanly, whereas all the others do. No clear indication of why this
worker would have failed to exit since its own log output shows it
completely processing an event (seq 1072) and doesn't show it picking up
another one;
39 matches
Mail list logo
