kernel-packages team mailing list archive
-
kernel-packages team
-
Mailing list archive
-
Message #25653
[Bug 358654] Re: udevadm trigger is not permitted while udev is unconfigured
** Branch linked: lp:~xnox/debian/sid/cryptsetup/ubuntu
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to bcmwl in Ubuntu.
https://bugs.launchpad.net/bugs/358654
Title:
udevadm trigger is not permitted while udev is unconfigured
Status in “bcmwl” package in Ubuntu:
Invalid
Status in “cryptsetup” package in Ubuntu:
Fix Released
Status in “devmapper” package in Ubuntu:
Fix Released
Status in “fuse” package in Ubuntu:
Triaged
Status in “kbd” package in Ubuntu:
Fix Released
Status in “linux” package in Ubuntu:
Incomplete
Status in “lvm2” package in Ubuntu:
Fix Released
Status in “ntfs-3g” package in Ubuntu:
Fix Released
Status in “plymouth” package in Ubuntu:
Fix Released
Status in “watershed” package in Ubuntu:
Fix Released
Bug description:
I've just finished helping a German user diagnose a failed-boot issue
after the system had been updated. The failure means that although
udevd starts it doesn't do anything so no devices are populated.
Later, we found a forums post (also in the German language) with the
same issue which shows:
udevadm trigger is not premitted while udev is unconfigured.
Gave up waiting for root device. Common problems:
-Boot args (cat /proc/cmdline)
-Check rootdelay= (did the system wait long enough)
-Check root= (did the system wait for the right device?)
-Missing modules (cat /proc/modules; ls /dev)
ALERT! /dev/disk/by-uuid/05d79451-0ad0-43fc-9f51-a2c98b4831f2 does not exist.
Dropping to a shell!
See: http://forum.ubuntuusers.de/topic/nach-update-bootet-laptop-
nicht-mehr/
It seems that the user was prompted to restart the system before the
system had been fully configured. I'm not sure how that could happen
and unfortunately we have no logs to look at, but this should at least
be on the radar.
The user reported he updates the system every day so in this case the
difference was between 8th April and 9th April.
Discussing it on 'ubuntu-devel kees suggested the best packages to
post this against since:
<kees> you could open it against both udev and linux :)
<kees> ...well both of those packages drop the "please reboot" file, so they likely both need to be fixed.
But Scott thought that wouldn't help and needs a cross reference check
of the postinst scripts against package depends:
<Keybuk> instead grep /var/lib/dpkg/info/*.postinst and look for calls to update-initramfs
<Keybuk> and check each of the packages to make sure they have Depends: initramfs-tools
<Keybuk> if you find some which don't, file bugs on them
For which the user needs to return to check their particular
installation, since they left in a hurry once the problem was finally
fixed.
However, the following shell script identifies some packages that
don't depend on initramfs-tools:
for ITEM in /var/lib/dpkg/info/*.postinst; do PKG=$(sed -n "/update-
initramfs/ s/.*/${ITEM##*/}/p" $ITEM | sort -u); [ ! -z $PKG ] &&
(apt-cache depends ${PKG%%.postinst} | grep Depends | grep -q
initramfs-tools || echo ${PKG%%.postinst}); done
For now I've assigned some of the packages this identifies whilst
discussion continues as to the extent of the issue.
----------
The solution is to use a live-CD to mount the system (or boot from a completely separate installation), mount the failed OS partition(s), and complete the update process:
e.g.
sudo -i
# create a target mount point
mkdir /mnt/target
# mount root
mount /dev/sda8 /mnt/target
# mount boot
mount /dev/sda9 /mnt/target/boot
# into Jaunty
chroot /mnt/target/
# update
dpkg --configure -a
# done
exit
#unmount
umount /mnt/target/boot
umount /mnt/target
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bcmwl/+bug/358654/+subscriptions