I'm using Neon User Edition Bionic testing. It takes a long time to start up. The first test was to use systemd-analyze

Code: Select all

$ systemd-analyze     
Startup finished in 14.815s (firmware) + 10.384s (loader) + 3.707s (kernel) + 23.984s (userspace) = 52.892s

Code: Select all

$ systemd-analyze blame
        15.929s apt-daily.service
        6.205s NetworkManager-wait-online.service
        810ms dev-nvme0n1p2.device
        634ms motd-news.service
        ...

I'm running it on a 3GB/s NVMe SSD and my other hardware in my desktop is fairly high end. Loading should be fast but it still takes a lot time for me to get to the desktop. NetworkManager I understand, that's because I have my NAS mounted. apt-daily may or may not be blocking startup according to a discussion here https://bugs.debian.org/cgi-bin/bugrepo ... bug=844453

I'm not sure where to go from here.

There's still 15 seconds of firmware loading, 10 seconds of "loader" loading, whatever that is. How can I drill down the cause of my long start up times? I don't recall any other ubuntu-based distro taking this long to start up. What else can I check?

Thanks

I reported the same problem on September 8, 2018!

Sat Sep 08, 2018 3:25 pm
I just noticed something new. I installed Binoic on my second hard drive, and I'm noticing a much longer boot time. KDE neon 16.04 xenial 5.13 takes about 14 seconds to boot up. As my second hard drive with Bionic takes about 24 seconds to boot up. Any room for improvement!

i have the same issue, but i have not upgraded fully to bionic.
it takes about 60 seconds too boot up, plasma desktop loads, and after that for about 120 seconds the system hangs, and cpu runs at 100%.
whats up with that?

A new bionic install yesterday show:

$ systemd-analyze
Startup finished in 13.633s (firmware) + 8.092s (loader) + 3.880s (kernel) + 7.408s (userspace) = 33.015s
graphical.target reached after 7.405s in userspace

Confirmed, this seems to be resolved now. Thanks whoever did that

There's still an apt-daily service but it's much faster and it seems to be a different service now. apt-daily.service versus apt-daily-upgrade.service

Code: Select all

$ systemd-analyze blame
          7.148s NetworkManager-wait-online.service
           854ms dev-nvme0n1p2.device
           677ms motd-news.service
           486ms snapd.service
           432ms apt-daily-upgrade.service
           256ms systemd-resolved.service
           256ms systemd-timesyncd.service
           218ms nvidia-persistenced.service

Hi, I have noticed that too.
systemd-analyze
systemd-analyze
Startup finished in 5.268s (kernel) + 3min 35.627s (userspace) = 3min 40.895s
graphical.target reached after 29.289s in userspace
systemd-analyze blame
3min 5.303s apt-daily.service
15.254s dev-sda1.device
12.180s lvm2-monitor.service
12.074s systemd-journal-flush.service
11.719s systemd-tmpfiles-setup-dev.service
6.483s NetworkManager-wait-online.service
3.650s snapd.service
3.424s NetworkManager.service
3.230s udisks2.service
3.209s networkd-dispatcher.service
2.243s ModemManager.service
2.012s motd-news.service
1.795s systemd-tmpfiles-clean.service
1.794s accounts-daemon.service
1.781s thermald.service
1.441s keyboard-setup.service
1.279s apt-daily-upgrade.service
1.144s resolvconf.service
1.123s gpu-manager.service
1.089s grub-common.service
1.067s resolvconf-pull-resolved.service
958ms dev-hugepages.mount
943ms systemd-remount-fs.service
922ms sys-kernel-debug.mount
912ms dev-mqueue.mount
795ms systemd-modules-load.service
696ms networking.service

Hi,
Today the problem seems partially solved.
systemd-analyze time
Startup finished in 5.255s (kernel) + 1min 40.336s (userspace) = 1min 45.591s
graphical.target reached after 28.785s in userspace
systemd-analyze blame
1min 10.504s apt-daily.service
14.725s dev-sda1.device
11.988s systemd-tmpfiles-setup-dev.service
11.784s lvm2-monitor.service
11.391s systemd-journal-flush.service
9.818s systemd-sysctl.service
6.324s NetworkManager-wait-online.service
4.183s snapd.service
3.461s networkd-dispatcher.service
3.199s NetworkManager.service
3.012s udisks2.service
2.469s accounts-daemon.service
2.330s thermald.service
2.278s resolvconf-pull-resolved.service
2.028s ModemManager.service
1.574s grub-common.service
1.445s systemd-modules-load.service
1.296s apt-daily-upgrade.service
1.148s keyboard-setup.service
1.123s resolvconf.service
1.008s networking.service
939ms gpu-manager.service
931ms lm-sensors.service
929ms avahi-daemon.service
905ms pppd-dns.service
905ms systemd-logind.service
851ms rsyslog.service

I also run this command today
systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

graphical.target @28.785s
└─multi-user.target @28.785s
└─virtualbox.service @28.534s +250ms
└─network-online.target @28.528s
└─NetworkManager-wait-online.service @22.203s +6.324s
└─NetworkManager.service @18.940s +3.199s
└─dbus.service @18.121s
└─basic.target @18.015s
└─sockets.target @18.015s
└─snapd.socket @18.011s +2ms
└─sysinit.target @17.987s
└─systemd-timesyncd.service @17.828s +158ms
└─systemd-tmpfiles-setup.service @17.687s +123ms
└─local-fs.target @17.681s
└─media-jochoa-Bluebirds.mount @36.392s
└─clean-mount-point@media-jochoa-Bluebirds.service @36.475s
└─system-clean\x2dmount\x2dpoint.slice @36.475s
└─system.slice @2.506s
└─-.slice @2.491s

Then you could run some test over the services with the command journalctl looking at the results from systemd-analyze blame or critical-chain.
For example,
journalctl -f -u NetworkManager.service
-- Logs begin at Wed 2018-09-26 08:59:29 -03. --
sep 28 12:13:33 jochoapc NetworkManager[802]: <info> [1538147613.2144] dhcp4 (enp3s0): state changed unknown -> bound
sep 28 12:13:33 jochoapc NetworkManager[802]: <info> [1538147613.2177] device (enp3s0): state change: ip-config -> ip-check (reason 'none', sys-iface-state: 'managed')
sep 28 12:13:33 jochoapc NetworkManager[802]: <info> [1538147613.2210] device (enp3s0): state change: ip-check -> secondaries (reason 'none', sys-iface-state: 'managed')
sep 28 12:13:33 jochoapc NetworkManager[802]: <info> [1538147613.2220] device (enp3s0): state change: secondaries -> activated (reason 'none', sys-iface-state: 'managed')
sep 28 12:13:33 jochoapc NetworkManager[802]: <info> [1538147613.2228] manager: NetworkManager state is now CONNECTED_LOCAL
sep 28 12:13:33 jochoapc NetworkManager[802]: <info> [1538147613.3714] manager: NetworkManager state is now CONNECTED_SITE
sep 28 12:13:33 jochoapc NetworkManager[802]: <info> [1538147613.3717] policy: set 'Wired connection 2' (enp3s0) as default for IPv4 routing and DNS
sep 28 12:13:33 jochoapc NetworkManager[802]: <info> [1538147613.3734] device (enp3s0): Activation: successful, device activated.
sep 28 12:13:33 jochoapc NetworkManager[802]: <info> [1538147613.3755] manager: NetworkManager state is now CONNECTED_GLOBAL
sep 28 12:13:36 jochoapc NetworkManager[802]: <info> [1538147616.7164] manager: startup complete



Hope it helps.

Hola Mis tiempos son :
Startup finished in 7.520s (firmware) + 2.844s (loader) + 34.412s (kernel) + 2.391s (userspace) = 47.169s
graphical.target reached after 2.364s in userspace
¿Problemas kernel? ¿solucion?
Saludos
Pedro

Hi Pedro,
In order to look which is the longer service time and see what is happening you shoud run this command first
systemd-analyze blame
I saw in my post that the apt-daily.serviece has the longer time and I should try to run journalctl -f -u apt-daily.service in orde to look for some problems.
I do not know which is your longer service startup time.
Please, run this command and put the output here:
journalctl -f -u the_name_of_the_longer_service in your output.

Hope it helps,

I was able to upgrade all my computers with no problem at all. The only issue was a long start up on an encrypted hard drive which I have on all my computers. After I upgraded my system to Bionic, it was taking just about 40 seconds just to get to the login screen after you entered the encryption key. Before the upgrade, it took about 6 seconds. So I decided to do a fresh install, to see what happens, and then boom.... runs like a champ now! It takes less than 3 seconds to get to the login screen after entering the encryption key! Needless to say I ended up formatting all my computers and did a fresh install! So I recommend a fresh install if you're having the same issue. A BIG thank you to the developers and the Neon team for such a fantastic product, as the quality indeed shows.

Hola . HI . j8a .
808ms snapd.service
725ms dev-sdb2.device
621ms keyboard-setup.service
384ms snapd.seeded.service
369ms systemd-journal-flush.service
334ms udisks2.service
296ms NetworkManager.service
295ms networkd-dispatcher.service
219ms systemd-logind.service
179ms systemd-timesyncd.service
164ms systemd-resolved.service
119ms snap-core-5328.mount
111ms systemd-rfkill.service
98ms snap-kde\x2dframeworks\x2d5-25.mount
90ms lvm2-monitor.service
84ms ModemManager.service
82ms apparmor.service
75ms systemd-udev-trigger.service
72ms plymouth-quit-wait.service
72ms thermald.service
71ms snap-core-5145.mount
70ms plymouth-quit.service
67ms accounts-daemon.service
63ms grub-common.service
55ms upower.service
53ms snap-core-4917.mount
50ms systemd-journald.service
49ms systemd-tmpfiles-setup-dev.service
44ms systemd-fsck@dev-disk-by\x2duuid-2EE8\x2d2382.service
42ms pppd-dns.service
40ms systemd-udevd.service
39ms rsyslog.service
37ms snap-kde\x2dframeworks\x2d5-27.mount
¿Solucion actualizo kernel a 4.18 ?
Saludos y gracias
Pedro

adamno wrote:

Code: Select all

$ systemd-analyze blame
        15.929s apt-daily.service
        6.205s NetworkManager-wait-online.service
        810ms dev-nvme0n1p2.device
        634ms motd-news.service
        ...

I guess it has a wifi connection?
In any case seems that it takes 6 secs to come online and NetworkManager-wait-online.service delays the boot. You can safely disable that service and the only side effect will be that you would already have a full functional desktop but you would need to wait for the network to be connected

I had similar issues upgrading from Mint 18.3 (16.04 base) to Mint 19 (18.04 base) on all three of my PCs that I upgraded. In each case, the problem for me was an apparent conflict between the way that I had swap set up (in its own partition, unencrypted) and the default config for 18.04, which was an encrypted swap file (not in its own partition). Sometimes I would get prompts for a swapfile passphrase during boot, something I'd never explicitly set, as I had never said I wanted an encrypted swapfile (I use the self encrypting feature on my Samsung SSDs, so everything's encrypted with no performance hit).

I edited fstab to specify the swap partition be mounted as such, making sure the UUID was the same as expected, deleting any references to encryption, and setting swapon (I used the GNOME Disks utility that comes with Mint) and making sure that partition is active.

In addition, I had to edit this file:

Code: Select all

/etc/initramfs-tools/conf.d/resume

It had some ecryptfs stuff in there I had never asked for, so I changed it to the UUID of my swap partition. I also added resume=UUID=xxxxxxxxxxx to the Grub kernel parameters in order to re-enable hibernation (which depends on the swap partition).

After that,

Code: Select all

sudo update-grub

and maybe

Code: Select all

sudo update-initramfs

(not sure if that last one is necessary or not, but it should not hurt to do both).

Another change that took place between the 16.04 base and the 18.04 base was that Ubuntu removed the ecryptfs support from the latter version, which is why the "encrypt home folder" button is gone for the 18.04 installers. If you were using ecryptfs, installing that over an existing installed ecryptfs library might have caused problems.

Hi, I recieved and upgrade for lightdm today and now I saw that the start up time improves, although my machine is a bit old.
systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

graphical.target @29.142s
└─multi-user.target @29.142s
└─virtualbox.service @28.521s +619ms
└─network-online.target @28.520s
└─NetworkManager-wait-online.service @21.193s +7.326s
└─NetworkManager.service @14.034s +7.106s
└─dbus.service @13.279s
└─basic.target @13.096s
└─sockets.target @13.096s
└─snapd.socket @13.079s +15ms
└─sysinit.target @13.037s
└─apparmor.service @11.863s +1.173s
└─local-fs.target @11.849s
└─run-user-1000.mount @27.737s
└─swap.target @11.501s
└─dev-disk-by\x2duuid-9cbdb76e\x2d8c9f\x2d4eba\x2db48c\x2de5d7884fbfac.swap @11.401s +99ms
└─dev-disk-by\x2duuid-9cbdb76e\x2d8c9f\x2d4eba\x2db48c\x2de5d7884fbfac.device @11.399s
jochoa@jochoapc:~$ systemd-analyze blame
8.945s networkd-dispatcher.service
8.828s dev-sda1.device
8.618s snapd.service
7.326s NetworkManager-wait-online.service
7.106s NetworkManager.service
6.801s udisks2.service
6.310s ModemManager.service
3.947s accounts-daemon.service
3.846s dev-loop0.device
3.795s dev-loop5.device
3.674s dev-loop1.device
3.648s dev-loop3.device
3.598s dev-loop2.device
3.554s dev-loop4.device
3.323s networking.service
3.268s thermald.service
2.808s wpa_supplicant.service
2.619s systemd-journal-flush.service
2.446s lvm2-monitor.service
2.330s gpu-manager.service
1.839s systemd-tmpfiles-setup-dev.service
1.833s rsyslog.service
1.790s systemd-udevd.service
1.533s grub-common.service
1.462s keyboard-setup.service
1.248s polkit.service
1.177s avahi-daemon.service
jochoa@jochoapc:~$ systemd-analyze
Startup finished in 5.220s (kernel) + 29.157s (userspace) = 34.377s
graphical.target reached after 29.142s in userspace