joenix, could you please open a new bug at https://launchpad.net/distros/ubuntu/+source/udev/+filebug and attach that file to it once reported -- you have a slightly different problem to Thilo and it will only be confusing if I attempt to address you both at the same time.

Thilo, a couple of interesting things from your boot ...

UEVENT[1146485653.660855] add@/class/sound/sequencer
UEVENT[1146485653.661309] add@/class/sound/sequencer2
UEVENT[1146483565.704583] add@/module/snd_seq_dummy
UEVENT[1146485829.758535] add@/module/lp
UEVENT[1146485829.760120] add@/class/printer/lp0

There's almost 180 seconds between the event for the sound card being sent, and the event for the printer.  This is a magic number, because it's the longest that we wait for hardware to respond to configuration.

So this implies one of the devices before 1146483565.704583 failed to complete configuration, and that we hung around for it.  Everything after 1146485829.758535 is a record of what "else" happened during the boot process -- this is deliberately logged on failed boots.

The log of what was processed is more interesting ...

UDEV  [1146485653.750400] add@/devices/pci0000:00/0000:00:11.5/card0-0
UDEV  [1146485653.771296] add@/class/sound/controlC0
UDEV  [1146485653.776458] add@/class/sound/mixer
UDEV  [1146485709.010692] add@/block/hdc
UDEV  [1146485829.759557] add@/module/lp
UDEV  [1146485829.762179] add@/class/printer/lp0

The sound card events are processed in under a tenth of a second, as we'd expect.  Likewise after the magic barrier, the printer events are processed within a thousandth of a second or two, again as we'd expect.

The interesting one is that "/block/hdc" stuck in the middle, which shouldn't be there ... if we look for the original send of this event and compare the two times:

UEVENT[1146485650.591980] add@/block/hdc
UDEV  [1146485709.010692] add@/block/hdc

This event took almost 60s to be processed.

Likewise there's a UEVENT for /block/hdd but not UDEV, implying that this was not processed.

So let's look at those events together:

UEVENT[1146485650.591980] add@/block/hdc
ACTION=add
DEVPATH=/block/hdc
SUBSYSTEM=block
SEQNUM=1569
MINOR=0
MAJOR=22
PHYSDEVPATH=/devices/pci0000:00/0000:00:0f.1/ide1/1.0
PHYSDEVBUS=ide
PHYSDEVDRIVER=ide-cdrom

UEVENT[1146485650.594503] add@/block/hdd
ACTION=add
DEVPATH=/block/hdd
SUBSYSTEM=block
SEQNUM=1570
MINOR=64
MAJOR=22
PHYSDEVPATH=/devices/pci0000:00/0000:00:0f.1/ide1/1.1
PHYSDEVBUS=ide
PHYSDEVDRIVER=ide-cdrom

UDEV  [1146485709.010692] add@/block/hdc
UDEV_LOG=3
ACTION=add
DEVPATH=/block/hdc
SUBSYSTEM=block
SEQNUM=1569
MINOR=0
MAJOR=22
PHYSDEVPATH=/devices/pci0000:00/0000:00:0f.1/ide1/1.0
PHYSDEVBUS=ide
PHYSDEVDRIVER=ide-cdrom
UDEVD_EVENT=1
ID_CDROM=1
ID_CDROM_CD_R=1
ID_CDROM_CD_RW=1
ID_CDROM_MRW=1
ID_CDROM_MRW_W=1
ID_CDROM_RAM=1
ID_TYPE=cd
ID_MODEL=SONY_CD-RW_CRX140E
ID_SERIAL=
ID_REVISION=1.0c
ID_BUS=ata
ID_PATH=pci-0000:00:0f.1-ide-1:0
DEVNAME=/dev/hdc
DEVLINKS=/dev/cdrom /dev/cdrw /dev/disk/by-path/pci-0000:00:0f.1-ide-1:0


This is where my suspicion lies, your CD-RW drive (/dev/hdc) took 60s to configure, and the second {CD/DVD}-{ROM/RW} (/dev/hdd) didn't complete configuration at all.

A common cause of this is hdparm, where we have a problem with certain "one-in-a-million" combinations of hardware.

So to test whether this is the cause, could you do this for me:

When you boot the computer, press Esc to get into the boot loader menu (the Ubuntu one), press "e" to edit the default entry (the one that fails), hilight the line in the menu with the kernel filename and command line, press "e" again, then make the following changes:

Remove "quiet" and "splash"
Replace them with "nohdparm"

Enter and "b" to boot with those changes; and let me know whether that boots up normally, or whether that fails.  If it works fine, please attach your /etc/hdparm.conf file; if it still hangs, we'll look at some other problem