Announcement

**jlittle** · Sep 21, 2021, 02:53 AM

"Over a minute" suggests a systemd timeout, which default to 90 s. These can be a nuisance to track down, but the timeout length can be changed from the default.

Have you turned on boot messages to see what's happening? (To do so, edit /etc/default/grub to remove the words "quiet splash" from the variable settings where they appear, then run sudo update-grub in a konsole.)

Often it's a network timeout accessing a device on a system that's not on or not there. Starting Kubuntu with an empty session might help.

**claydoh** · Sep 21, 2021, 06:56 AM

Code:

Startup finished in 28.028s (firmware)

This may be the place to look, though it won't be obvious what the real culprit is.
This 28 seconds is the time it takes to get past the bios POST, before grub or anything else, so this very likely is not OS related at all.

Do you have a USB backup drive or similar connected?
I ask as I myself have a 'long' boot time, with moist of it being similar toy your output - a very long time to get past the bios, sometimes well over 30 seconds. After messing with various settings, I sort of gave up, figuring the HP just had a sh***ty bios. Yesterday, I accidentally unplugged my external USB backup drive, and neglected to plug it back in. My boot time in the firmware section dropped to just over 10 seconds, which is nearly 1/3 of the previous time. The rest of the boot seems faster, but I don't remember the overall time it used to be with the drive connected.

Your Snaps do add some time to logins, but do note that the times you see in systemd-analyze blame are not cumulative, many things are loaded in parallel, so remove one tiem tjhat takes 2 seconds or something won't speed up boot time by those 2 seconds.

But you do have a lot of things being mounted (.mount and loop devices, not just from snaps.)

the NetworkManager-wait-online.service is worth investigating, this can hold up other things, and is quite common for some people to notice and learn how to disable. A few seconds is a few seconds

**jasoncollege24** · Sep 21, 2021, 09:10 AM

replying in order. jlittle, I have not tried with the splash turned off, and I may try this, but I always start with an empty session. (This is one of the first things I change in a new install, because I love fresh sessions)

Firmware startup isn't something I'm worried about. I know what causes that, and it's the same delay for Windows. I have 1 bad physical USB port, that I never use, and another that's always reported, but isn't physically connected to the system. The board has a USB-C connector that the case didn't have a plug for, and the other was burned out by a power surge. Pretty sure the 30-ish second POST delay is caused by these, and I ignore this problem.

Literally the only time I'm worried about dropping is the kernel boot time, which is just over a minute. I get rid of that slow down, and my boot times will be right in-line with Windows 10. This system dual-boots with Windows 10. Once that boot gets past the 30-ish seconds worth of POST delays, it's up, and waiting for me to login in around 10 seconds.

I have a fat32 external drive that is always connected to the system. I call it my travel drive. It stays connected to this PC, unless I go somewhere with my laptop, as it has files I use on both. I could try disconnecting that on my next boot.

Hard drive mounts are all noted in fstab, which has been checked several times, to make sure those are set correctly, and that the noauto option is used on any drive that might not be attached on boot (travel drive, for example)

I use grub as my OS Choice menu. When I choose Windows, normal boot, no issues. When I choose ubuntu, it goes back to my POST splash, and I don't see the Kubuntu splash, until a full minute has passed. Once I see the Kubuntu splash, boot takes only seconds.

**claydoh** · Sep 21, 2021, 09:42 AM

Look at the large number of snaps, and their respective mounts.

look a the first things unrelated to snaps:

Code:

7.630s NetworkManager-wait-online.service                                                       
3.491s media-jason-Users.mount                                                                  
3.376s upower.service                                                                           
3.163s media-jason-Virtual.mount                                                                
3.099s media-jason-ROMs.mount                                                                   
2.399s media-jason-VM.mount

These may be causing slowdown/waits as other startup services wait for these to finish

You do have an fairly large number of snap applications + their respective loops/mounts, and dependency loops/mounts. This could be a factor as well. Well, very likely is the factor. Count the number of loop and mount items in your startup.

So, imo you might want to look at disabling NetworkManager-wait-online.service, this seems to be a common item that can slow down the loading of other services down the line that are waiting for the network to load. Some people (not all!) see good improvements without it.

and then try disabling or removing some of your snaps, including the ones you won't see in a GUI software center.

**claydoh** · Sep 21, 2021, 11:42 AM

I also realized I missed clarifying my point about drives and a slow POST. 30 seconds is a LONG time for this process, and my removing the USB backup drive not only sped that part up by 2/3, it also reduced the overall boot time from ~ 1 minute to under 25 seconds. It may not be anything major, but examining the drives(s) and partitions might also be worth looking at if Snaps are not the main cause for your slow boot.

**jasoncollege24** · Sep 21, 2021, 05:30 PM

Here's what I've done, and the results there-of:

commented out the "no-splash" line in /etc/default/grub, and ran sudo update-grub. When I watched, I saw my custom NTFS mounts take an abnormally long time to mount. The 2TB "Users" partition took 20 minutes alone. I set all of those to "noauto" in fstab, and it stopped that issue, but the txt during boot flies by, so I have no time to read anything. There a way to do a one-time output of ALL of that text to a text file of my choosing, so I can peruse through it easier? (I did see a timeout on a device, but it was gone, before I could read more than that.)

removed the snap packages notepad-plus-plus, and spotify. I use keepassxc a lot, so keeping that. Here's the remaining list. Not sure about those Wine packages, because I don't know if keepassxc uses one of them. (I'm assuming they're for some snaps) What can I safely remove from here?

Code:

core18
gnome-3-28-1804
gtk-common-themes
keepassxc
snapd
wine-platform-5-stable  5.0.3
wine-platform-6-stable  6.0.1
wine-platform-runtime   v1.0

Since NetworkManager-wait-online.service was mentioned, I should point out that I did not disable it, because in certain circumstances, I need access to the computer from the network, to issue commands at the login screen, but not before that point. (usually to change to the display on my bed, since I'm disabled) If I can disable this, and still issue commands via ssh, once i reach the GUI Login screen, then let me know, and I will try this step.

You mentioned loop devices. I see those in the blame list, but not sure what they are. I do have a xbox controller driver, which allows me to use my xbox one controller, with it's own wireless dongle, as opposed to plugging it in. I also have a few different bluetooth devices.

The above changes served only to shorten the userspace boot time from 12.4s to about 9.8 seconds. The kernel boot time has not changed.

Here's the breakdown of boot times, and where the issue is)
* POST (ROG Splash) (30s average, don't care about this)
* GRUB Boot menu (however long it takes me to choose Linux)
* Kernel boot (ROG Splash, 1m8s)
* userspace boot (Kubuntu splash, 9.8s, don't care about this)

Nothing seems to be shortening the kernel boot time, which I've seen as low as 2-3s on other posts I've found here about slow boot times. This userspace stuff is helping me make normal boot times quicker, so thanks for those tips, but this is abnormal, and appears to be happening earlier than the stuff you're suggesting... unless I'm misunderstanding? (I have a good grasp of Linux, but am still kinda new.)

oh... the POST has been this way, since I installed the board to a case with no USB-C connector included. I might turn off the splash screen there, to see what it's doing behind closed doors. I've also unplugged the external drive. will update you on my next reboot to Linux.

**claydoh** · Sep 21, 2021, 07:11 PM

Since NetworkManager-wait-online.service was mentioned, I should point out that I did not disable it, because in certain circumstances, I need access to the computer from the network, to issue commands at the login screen, but not before that point. (usually to change to the display on my bed, since I'm disabled) If I can disable this, and still issue commands via ssh, once i reach the GUI Login screen, then let me know, and I will try this step.

This won't effect that, it just stops the boot process from waiting for a network connection before proceeding. Network Manager is still going to load things, the rest of the system just won't be waiting around for it to get it's butt into gear. In any case, it is the same sort of step to re-enable it.

**jasoncollege24** · Sep 22, 2021, 04:05 PM

This problem is resolved. when I disabled the service, and restarted, I used my phone to take pictures of some of the pauses in text.

Your USB backup drive theory was partially correct. I use a 28 port hub, to connect everything, except my VR headset, keyboard, and mouse. Turns out that some of the ports there have gone bad. Moving everything out of the bad ports resolved the issue with both the Linux boot time, and the POST time. It also tells me that what I thought was a burned out USB port on my PC was actually an item plugged into a bad port on the hub. THANK YOU!

Code:

Startup finished in 15.521s (firmware) + 7.520s (loader) + 4.983s (kernel) + 12.597s (userspace) = 40.622s 
graphical.target reached after 12.591s in userspace

**claydoh** · Sep 22, 2021, 05:21 PM

Originally posted by jasoncollege24 View Post

Code:

Startup finished in 15.521s (firmware) + 7.520s (loader) + 4.983s (kernel) + 12.597s (userspace) = 40.622s 
graphical.target reached after 12.591s in userspace

Zooom!

Sweet

Announcement

Kernel takes more than a minute to boot

[SOLVED] Kernel takes more than a minute to boot

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment