[SOLVED] Super slow boot after third OS install
by thelynx from LinuxQuestions.org on (#4VGH8)
I'm posting this here because I couldn't find Pop!OS in the list of distros. Since it's based on Ubuntu, I thought this would be the best option.
I have a dual boot system on an Acer Swift3 (SSD -- nvm) with AntiX on one partition and Pop!OS on another. A few days ago, I wanted to install Slackware on a third partition. I did so. The first bootloader is AntiX so I updated grub and Slackware was found without a problem and it booted. In order to boot into Pop!, since Pop! doesn't use grub, I always pressed F12 upon powering on to get to Bios bootloader and upon clicking, the system would load in literally ten seconds. However, ever since I did my experiment with Slackware (I have since deleted Slackware and formatted the partition as a Backup), Pop!OS boots painfully slow. It takes 1min 39 seconds in fact from boot to seeing the log in screen. That's a gargantuan difference from before. Please note that I am currently running the latest 19.10 having updated after all this happened.
I've searched online for solutions and will post some relevant info below in the hopes someone can shed light on this:
Code:systemd-analyze blame
6.001s NetworkManager-wait-online.service
5.240s fwupd.service
5.197s plymouth-quit-wait.service
5.043s bolt.service
2.391s e2scrub_reap.service
1.209s dev-nvme0n1p3.device
765ms systemd-logind.service
634ms accounts-daemon.service
465ms upower.service
406ms networkd-dispatcher.service
371ms systemd-resolved.service
369ms udisks2.service
344ms systemd-hwdb-update.service
341ms systemd-timesyncd.service
306ms systemd-journald.service
288ms snapd.service
270ms systemd-rfkill.service
268ms ModemManager.service
255ms gpu-manager.service
149ms bluetooth.service
140ms keyboard-setup.service
139ms systemd-udev-trigger.service
132ms systemd-journal-flush.service
No helpful info there, so I then ran:
Code: systemd-analyze critical-chain
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.
graphical.target @1min 36.615s
a""a"multi-user.target @1min 36.615s
a""a"avahi-daemon.service @1min 36.673s +13ms
a""a"basic.target @1min 30.268s
a""a"sockets.target @1min 30.268s
a""a"snapd.socket @1min 30.261s +6ms
a""a"sysinit.target @1min 30.259s
a""a"systemd-timesyncd.service @1.604s +341ms
a""a"systemd-tmpfiles-setup.service @1.583s +18ms
a""a"local-fs.target @1.582s
a""a"run-user-1000-doc.mount @1min 42.924s
a""a"run-user-1000.mount @1min 41.210s
a""a"local-fs-pre.target @394ms
a""a"keyboard-setup.service @252ms +140ms
a""a"systemd-journald.socket @243ms
a""a"-.mount @240ms
a""a"systemd-journald.socket @243ms
a""a"...
I then used "plot" and ran Code:systemd-analyze plot > blame2.svg, but unfortunately I can't upload that type of file here. I found out that dev-fuse.device under user-1000.slice is what is taking up so much time. In fact, the red line goes off the chart! It doesn't even give me the number of seconds! Following that, fuwp.service and bolt.service take 5 seconds each, NetworkManager-wait-online.service takes 6 seconds and plymouth-quit-wait.service takes an additional 4 seconds.
Bottom line is that it seems dev-fuse.device is the culprit, but I have no idea how to fix this issue and I've not been able to find a solution online for this.
Thank you in advance for any suggestions.
I have a dual boot system on an Acer Swift3 (SSD -- nvm) with AntiX on one partition and Pop!OS on another. A few days ago, I wanted to install Slackware on a third partition. I did so. The first bootloader is AntiX so I updated grub and Slackware was found without a problem and it booted. In order to boot into Pop!, since Pop! doesn't use grub, I always pressed F12 upon powering on to get to Bios bootloader and upon clicking, the system would load in literally ten seconds. However, ever since I did my experiment with Slackware (I have since deleted Slackware and formatted the partition as a Backup), Pop!OS boots painfully slow. It takes 1min 39 seconds in fact from boot to seeing the log in screen. That's a gargantuan difference from before. Please note that I am currently running the latest 19.10 having updated after all this happened.
I've searched online for solutions and will post some relevant info below in the hopes someone can shed light on this:
Code:systemd-analyze blame
6.001s NetworkManager-wait-online.service
5.240s fwupd.service
5.197s plymouth-quit-wait.service
5.043s bolt.service
2.391s e2scrub_reap.service
1.209s dev-nvme0n1p3.device
765ms systemd-logind.service
634ms accounts-daemon.service
465ms upower.service
406ms networkd-dispatcher.service
371ms systemd-resolved.service
369ms udisks2.service
344ms systemd-hwdb-update.service
341ms systemd-timesyncd.service
306ms systemd-journald.service
288ms snapd.service
270ms systemd-rfkill.service
268ms ModemManager.service
255ms gpu-manager.service
149ms bluetooth.service
140ms keyboard-setup.service
139ms systemd-udev-trigger.service
132ms systemd-journal-flush.service
No helpful info there, so I then ran:
Code: systemd-analyze critical-chain
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.
graphical.target @1min 36.615s
a""a"multi-user.target @1min 36.615s
a""a"avahi-daemon.service @1min 36.673s +13ms
a""a"basic.target @1min 30.268s
a""a"sockets.target @1min 30.268s
a""a"snapd.socket @1min 30.261s +6ms
a""a"sysinit.target @1min 30.259s
a""a"systemd-timesyncd.service @1.604s +341ms
a""a"systemd-tmpfiles-setup.service @1.583s +18ms
a""a"local-fs.target @1.582s
a""a"run-user-1000-doc.mount @1min 42.924s
a""a"run-user-1000.mount @1min 41.210s
a""a"local-fs-pre.target @394ms
a""a"keyboard-setup.service @252ms +140ms
a""a"systemd-journald.socket @243ms
a""a"-.mount @240ms
a""a"systemd-journald.socket @243ms
a""a"...
I then used "plot" and ran Code:systemd-analyze plot > blame2.svg, but unfortunately I can't upload that type of file here. I found out that dev-fuse.device under user-1000.slice is what is taking up so much time. In fact, the red line goes off the chart! It doesn't even give me the number of seconds! Following that, fuwp.service and bolt.service take 5 seconds each, NetworkManager-wait-online.service takes 6 seconds and plymouth-quit-wait.service takes an additional 4 seconds.
Bottom line is that it seems dev-fuse.device is the culprit, but I have no idea how to fix this issue and I've not been able to find a solution online for this.
Thank you in advance for any suggestions.