upstart/mountall does not boot after mounting crypto disks

Bug #438962 reported by rrva
18
This bug affects 4 people
Affects Status Importance Assigned to Milestone
udev (Ubuntu)
Confirmed
High
Unassigned
Karmic
Confirmed
High
Unassigned

Bug Description

Binary package hint: udev

Upstart fails to finish booting after starting init of crypto disks. udevd complains about inotify_add_watch(6, (null), 10) failed: Bad address. When investigating the system by forcing a getty to be spawned and logging in, I can see that / is read-only and swap is not mounted.

ProblemType: Bug
Architecture: amd64
Date: Tue Sep 29 22:07:06 2009
DistroRelease: Ubuntu 9.10
MachineType: LENOVO 423339G
Package: udev 147~-5
ProcCmdLine: auto BOOT_IMAGE=Linux ro root=/dev/mapper/vg1-root_crypt
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-11.36-generic
SourcePackage: udev
Tags: ubuntu-unr
Uname: Linux 2.6.31-11-generic x86_64
dmi.bios.date: 10/20/2008
dmi.bios.vendor: LENOVO
dmi.bios.version: 6GET12WW(V1.03)
dmi.board.name: KIWDX
dmi.board.vendor: LENOVO
dmi.board.version: REFERENCE
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: No Enclosure
dmi.chassis.version: N/A
dmi.modalias: dmi:bvnLENOVO:bvr6GET12WW(V1.03):bd10/20/2008:svnLENOVO:pn423339G:pvrLenovo3000N500:rvnLENOVO:rnKIWDX:rvrREFERENCE:cvnNoEnclosure:ct10:cvrN/A:
dmi.product.name: 423339G
dmi.product.version: Lenovo 3000 N500
dmi.sys.vendor: LENOVO

Revision history for this message
rrva (ragnar-rova) wrote :
Revision history for this message
Steve Langasek (vorlon) wrote :

Pasting the user's fstab as requested (non-booting systems make cut-n-paste !fun)

# /etc/fstab: static file system information.
#
# Use 'vol_id --uuid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
/dev/mapper/vg1-root_crypt / ext4 relatime,errors=remount-ro 0 1
# /boot was on /dev/mapper/vg0-boot during installation
UUID=350a70dd-78c3-4616-ae04-7038341cda18 /boot ext3 relatime 0 2
/dev/mapper/vg1-swap_crypt none swap sw 0 0
/dev/scd0 /media/cdrom0 udf,iso9660 user,noauto,exec,utf8 0 0
/resumefile swap swap noauto,defaults 0 0

Changed in udev (Ubuntu):
importance: Undecided → High
status: New → Confirmed
rrva (ragnar-rova)
tags: added: ubuntu-boot
Revision history for this message
Timothy Pearson (kb9vqf) wrote :

Don't know if this will help you track it down, but I have several identical computers, each running an identical imaged Karmic installation. One of them is unaffected by this bug, and the other two will not boot no matter what I do--including re-imaging from the working one. (???)

Could the BIOS configuration/version have any role in this?

Revision history for this message
goto (gotolaunchpad) wrote :

Architecture: i386
Date: Fri Oct 2 19:13:12 2009
DistroRelease: Ubuntu 9.10
Package: upstart 0.6.3-5
ProcEnviron:
 SHELL=/bin/bash
 PATH=(custom, no user)
Uname: Linux 2.6.31-4-generic i686
System: IBM Thinkpad X40, 2371LG3

# /etc/fstab: static file system information.
/dev/mapper/sda2_crypt / btrfs errors=remount-ro,compress,ssd 0 1
/dev/sda1 /boot ext2 defaults 0 2

I've seen the same behaviour after an update. Persists even after a tried reinstall. My root partition is a luks-encrypted btrfs, which worked fine with Alpha5. I'm still using the older kernel, because the alpha6 initrd doesn't even find the cryptoroot.

Cannot decipher where exactly the boot/upstart hang occours, but mountall.conf seems a problem spot on my setup too. The initial error message is identical: "udevd[1283]: inotify_add_watch(...) Bad address". The initrd cryptsetup ran through fine.

upstart/initctl doesn't give any details to where or why it hangs. Is there a debug mode or /etc/init.conf setting to make it verbose?

Revision history for this message
rrva (ragnar-rova) wrote :

My problem went away by reinstalling jaunty from scratch and then upgrading to karmic via aptitude. Don't know what triggered this. New install has the same filesystem setup with crypto disks.

Revision history for this message
goto (gotolaunchpad) wrote :

Me too. A _clean_ reinstall with Karmic-Beta1-desktop fixed most bootup problems. System is working again with luks-encrypted root partition and btrfs (- with manual conversion after install).

Guess: some remaining Alpha5 init.d/ scripts (or udev rules??) caused most of the upgrade / boot problems.
No idea if that helps - but I just attach my etc/ directory here. (karmic-....tbz2, some cruft removed)

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.