0

I've Ubuntu 18.04 installed on Dell Latitude E6320 (on Kingstone SSD), It used to boot in about 14 - 18 sec, but about three days ago the system started to take a lot of time to boot and in general slow performance.

systemd-analyze outputs

Startup finished in 7.782s (kernel) + 42.572s (userspace) = 50.354s
graphical.target reached after 42.544s in userspace

(I'm on EFI).

The actual boot time is about 2 min from grub screen until the Plymouth screen and then another 30s until the login screen shows up.

What caused the problem?

I did a usual software update and it included a kernel upgrade to 5.0.0-36-generic. restarted the system and the problem started.

What I've tried.

  • Tried to boot with the previous kernel (5.0.0.32) but nothing happened (grub hangs at loading initial ramdisk then shows Plymouth screen)
  • Removed swap 'file' and updated fstab to not include it
  • Added noresume option to GRUB_CMDLINE_LINUX_DEFAULT etc/default/grub/
  • Tried the solution listed here (Slow boot, long kernel load time, due to wrong resume device) Actually I didn't have /etc/initramfs-tools/conf.d/resume file so i created one.

System specification

  • Dell Latitude E6320 with the latest BIOS update.
  • Dual-booting Ubuntu 18.04 on SSD, and Windows 10 on completely separate HDD. both using EFI (Tried to boot with the HDD removed, nothing.)

It's not the first time I face this problem. I was using Kubuntu and the same problem happened but with 8 min boot time so I did a clean EFI install of Ubuntu (about a month ago) and achieved 14sec boot time.

I've noticed performance drop especially when it comes to reading or writing from the SSD. Even typing clare or any wrong command in the terminal takes a bit of time to be recognized as an unknown command.

Additional troubleshooting

The output of dmesg -k can be found here.

Update 1

systemd-analye blame output

systemd-analyze critical-chain output

Abdulhamid Zoubi
  • 1
  • Please edit/add the output of systemd-analyze critical-chain and systemd-analyze blame - First suggestion: clear the journal log with sudo journalctl --rotate; journalctl --vacuum-time=1s – cmak.fr Nov 21 '19 at 03:53
  • Thank you or your quick response, I edited the question.. I tried the command you mention with sudo privileges but it outputs Failed to delete archived journal /var/log/journal/.... .journal: Permission denied – Abdulhamid Zoubi Nov 21 '19 at 09:05
  • Yep, sorry : sudo journalctl --rotate; sudo journalctl --vacuum-time=1s – cmak.fr Nov 21 '19 at 10:06
  • (I forgot the second command's sudo sorry). executed the command successfully and about 2.1GB of logs were freed. the problem isn't solved, unfortunately. – Abdulhamid Zoubi Nov 21 '19 at 11:07
  • please paste the full output of systemd-analyze critical-chain as text, no picture, you can use a temp txt file systemd-analyze critical-chain > out.txt – cmak.fr Nov 21 '19 at 14:40
  • You can use: systemd-analyze blame to show how long each process takes from longest to shortest. This is better than timestamps and you only need to look at the first few lines to see what is taking so long. – mchid Nov 21 '19 at 14:52
  • I'm aware of that the screenshot actually contains the full output of the systemd-analyze critical-chain i used a picture to show the red lines. – Abdulhamid Zoubi Nov 21 '19 at 16:39
  • systemd-analyze in general doesn't help that much, I think the problem is related to the last line in dmesg output ([ 53.501883] rfkill: input handler disabled) – Abdulhamid Zoubi Nov 21 '19 at 16:47

0 Answers0