How to diagnose/fix very slow boot on Ubuntu 18.04
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
boot 18.04
add a comment |
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
boot 18.04
3
Is this a fresh install? with lvm? perhaps this bug : bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1768230 ?
– pim
May 2 '18 at 4:53
To see theWARNING:Failed to connect to lvmetad. Falling back to device scanning.
message, you should disable the spash/quiet boot (see : askubuntu.com/a/289/454520)
– pim
May 2 '18 at 5:46
It's about long network.service booting. Solution from this answer helped me.
– gyr9i
Jun 6 '18 at 7:59
add a comment |
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
boot 18.04
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
boot 18.04
boot 18.04
edited Jul 29 '18 at 18:37
wjandrea
9,29842664
9,29842664
asked May 2 '18 at 4:31
user105939user105939
5573719
5573719
3
Is this a fresh install? with lvm? perhaps this bug : bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1768230 ?
– pim
May 2 '18 at 4:53
To see theWARNING:Failed to connect to lvmetad. Falling back to device scanning.
message, you should disable the spash/quiet boot (see : askubuntu.com/a/289/454520)
– pim
May 2 '18 at 5:46
It's about long network.service booting. Solution from this answer helped me.
– gyr9i
Jun 6 '18 at 7:59
add a comment |
3
Is this a fresh install? with lvm? perhaps this bug : bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1768230 ?
– pim
May 2 '18 at 4:53
To see theWARNING:Failed to connect to lvmetad. Falling back to device scanning.
message, you should disable the spash/quiet boot (see : askubuntu.com/a/289/454520)
– pim
May 2 '18 at 5:46
It's about long network.service booting. Solution from this answer helped me.
– gyr9i
Jun 6 '18 at 7:59
3
3
Is this a fresh install? with lvm? perhaps this bug : bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1768230 ?
– pim
May 2 '18 at 4:53
Is this a fresh install? with lvm? perhaps this bug : bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1768230 ?
– pim
May 2 '18 at 4:53
To see the
WARNING:Failed to connect to lvmetad. Falling back to device scanning.
message, you should disable the spash/quiet boot (see : askubuntu.com/a/289/454520)– pim
May 2 '18 at 5:46
To see the
WARNING:Failed to connect to lvmetad. Falling back to device scanning.
message, you should disable the spash/quiet boot (see : askubuntu.com/a/289/454520)– pim
May 2 '18 at 5:46
It's about long network.service booting. Solution from this answer helped me.
– gyr9i
Jun 6 '18 at 7:59
It's about long network.service booting. Solution from this answer helped me.
– gyr9i
Jun 6 '18 at 7:59
add a comment |
5 Answers
5
active
oldest
votes
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:
Edit the file
/etc/default/grub
file so that the stringnoresume
is included in theGRUB_CMDLINE_LINUX_DEFAULT
line, for example:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash noresume"
Run this command to update GRUB:
sudo update-grub
Reboot the computer
1
noresume fixed it, nothing strange in initramfs.
– user105939
May 4 '18 at 7:15
1
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
7
Please note that this is a workaroud, since it will prevent resuming a hibernated system.
– pim
May 9 '18 at 13:52
2
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
add a comment |
$ systemd-analyze blame
Look to see which processes are taking the most time of the boot process.
3
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
1
good hint, but the longest process took only 1.6seconds, so this tool did not help.
– user105939
May 4 '18 at 7:16
1
@Pimsystemd-analyse time
has a typo, it should have az
– RobAu
Nov 20 '18 at 8:18
systemd-analyze critical-chain
is even better thanblame
– user535733
Dec 9 '18 at 22:14
add a comment |
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).
add a comment |
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
add a comment |
Time Start Job and Stop Jobs
∘ "acpi int3400 unsupported event" ERRORS OVER 285 FARG!@#$ING Times
sudo gedit /etc/systemd/system.conf
Change/or Add a Different line that's Uncommented (from 90 seconds to 5 {I Like}) and Uncomment
#DefaultTimeoutStartSec=90s
DefaultTimeoutStartSec=5s
and the other
#DefaultTimeoutStopSec=90s
DefaultTimeoutStopSec=5s
sudo update-initramfs -u
add a comment |
protected by Community♦ Jul 21 '18 at 1:54
Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?
5 Answers
5
active
oldest
votes
5 Answers
5
active
oldest
votes
active
oldest
votes
active
oldest
votes
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:
Edit the file
/etc/default/grub
file so that the stringnoresume
is included in theGRUB_CMDLINE_LINUX_DEFAULT
line, for example:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash noresume"
Run this command to update GRUB:
sudo update-grub
Reboot the computer
1
noresume fixed it, nothing strange in initramfs.
– user105939
May 4 '18 at 7:15
1
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
7
Please note that this is a workaroud, since it will prevent resuming a hibernated system.
– pim
May 9 '18 at 13:52
2
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
add a comment |
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:
Edit the file
/etc/default/grub
file so that the stringnoresume
is included in theGRUB_CMDLINE_LINUX_DEFAULT
line, for example:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash noresume"
Run this command to update GRUB:
sudo update-grub
Reboot the computer
1
noresume fixed it, nothing strange in initramfs.
– user105939
May 4 '18 at 7:15
1
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
7
Please note that this is a workaroud, since it will prevent resuming a hibernated system.
– pim
May 9 '18 at 13:52
2
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
add a comment |
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:
Edit the file
/etc/default/grub
file so that the stringnoresume
is included in theGRUB_CMDLINE_LINUX_DEFAULT
line, for example:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash noresume"
Run this command to update GRUB:
sudo update-grub
Reboot the computer
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:
Edit the file
/etc/default/grub
file so that the stringnoresume
is included in theGRUB_CMDLINE_LINUX_DEFAULT
line, for example:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash noresume"
Run this command to update GRUB:
sudo update-grub
Reboot the computer
edited May 9 '18 at 15:24
Zanna
50.9k13137241
50.9k13137241
answered May 3 '18 at 18:08
ClifforusClifforus
63622
63622
1
noresume fixed it, nothing strange in initramfs.
– user105939
May 4 '18 at 7:15
1
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
7
Please note that this is a workaroud, since it will prevent resuming a hibernated system.
– pim
May 9 '18 at 13:52
2
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
add a comment |
1
noresume fixed it, nothing strange in initramfs.
– user105939
May 4 '18 at 7:15
1
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
7
Please note that this is a workaroud, since it will prevent resuming a hibernated system.
– pim
May 9 '18 at 13:52
2
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
1
1
noresume fixed it, nothing strange in initramfs.
– user105939
May 4 '18 at 7:15
noresume fixed it, nothing strange in initramfs.
– user105939
May 4 '18 at 7:15
1
1
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
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
1
You could improve your already good answer with instructions on updating grub.
– WinEunuuchs2Unix
May 9 '18 at 0:44
You could improve your already good answer with instructions on updating grub.
– WinEunuuchs2Unix
May 9 '18 at 0:44
7
7
Please note that this is a workaroud, since it will prevent resuming a hibernated system.
– pim
May 9 '18 at 13:52
Please note that this is a workaroud, since it will prevent resuming a hibernated system.
– pim
May 9 '18 at 13:52
2
2
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
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
add a comment |
$ systemd-analyze blame
Look to see which processes are taking the most time of the boot process.
3
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
1
good hint, but the longest process took only 1.6seconds, so this tool did not help.
– user105939
May 4 '18 at 7:16
1
@Pimsystemd-analyse time
has a typo, it should have az
– RobAu
Nov 20 '18 at 8:18
systemd-analyze critical-chain
is even better thanblame
– user535733
Dec 9 '18 at 22:14
add a comment |
$ systemd-analyze blame
Look to see which processes are taking the most time of the boot process.
3
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
1
good hint, but the longest process took only 1.6seconds, so this tool did not help.
– user105939
May 4 '18 at 7:16
1
@Pimsystemd-analyse time
has a typo, it should have az
– RobAu
Nov 20 '18 at 8:18
systemd-analyze critical-chain
is even better thanblame
– user535733
Dec 9 '18 at 22:14
add a comment |
$ systemd-analyze blame
Look to see which processes are taking the most time of the boot process.
$ systemd-analyze blame
Look to see which processes are taking the most time of the boot process.
edited May 2 '18 at 22:47
ubashu
2,39121837
2,39121837
answered May 2 '18 at 5:24
ManojManoj
1835
1835
3
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
1
good hint, but the longest process took only 1.6seconds, so this tool did not help.
– user105939
May 4 '18 at 7:16
1
@Pimsystemd-analyse time
has a typo, it should have az
– RobAu
Nov 20 '18 at 8:18
systemd-analyze critical-chain
is even better thanblame
– user535733
Dec 9 '18 at 22:14
add a comment |
3
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
1
good hint, but the longest process took only 1.6seconds, so this tool did not help.
– user105939
May 4 '18 at 7:16
1
@Pimsystemd-analyse time
has a typo, it should have az
– RobAu
Nov 20 '18 at 8:18
systemd-analyze critical-chain
is even better thanblame
– user535733
Dec 9 '18 at 22:14
3
3
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
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
1
1
good hint, but the longest process took only 1.6seconds, so this tool did not help.
– user105939
May 4 '18 at 7:16
good hint, but the longest process took only 1.6seconds, so this tool did not help.
– user105939
May 4 '18 at 7:16
1
1
@Pim
systemd-analyse time
has a typo, it should have a z
– RobAu
Nov 20 '18 at 8:18
@Pim
systemd-analyse time
has a typo, it should have a z
– RobAu
Nov 20 '18 at 8:18
systemd-analyze critical-chain
is even better than blame
– user535733
Dec 9 '18 at 22:14
systemd-analyze critical-chain
is even better than blame
– user535733
Dec 9 '18 at 22:14
add a comment |
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).
add a comment |
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).
add a comment |
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).
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).
edited May 15 '18 at 6:26
ubashu
2,39121837
2,39121837
answered May 15 '18 at 6:17
user7081858user7081858
991
991
add a comment |
add a comment |
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
add a comment |
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
add a comment |
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
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
edited Jul 7 '18 at 19:49
lrkwz
165115
165115
answered May 10 '18 at 6:22
krigekrige
785
785
add a comment |
add a comment |
Time Start Job and Stop Jobs
∘ "acpi int3400 unsupported event" ERRORS OVER 285 FARG!@#$ING Times
sudo gedit /etc/systemd/system.conf
Change/or Add a Different line that's Uncommented (from 90 seconds to 5 {I Like}) and Uncomment
#DefaultTimeoutStartSec=90s
DefaultTimeoutStartSec=5s
and the other
#DefaultTimeoutStopSec=90s
DefaultTimeoutStopSec=5s
sudo update-initramfs -u
add a comment |
Time Start Job and Stop Jobs
∘ "acpi int3400 unsupported event" ERRORS OVER 285 FARG!@#$ING Times
sudo gedit /etc/systemd/system.conf
Change/or Add a Different line that's Uncommented (from 90 seconds to 5 {I Like}) and Uncomment
#DefaultTimeoutStartSec=90s
DefaultTimeoutStartSec=5s
and the other
#DefaultTimeoutStopSec=90s
DefaultTimeoutStopSec=5s
sudo update-initramfs -u
add a comment |
Time Start Job and Stop Jobs
∘ "acpi int3400 unsupported event" ERRORS OVER 285 FARG!@#$ING Times
sudo gedit /etc/systemd/system.conf
Change/or Add a Different line that's Uncommented (from 90 seconds to 5 {I Like}) and Uncomment
#DefaultTimeoutStartSec=90s
DefaultTimeoutStartSec=5s
and the other
#DefaultTimeoutStopSec=90s
DefaultTimeoutStopSec=5s
sudo update-initramfs -u
Time Start Job and Stop Jobs
∘ "acpi int3400 unsupported event" ERRORS OVER 285 FARG!@#$ING Times
sudo gedit /etc/systemd/system.conf
Change/or Add a Different line that's Uncommented (from 90 seconds to 5 {I Like}) and Uncomment
#DefaultTimeoutStartSec=90s
DefaultTimeoutStartSec=5s
and the other
#DefaultTimeoutStopSec=90s
DefaultTimeoutStopSec=5s
sudo update-initramfs -u
answered Jan 27 at 17:33
markackerman8-gmail.commarkackerman8-gmail.com
787612
787612
add a comment |
add a comment |
protected by Community♦ Jul 21 '18 at 1:54
Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?
3
Is this a fresh install? with lvm? perhaps this bug : bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1768230 ?
– pim
May 2 '18 at 4:53
To see the
WARNING:Failed to connect to lvmetad. Falling back to device scanning.
message, you should disable the spash/quiet boot (see : askubuntu.com/a/289/454520)– pim
May 2 '18 at 5:46
It's about long network.service booting. Solution from this answer helped me.
– gyr9i
Jun 6 '18 at 7:59