Feisty: Boot takes very long time after last upgrade

[Riccardo Lucchese]

Hi

After the last upgrade(i think it was 18pm in Italy) the boot in Feisty takes _really_ a long time doing "apparently" nothing.
I see the boot splash screnn, then I hear a "click" when the audio module is loaded and when the orange bar arrives near the middle of the widget nothing more happens for one minute or something.
Also no reading or writing to disk in this minute.

Switching to shell i see:
...
kinit: no resume image, doing normal boot
- 1 minute doing nothing -

Sometimes i get this instead:
...
kinit: no resume image, doing normal boot
[20.484000] intel_rng: FWH not detected
- 1 minute doing nothing -

After that the machine(a laptop) goes on booting 100% normally as usual.

I also have a desktop pc but I didn't noticed such behaviour on the desktop machine.

Please help me! This "don't know what the machine is doing for one hour at boot" is something i'd gladly leave to windows :P

Thank you very much for your work,
Riccardo.

[Riccardo Lucchese (riccardo.lucchese)]

ps. I won't be able to read my mail in the next 7 days. Sorry.
my laptop is a Fujitsu-Siemens 7425

[Shadows_Friend (shadows-friend)]

Same issue on a Acer Travelmate C200 Notebook. After yesterday's updates boot time increased to an unusual long time.

[Christiansen (happylinux)]

Experiences same problem on IBM Thinkpad. The 7.04 Beta was okay, but after upgrading with the latest updates the issue arrived.

[Shadows_Friend (shadows-friend)]

After I had followed the boot progress in the console I just recognized that the "boot stop" takes place while "Configuring Network Devices". Maybe that's the root of the problem?!

[Christiansen (happylinux)]

Had the same experience as above, following the boot process from the text-console. Disabled both network adapters in BIOS solved the problem, and Kubuntu started with no delay - and off course no network connections either. Enabled the wired adapter first, and the boot delay (approximately 1 minute) was back. Disabled the wired NIC and end enabled the Wireless NIC and got same boot-delay.

[apelete (apelete)]

Exactly same problem here.
Running Feisty Beta with last upgrade (kernel 2.6.20-14) on an AMD Athlon XP 2400+with 1GB RAM.
Boot process hangs for some time at network interfaces configuring stage.

[Nick McMahon (nmcmahon)]

Yep, was about to report this after coming back from holiday :)

Here are boot charts for before and after

[Nick McMahon (nmcmahon)]

(before)

[Shadows_Friend (shadows-friend)]

I found a temporary solution to the bug. The problem seems to be related to a dhcp issue. After I restarted the network devices manually I recognized that the start script waits for a dhcp answer. And it does this very long. If you haven't got a static configuration for your devices you can fix the bug temporarily by commenting out all the devices execpt the loopback device, which is essential, in the /etc/network/interfaces . My file:

auto lo
iface lo inet loopback

#auto eth0
#iface eth0 inet dhcp

#auto eth1
#iface eth1 inet dhcp

#auto eth2
#iface eth2 inet dhcp

#auto ath0
#iface ath0 inet dhcp

#auto wlan0
#iface wlan0 inet dhcp

For me this resolves the problem. But this is just a temporary solution because I don't expect all the future Feisty users with this issue to read this bug report or to be willing to find a solution by themselves...

[Robert Los (robert-robertlos)]

I have the same problem and it seems to be related to adding a drive to a table. I disabled the splash screen at booting and followed the text on screen to see where the boot process times-out. It waits approx 10 minutes at the position below (excerpt from var/log/messages)

jul 20 21:37:20 max-linux kernel: [ 47.937520] input: ImPS/2 Logitech Wheel Mouse as /class/input/input3
Jul 20 21:37:20 max-linux kernel: [ 47.964425] ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 19
Jul 20 21:37:20 max-linux kernel: [ 47.964488] ACPI: PCI Interrupt 0000:02:07.0[A] -> Link [LNKD] -> GSI 19 (level, high) -> IRQ 20
Jul 20 21:37:20 max-linux kernel: [ 48.278784] device-mapper: table: device /dev/mapper/1ATA_WDC_WD2000JD-00GBB0_WD-WMAEP1588874p1 too small for target
Jul 20 21:37:20 max-linux kernel: [ 48.278924] device-mapper: ioctl: error adding target to table
Jul 20 21:37:20 max-linux kernel: [ 48.279721] device-mapper: table: device /dev/mapper/1ATA_WDC_WD2000JD-00GBB0_WD-WMAEP1588874p1 too small for target
Jul 20 21:37:20 max-linux kernel: [ 48.279852] device-mapper: ioctl: error adding target to table
Jul 20 21:37:20 max-linux kernel: [ 227.781290] device-mapper: table: device /dev/mapper/1ATA_WDC_WD2000JD-00GBB0_WD-WMAEP1588874p1 too small for target
Jul 20 21:37:20 max-linux kernel: [ 227.781432] device-mapper: ioctl: error adding target to table
Jul 20 21:37:20 max-linux kernel: [ 227.805638] device-mapper: table: device /dev/mapper/1ATA_WDC_WD2000JD-00GBB0_WD-WMAEP1588874p1 too small for target
Jul 20 21:37:20 max-linux kernel: [ 227.805769] device-mapper: ioctl: error adding target to table
Jul 20 21:37:20 max-linux kernel: [ 246.366164] lp0: using parport0 (interrupt-driven).

the curious thing is that when i boot dapper LTS it does not have a problem. Is there a way to re-initiate the hardware table?