I feel like I have _almost_ found the ANSWER. It only took a week.
3.2.0-4-amd64 SMP Debian 3.2.46-1+deb7u1 x86_64 GNU/Linux
See the attached
udev.modified file. My modifications are near the comments that start #MMMMMMMMM .
I'ved tried to attach a file, but it has not showed up yet. Sigh.
The problem comes about because the
udevadm trigger command causes actions on the various buses, in particular the PCI and PCIexpress buses that hold things like the graphics cards. And in particular the graphics card that is being written to by the
/etc/init.d/udev script that is running the
udevadm trigger command. In my case, this produced a (supposedly) harmless message saying that the
pcieport driver was not able to do something it wanted to.
But that is the problem. The graphics card is being
touched _while_ the udev script is trying to write through it.
In my case, the boot would fail about once every 5 times or so, apparently at random.
But I found, the more
log_*_msg items I put in to trace the execution, the more often it failed.
So my modification is to
not print
anything between the
udevadm trigger and the
udevadm settle commands.
(I am discovering in further testing that this modification is well shy of 100% reliable. I am still fiddling. The evidence is that the
udevadm trigger is bit fragile when it is poking on the PCI/PCIe bus.
There are also 3
sleep commands in there to avoid a race conditions that apparently exist between and among the log messages and the
udevadm commands.
Code: Select all
## This has bee rewritten to prevent writing to the console while
## udevd is populating /dev.
## Experience shows that if the graphics card is being prodded at
## the same time as something is writing to it, the machine might
## suffer a hangup.
log_action_msg "Populate /dev; wait until it is full. (up to 120 seconds)"
## Yes, the sleeps seem to be necessary.
sleep 1
udevadm trigger --action=add
sleep 2
udevadm settle
sleep 2
log_action_msg "/dev is populated."
Here is the entire
start) case (the 2nd one! -- there are two start-stop-restart ... cases in this file)
Code: Select all
# When modifying this script, do not forget that between the time that the
# new /dev has been mounted and udevadm trigger has been run there will be
# no /dev/null. This also means that you cannot use the "&" shell command.
log_warning_msg "$0 $1: MODIFIED" #MMMMMMMMMMMMMMMMMMMMMMMMMMMMM
case "$1" in
start)
if init_is_upstart 2>/dev/null; then
exit 1
fi
if mountpoint -q $udev_root/; then
TMPFS_MOUNTED=1
elif [ -e "$udev_root/.udev/" ]; then
log_warning_msg ".udev/ already exists on the static $udev_root"
fi
if [ ! -e "$udev_root/.udev/" -a ! -e "/run/udev/" ]; then
warn_if_interactive
fi
echo > /sys/kernel/uevent_helper
move_udev_database
if [ -z "$TMPFS_MOUNTED" ]; then
unmount_devpts
mount_tmpfs
[ -d /proc/1 ] || mount -n /proc
fi
# clean up parts of the database created by the initramfs udev
udevadm info --cleanup-db
# set the SELinux context for devices created in the initramfs
[ -x /sbin/restorecon ] && /sbin/restorecon -R /dev
# /dev/null must be created before udevd is started
/lib/udev/create_static_nodes || true
log_daemon_msg "Starting the hotplug events dispatcher" "udevd"
if udevd --daemon; then
log_end_msg $?
else
log_warning_msg $?
log_warning_msg "Waiting 15 seconds and trying to continue anyway"
sleep 15
fi
/lib/udev/write_dev_root_rule
#MMMMMMMMMMMMMMMMMvvvvvvvvvvvvvvvvvvv Reworked.
create_dev_makedev
## This has bee rewritten to prevent writing to the console while
## udevd is populating /dev.
## Experience shows that if the graphics card is being prodded at
## the same time as something is writing to it, the machine might
## suffer a hangup.
log_action_msg "Populate /dev; wait until it is full. (up to 120 seconds)"
## Yes, the sleeps seem to be necessary.
sleep 1
udevadm trigger --action=add
sleep 2
udevadm settle
sleep 2
log_action_msg "/dev is populated."
#MMMMMMMMMMMMMMMMM^^^^^^^^^^^^^^^^^^^^
;;
