Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

So I've insalled Ubuntu 12.10 from a usb stick alongside with Windows. When I boot Ubuntu, it spends about 10 minutes in a purple screen, no cursor, no nothing, then it goes to a black screen but with a cursor, and lastly the login screen, which stays frozen for like 10 minutes. After I login, the screen stays frozen on an empty wallpaper for 10 minutes aswell. Finally after Ubuntu boots, everything runs ultra slowly. Firefox takes a few minutes to launch and freezes every like 10 seconds. Ive got an Intel Pentium 2.93 Ghz dual core processor, 4 Gigs of ram, Geforce GTS250.

share|improve this question
    
Open a terminal and write $ gksu gedit /etc/default/grub Remove splash and quiet from GRUB_CMDLINE_LINUX_DEFAULT. Then reboot, you should get some more information. –  Frederik Spang Mar 26 '13 at 16:09
    
Run the command dmesg > ~/dmesg.txt and post the contents of the file dmesg.txt in your home directory. This will show what is happening during boot. –  tgies Mar 26 '13 at 16:10
    
@tgies Heres the dmesg.txt Pastebin link –  Fred. Mar 26 '13 at 17:15
    
Ubuntu seems to have some issues with file systems and a usb-device. Does disconnecting all USB devices make it boot faster? –  FSMaxB Mar 26 '13 at 19:34
    
@Fred. Thank you! I've posted an answer below that explains how to read dmesg output, as well as a probable solution to your specific output. –  tgies Mar 26 '13 at 23:17
show 1 more comment

1 Answer

The first step in diagnosing a slow boot is to look at the output of dmesg. dmesg displays the contents of the kernel ring buffer, which contains status messages logged by the kernel more or less from the moment control is passed to the Linux kernel to the point that your syslog daemon takes over those logging duties.

To get the output of dmesg in a file for easy browsing, do dmesg > dmesg.txt. Now dmesg.txt in your current directory contains the kernel log.

Reading dmesg: Every line of dmesg output starts with a sequence like [ 0.106607]. This is a timestamp in "T-plus" format: it is the number of seconds since the instant the kernel started.

To identify your slowdown, look for a point where the timestamp "jumps" a great deal from one line to the next (hint: you can also use dmesg -d to get dmesg to print the time difference from one timestamp to the next in angle brackets after the timestamp):

[    3.201806] usb 2-4: >New USB device strings: Mfr=2, Product=3, SerialNumber=4
[    3.201810] usb 2-4: >Product: Android
[    3.201813] usb 2-4: >Manufacturer: Android
[    3.201816] usb 2-4: >SerialNumber: 00093f054d0a2f
[   43.254818] EXT4-fs (sda5): orphan cleanup on readonly fs
[   43.254827] EXT4-fs (sda5): ext4_orphan_cleanup: deleting unreferenced inode 10747985
[   43.254879] EXT4-fs (sda5): ext4_orphan_cleanup: deleting unreferenced inode 10748275
[   43.254892] EXT4-fs (sda5): ext4_orphan_cleanup: deleting unreferenced inode 10748394

Here we see a jump from T+3 seconds to T+43 seconds, meaning that for 40 seconds the kernel was logging nothing, and presumably twiddling its thumbs waiting for something to happen. This is right after it's recognized an Android device plugged in, so for starters, we might want to try having that Android device unplugged during boot. That could be a red herring, though -- the delay might be incurred by the filesystem cleanup that is happening next.

This is followed shortly by:

[   43.254959] EXT4-fs (sda5): ext4_orphan_cleanup: deleting unreferenced inode 10748175
[   43.254969] EXT4-fs (sda5): 8 orphan inodes deleted
[   43.254970] EXT4-fs (sda5): recovery complete
[   52.161162] EXT4-fs (sda5): mounted filesystem with ordered data mode. Opts: (null)
[  451.530476] Adding 51097596k swap on /dev/sda2.  Priority:-1 extents:1 across:51097596k
[  451.540572] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[  455.117113] udevd[430]: starting version 175
[  458.734692] lp: driver loaded but no devices found

Wow, a gap from T+52 seconds to T+451 seconds. We notice that the last thing that happens prior to the delay is the filesystem being mounted.

A little research (doing a Google search for 'slow boot dmesg "mounted filesystem with ordered data mode"') yields a promising lead: an unfixed bug pertaining to udev that refers to a long wait at boot right after this message!

Browsing that thread, it looks like a workaround has been established:

It consists in adding a --noudevsync parameter to the vgchange command in /lib/udev/rules.d/85-lvm2.rules. Then regenerating the initramfs with update-initramfs -u

So we'll do something like this:

sudo nano /lib/udev/rules.d/85-lvm2.rules

Find the excerpt that looks like /sbin/lvm vgchange -a y and change it to read /sbin/lvm vgchange --noudevsync -a y. It may be necessary to append the same option to the /sbin/lvm vgscan call.

Now do sudo update-initramfs -u and reboot when it is successful.

share|improve this answer
    
Use the profile parameter on boot too? ubuntubuzz.com/2012/01/… –  Frederik Spang Mar 27 '13 at 7:23
    
@FrederikSpang That's not really going to fix this problem (and in any case that blog is giving bad advice -- you shouldn't make profile a permanent fixture of your kernel command line unless you'd like it to boot far slower; just hit e at GRUB, append profile to the kernel command line after quiet splash, and hit Ctrl-x. –  tgies Mar 27 '13 at 13:30
    
The article states, to profile it once, and then remove the parameter again. –  Frederik Spang Mar 27 '13 at 16:05
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.