Booting time/Congrats Kubuntu

[steve7233]

I just timed the boot from where it says "Loading OS." to steam and firefox being up. SSD + abt 28 seconds!

Fantastic work team Kubuntu. Of course, not everyone has an SSD like I do. Read=650 ms, Write = 670 ms.

[steve7233]

Looks like the snoopy emote doesn't work.

Sent from my LM-Q610(FGN) using Tapatalk


(Dancing Snoopy added by Snowhog)


Works for me.

[claydoh]

pfff

Why so long?? I think my ex-laptop took about 10 seconds from hitting the power button to loading the desktop, including any applications open in the last session.

Have not checked my new-to-me PC that replaced it; it has a slow loading bios.

 sudo hdparm -Tt /dev/nvme0n1p2

/dev/nvme0n1p2:
 Timing cached reads:   31472 MB in  1.99 seconds = 15848.62 MB/sec
 Timing buffered disk reads: 2762 MB in  3.00 seconds = 920.47 MB/sec

Cant quickly recall which benchmark or test is best for nvme ssds

[steve7233]

pfff

Why so long?? I think my ex-laptop took about 10 seconds from hitting the power button to loading the desktop, including any applications open in the last session.

Have not checked my new-to-me PC that replaced it; it has a slow loading bios.

 sudo hdparm -Tt /dev/nvme0n1p2

/dev/nvme0n1p2:
Timing cached reads:   31472 MB in  1.99 seconds = 15848.62 MB/sec
Timing buffered disk reads: 2762 MB in  3.00 seconds = 920.47 MB/sec

Cant quickly recall which benchmark or test is best for nvme ssds

Mabey something needs configuring. There is a delay after pressing the power button and another delay getting Grub II to work. It might be something hardware related.

[claydoh]

naw, already looked at that,but not thoroughly, though I had not shortened the default 10 second grub timeout for the windows drive I never boot to. It is probably partly due to looking for network booting.
I seldom reboot, so hardly notice anyway.
My last HP was similar, taking even longer to get to grub than this one does. No biggie. Still takes far less than 30 seconds.

[steve7233]

I just tried editing my first post and deleting the snoopy code and then re-adding it. It still doesn't work which is weird since it works for Snowhog.

[GreyGeek]

Mabey something needs configuring. There is a delay after pressing the power button and another delay getting Grub II to work. It might be something hardware related.

Try

systemd-analyze blame

to see what is taking most of your boot up time.

For me, apparmor reporting took almost 40 seconds to load, I edited its unit and set it to run in the background about a minute after boot up was complete.

My current "systemd-analyze"

$ systemd-analyze
Startup finished in 3.412s (kernel) + 8.157s (userspace) = 11.569s
graphical.target reached after 8.147s in userspace

[Don B. Cilly]

Boo hoo.
On an SSD and all, I get

~$ systemd-analyze
Startup finished in 7.697s (firmware) + 11.316s (loader) + 6.191s (kernel) + 11.557s (userspace) = 36.761s
graphical.target reached after 11.532s in userspace

Of course, most of the blame is on 7.045s NetworkManager-wait-online.service

Oh well. Still, even though it's nothing to dance about, in the interest of general knowledge, I'll try the annoying-snoopy thing, shall I.

[mick.kde]

Nothing is as annoying as that wandering fly on the screen.

[GreyGeek]

Boo hoo.
On an SSD and all, I get

~$ systemd-analyze
Startup finished in 7.697s (firmware) + 11.316s (loader) + 6.191s (kernel) + 11.557s (userspace) = 36.761s
graphical.target reached after 11.532s in userspace
...

What is "firmware" and "loader", which are taking 18 seconds of your boot up time?
Can you turn them, and POST, off?

[Don B. Cilly]

What is "firmware" and "loader", which are taking 18 seconds of your boot up time?

Good question. What are they?

Can you turn them, and POST, off?

Even better question. Can I?

[AH] There you go: my 20 top "blames".

~$ blm
        7.085s NetworkManager-wait-online.service
        2.687s dev-sdc2.device
         989ms udisks2.service
         821ms mysql.service
         507ms accounts-daemon.service
         504ms ModemManager.service
         500ms systemd-journal-flush.service
         492ms dev-disk-by\x2duuid-c988060d\x2dc444\x2d430e\x2db5cd\x2d4ea65aa54446.swap
         490ms upower.service
         457ms systemd-udev-trigger.service
         436ms hcron.service
         419ms lvm2-monitor.service
         399ms grub-common.service
         332ms thermald.service
         316ms pppd-dns.service
         311ms networkd-dispatcher.service
         274ms NetworkManager.service
         268ms keyboard-setup.service
         260ms systemd-logind.service
         251ms systemd-journald.service

(blm is an alias for systemd-analyze blame | head -n 20)

[kubicle]

Good question. What are they?

If you boot via UEFI and use a boot loader which implements systemd's Boot Loader Interface (which currently systemd-boot and GRUB do), systemd-analyze can additionally show you how much time was spent in the EFI firmware and the boot loader itself.
(Note that system initialization and boot loader take their time even if you boot with legacy BIOS, it's just that systemd-analyze can't report them separately)

Even better question. Can I?

Not really, but it is sometimes possible to shorten the duration via configuration, like turning of extended POST checks in EFI firmware etc.

[Don B. Cilly]

I boot via UEFI and have rEFInd as boot manager.
Now, turning off extended POST checks in EFI firmware etc... if I groogle that... hrumph. Any hints and tips from a serious forum? ;·)

Mind you, I'm perfectly happy with my boot times - the ones on the SSD. And I realise GG's may not be "telling the whole story".
Still, nothing wrong with optimising where possible, is there. And it's of general interest anyway... I guess :·)

[kubicle]

I boot via UEFI and have rEFInd as boot manager.
Now, turning off extended POST checks in EFI firmware etc... if I groogle that... hrumph. Any hints and tips from a serious forum? ;·)

Mind you, I'm perfectly happy with my boot times - the ones on the SSD. And I realise GG's may not be "telling the whole story".
Still, nothing wrong with optimising where possible, is there. And it's of general interest anyway... I guess :·)

To see what power-on-self-test configuration(s) are available on your system, you have to boot into into the UEFI setup, commonly done by pressing a key (like F2, but can be something else on different systems) during boot...you can also boot into efi by choosing "system setup" in the grub menu (I don't know how refind handles that).

I'm not suggesting you should change the efi settings, especially if you are happy with the boot times, POST checks can give you valuable information on hardware failures etc.

And while I personally think that there is no such thing as "excessive optimizing", boot times are fairly meaningless to me (I commonly boot only after kernel upgrades)

[Don B. Cilly]

So, my BIOS takes some 8 seconds to load. I'll keep the POST checks.
rEFInd some 11 - of which 10 are waiting for a choice. I can optimise that, make the timeout 2.

I do reboot "a lot" - at least two to sometimes even ten or more times a day. It's a desktop rig.
From pressing the power button to have a usable desktop - like really usable, for anything, unlike some OSs we know ;·) - it takes some 40 seconds altogether... not anything I'd worry about.
It's a fairly old (2014) rig too.