Forgive me, I just installed Ubuntu yesterday and am trying to learn as quickly as I can.

I cannot figure out why the boot, restart, and shutdown takes so long, from the info below I can see where the issue is happening but I do not know how to fix it. I also understand that boot, restart and shutdown could be separate issues and if so prefer to start with startup / reboot (I think they are related).

Every time I start my computer or reboot my computer the kernel takes over 90 seconds to load (sitting at black screen while waiting).

Thank you for any and all help you can provide.

FYI, I have loaded Zorin OS 9 without any issues but this is using an older version of Ubuntu (14.04 LTS) and I want to use the latest.

System Info:

  • Intel I7-3770K
  • AMD Radeon R9 290x
  • 32 GB Ram
  • Samsung SSD as primary (grub installed here)
  • WD HDD 7200rpm as my swap and root for ubuntu.
  • Ubuntu 16.04.1 LTS 64 bit, Updated.

Grub is installed on my primary drive while ubuntu is on /dev/sdb3 (3rd drive in my system)

I have tried booting with nomodeset and this does not help at all.

EDIT: Additional info - I am using UEFI 64 bit version of Ubuntu. I also have an overclock set in my bios. I have tried adding parameters to my kernel either I am not doing it correctly or it has no effect. I have also tried unplugging every usb device from my computer including my keyboard and mouse (used a ps2 keyboard) and issue remained.

EDIT 2: I have done some additional testing:

I have unplugged every usb header, unplugged all HDD and the issue still happens (even with live usb).

I have this motherboard:


I am thinking it has to be something with the motherboard, perhaps the secondary SATA controller?

Anyone have any suggestions?

Image of the analyze plot: Ubuntu 16.04.1 LTS systemd-analyze plot

dmesg (Boot example 1)

[    2.135850] sd 10:0:0:0: [sdd] 976754645 4096-byte logical blocks: (4.00 TB/3.64 TiB)
[    2.136168] sd 10:0:0:0: [sdd] Write Protect is off
[    2.136170] sd 10:0:0:0: [sdd] Mode Sense: 4f 00 00 00
[    2.136327] sd 10:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    2.137493]  sdd: sdd1
[    2.138193] sd 10:0:0:0: [sdd] Attached SCSI disk
[    2.627661] clocksource: Switched to clocksource tsc
[   91.393716] random: nonblocking pool is initialized
[   91.478893] EXT4-fs (sdb3): mounted filesystem with ordered data mode. Opts: (null)
[   92.052207] systemd[1]: systemd 229 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN)
[   92.052306] systemd[1]: Detected architecture x86-64.
[   92.064886] systemd[1]: Set hostname to <AntUbuntu>.
[   92.298399] systemd[1]: Listening on udev Kernel Socket.
[   92.298491] systemd[1]: Set up automount Arbitrary Executable File Formats File System Automount Point.
[   92.298499] systemd[1]: Reached target Remote File Systems (Pre).

dmesg (Boot example 2)

[    4.297400] sd 10:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    4.298509]  sdd: sdd1
[    4.299195] sd 10:0:0:0: [sdd] Attached SCSI disk
[    4.393421] random: nonblocking pool is initialized
[   91.502212] EXT4-fs (sdb3): mounted filesystem with ordered data mode. Opts: (null)
[   92.075578] systemd[1]: systemd 229 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN)
[   92.075677] systemd[1]: Detected architecture x86-64.
[   92.088193] systemd[1]: Set hostname to <AntUbuntu>.
[   92.337609] systemd[1]: Listening on udev Control Socket.
[   92.337646] systemd[1]: Listening on udev Kernel Socket.
[   92.337659] systemd[1]: Listening on fsck to fsckd communication Socket.
[   92.337709] systemd[1]: Created slice System Slice.

systemd-analyze blame:

  6.233s lightdm.service
  5.922s snapd.refresh.service
  4.198s plymouth-quit-wait.service
  3.095s dev-sdb3.device
  2.376s NetworkManager.service
  1.961s ModemManager.service
  1.959s thermald.service
  1.945s accounts-daemon.service
  1.773s apparmor.service
  1.441s polkitd.service
  1.114s plymouth-start.service
  1.094s systemd-tmpfiles-setup.service
  1.033s apport.service
  1.004s grub-common.service
   868ms networking.service
   856ms systemd-journal-flush.service
   721ms gpu-manager.service
   695ms rsyslog.service
   642ms systemd-fsck@dev-disk-by\x2duuid-1EEB\x2dDE91.service
   571ms systemd-tmpfiles-setup-dev.service
   558ms console-setup.service
   509ms keyboard-setup.service
   495ms upower.service
  • The link to your systemd-analyze plot is broken. Please edit your question and repair it so that you have a better chance of being answered. Thank you for helping us help you! – Elder Geek Aug 28 '16 at 17:06

So let me get this straight. This is a 2 disk installation and you have the boot and root on seperate disks?

Have you thought about maybe putting the root boot and swap partitions on the ssd and using the HDD to serve data? Something like mounting the HDD to /srv.

I run this setup using a thumb drive as root boot home and swap and 2 hdds mounted to /srv and /mnt containing my virtual machine images and the data they serve. Boot time is <60 seconds

  • Thank you for the reply. The grub is installed to my Windows drive. Root(and rest of what ubuntu installs) and swap are on another drive. I have tried unplugging all my hard disks, just using live usb and the hang still happened at the same spot leading me to believe it is my motherboard. – Anthony Sep 3 '16 at 19:20

The 90 second delay is caused by a network interface naming conflict that happens due to a flaw in the BIOS of your motherboard. Some Intel motherboards with multiple integrated NICs have this problem. Two motherboards that I know of are the Intel DZ77GA-70K (your case) and the DZ77RE-75K (mine.)

Note that there are a number of failure modes that will cause a long delay during boot leading to wasted effort while seeking solutions. This specific case is related to network interface conflicts and can be detected by running the following command described here: https://bugzilla.redhat.com/show_bug.cgi?id=1102135

$ sudo grep . /sys/class/net/*/device/{index,acpi_index}
grep: /sys/class/net/*/device/acpi_index: No such file or directory

The two network devices have the same "index" value 1 and the ACPI index values are missing. There should be distinct APCI index values assigned by the BIOS. Due to these conflicting values the "Predictable Network Interface Name" policy (https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames) that appeared in udev v197 causes the network interfaces to somehow not initialize properly on boot and a 90 second timeout is observed.

Another way to detect this is to apply the "debug ignore_loglevel" arguments to the kernel command line. With these arguments in place during boot (and also in dmesg output) you will see a message after 60 seconds from systemd-udevd that some network interface is "taking a long time."

systemd-udevd[447]: seq 2024 '/devices/pci0000:00/...' is taking a long time

There are several ways to work around this problem. They are documented on the freedesktop.org link above. The relevant part is quoted here:

  1. You disable the assignment of fixed names, so that the unpredictable kernel names are used again. For this, simply mask udev's .link file for the default policy: ln -s /dev/null /etc/systemd/network/99-default.link

  2. You create your own manual naming scheme, for example by naming your interfaces "internet0", "dmz0" or "lan0". For that create your own .link files in /etc/systemd/network/, that choose an explicit name or a better naming scheme for one, some, or all of your interfaces. See systemd.link(5) for more information.

  3. You pass the net.ifnames=0 on the kernel command line

Speculation: these Z77 boards from Intel appeared just before Intel exited the desktop motherboard business in 2013. The boards never had the benefit of ongoing BIOS updates that might have corrected these issues. The boards work but there are some glitches, another being the USB "over-current" errors that happen on boot in both Linux and Windows despite there being no USB devices drawing current.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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