56

There is a long time where SSD does nothing.

  • How can I find the fault and fix it ?
  • Already checked /etc/fstab, no swap or anything wrong there (32GB of RAM, no swap)

[    2.173492] usb 2-1.6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[    2.173497] usb 2-1.6: Product: DW375 Bluetooth Module
[    2.173501] usb 2-1.6: Manufacturer: Dell Computer Corp
[    2.173511] usb 2-1.6: SerialNumber: 7CE9D3C0713B
[    2.323728] ata4: SATA link down (SStatus 0 SControl 300)
[    2.441062] input: AlpsPS/2 ALPS GlidePoint as /devices/platform/i8042/serio1/input/input6
[    2.640309] ata5: SATA link down (SStatus 0 SControl 300)
[    2.954947] ata6: SATA link down (SStatus 0 SControl 300)
[    3.068090] clocksource: Switched to clocksource tsc
[   36.584826] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)
[   36.726117] ip_tables: (C) 2000-2006 Netfilter Core Team
[   36.732610] systemd[1]: systemd 237 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +AC
L +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid)
[   36.751996] systemd[1]: Detected architecture x86-64.
[   36.753867] systemd[1]: Set hostname to <latitude-e5520>.
[   36.868561] systemd[1]: Started Forward Password Requests to Wall Directory Watch.
[   36.868594] systemd[1]: Reached target Remote File Systems.
[   36.868751] systemd[1]: Created slice User and Session Slice.
[   36.868869] systemd[1]: Created slice System Slice.
[   36.868948] systemd[1]: Listening on udev Control Socket.
[   36.868957] systemd[1]: Reached target Slices.
[   36.868996] systemd[1]: Listening on udev Kernel Socket.
[   36.895156] EXT4-fs (sda1): re-mounted. Opts: errors=remount-ro
[   36.898185] lp: driver loaded but no devices found
[   36.903941] ppdev: user-space parallel port driver
70

I upgraded to 18.04 today and encountered the same issue. I was able to fix it by booting the kernel with the noresume parameter.

Like you, I also have no swap space. At some point during the upgrade, the initramfs config was modified, adding a line pointing to a nonexistent swap partition. The slow boot was because it was looking for this partition and then timing out after 30 seconds.

To update GRUB so that it passes this option to the kernel automatically on boot:

  1. Edit the file /etc/default/grub file so that the string noresume is included in the GRUB_CMDLINE_LINUX_DEFAULT line, for example:

    GRUB_CMDLINE_LINUX_DEFAULT="quiet splash noresume"
    
  2. Run this command to update GRUB:

    sudo update-grub
    
  3. Reboot the computer

| improve this answer | |
  • 2
    noresume fixed it, nothing strange in initramfs. – user105939 May 4 '18 at 7:15
  • 2
    I upgraded to 18.04 yesterday and I had the same problem (it took 52 seconds to boot). After setting the "noresume" parameter, it took 21 seconds. – Erol May 4 '18 at 15:06
  • 1
    You could improve your already good answer with instructions on updating grub. – WinEunuuchs2Unix May 9 '18 at 0:44
  • 11
    Please note that this is a workaroud, since it will prevent resuming a hibernated system. – pim May 9 '18 at 13:52
  • 3
    I'm worried that this might prevent me from using hibernation. However this worked for me: askubuntu.com/questions/1013830/… (editing /etc/initramfs-tools/conf.d/resume, changing RESUME=none from the UUID and running update-initramfs -u) – Grey Panther Jul 11 '18 at 20:33
24
$ systemd-analyze blame

Look to see which processes are taking the most time of the boot process.

| improve this answer | |
  • 9
    systemd-analyze blame will not show kernel time, and for this problem. systemd-analyse time will show that it's the kernel that is stuck searching for the filesystem. – pim May 2 '18 at 5:36
  • 2
    good hint, but the longest process took only 1.6seconds, so this tool did not help. – user105939 May 4 '18 at 7:16
  • 4
    @Pim systemd-analyse time has a typo, it should have a z – RobAu Nov 20 '18 at 8:18
  • 1
    systemd-analyze critical-chain is even better than blame – user535733 Dec 9 '18 at 22:14
  • below is the output for blame...now how do i improve the time runs of the longest running jobs ??systemd-analyze blame 22.866s systemd-journal-flush.service 22.844s dev-sda1.device 16.689s ufw.service 16.041s systemd-modules-load.service 15.367s keyboard-setup.service 13.714s systemd-tmpfiles-setup-dev.service 9.229s NetworkManager-wait-online.service 7.599s snapd.service rest are lesser than 6 seconds. pls guide, i'm a newbie – EetSandhu Mar 7 at 5:27
14

What worked for me was to run sudo rm /etc/initramfs-tools/conf.d/resume followed by sudo update-initramfs -u . This seems to be a regression from an upgrade (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861151).

| improve this answer | |
  • Worked great. Seems cleaner to me than adding the "noresume" kernel argument to GRUB (which also worked). – hackerb9 May 18 at 5:55
8

I upgraded to 18.04 from 16.04. Boot time was more than 10 minutes.
Tried from "No splash screen to Kernel" to find which processes are taking the most time for booting.

A start job is running for Raise network interfaces (1min 26s / 5min 24s)

So, we need to reduce time for this process to save boot time. To do so,

You have to edit,

sudo nano /etc/systemd/system/network-online.target.wants/networking.service

Find

TimeoutStartSec=5min

Change to

TimeoutStartSec=5s

and reboot

| improve this answer | |
  • This is where my boot was burning a lot of time, so this solution worked for me. +1 – Gnawme Nov 13 '19 at 0:42
  • It was my case... Just I had to insert the line in /etc/systemd/system/network-online.target.wants/NetworkManager-wait-online.service file, under [Service] because it wasn't already there. I'm on Lubuntu 20.04. thank you – Funder Aug 21 at 12:23
6

You can configure the timeout for Start Job and Stop Jobs.

Edit /etc/systemd/system.conf with elevated privileges and change/add two lines that are commented by default from 90 seconds to 5 (or whatever you prefer) and uncomment it:

from:

#DefaultTimeoutStartSec=90s
#DefaultTimeoutStopSec=90s 

to:

DefaultTimeoutStartSec=5s
DefaultTimeoutStopSec=5s

After that, apply the changes by rebuilding your initramfs with the command:

sudo update-initramfs -u
| improve this answer | |
  • this solved my problem after doing Gparted repartition operations on SSD drive which took notably longer boot time otherwise. – doctorate Mar 6 at 9:24
0

I tried a different method but nothing it worked. then I find it was the graphics driver issue. I solved by using additional drivers for me it was Nvidia.

goto: software & updates -> choose listed graphics driver -> apply changes

Note: I am using kernel version 4.18.0-25-generic

| improve this answer | |

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