1 minute boot times
Experiencing slower than expected boot times compared to the other folks in the main channel.
systemd-analyze plotoutput attached as image. Is this expected? Is my system doing something strange?

62 Replies
It looks like you've got multiple SSDs installed which could be contributing to the long boot time as each drive is initialized.
You could try disconnecting or removing the other SSDs to check the boot time with just the 990 Pro that has Bazzite on it.
Additionally, is one of your SSDs in compatibility mode or ATA mode in your BIOS?
Has it been this slow on earlier deployments of Bazzite or other Linux distros?
Not so slow on Windows, didn't try other distros before this.
And my board doesn't include an ATA mode period.
If the boot time scales with the amount of storage devices (since it looks like 5 seconds for each one?) Then there isnt much to be done
@SkyOnPC what's the output of
And
?
blame has quite a few lines but the longest timed ones at the top are
One of these I recognize as my eldest Sata SSD.
Critical-chain:
Are those devices set to mount automatically?
What's the output of
?
All devices are automount. Promise to reply with the Fstab output in ~3 hours as I fell asleep and am now working.
@SkyOnPC in the future, could you use three ` instead? addressed!
Oh yeah my bad I didn't even know doing it 3 times would block format it like I can on slack
I'll even edit it now to fix it
in fact discord supports syntax highlighting (``'cpp) while slack doesn't lol, it's wild
I think what surprises me is that init for these devices is >5s when someone on weaker hardware had it at like 4s, I wonder if it's a quirk dependent on something else.
i wonder how they look in bios/uefi, if they aren't being potentially gimped on PCIex speeds?
but that wouldn't be a linux specific issue, that'd happen on any os
Have you turned off fast startup on Windows?
The long boot time could also be from a performance regression though with this being your first Linux install and first Bazzite deployment you would have to do something like
to roll back to the previous stable release. It'll download the 42-based image with Linux 6.16.4 so you can test that
All four should be Gen4, I at least went back into Windows and checked for this in HWINFO64, I also ran KDiskMark in parallel and the speeds match up OK
With only the 990 Pro getting gimped by CoW
I can boot back in and check if it is somehow re-enabled but I disabled this when prepping to dual boot back on Bazzite 42
I haven't rebased or anything since installing back in...August?
Ah, you've had this installed for a few months already?
Was the performance any different when you first installed it?
Its always been this slow, usually a lengthy black screen period between the Bazzite loading wheel screen and finally seeing the desktop
For science, switching back to Windows, was 16 seconds from Bios to Desktop
Systemd analyze is reporting >1m for Bazzite, so its a giant discrepancy
-> Fast Startup is not on

that pretty much eliminates it being a performance regression of any recent code changes

And as far as HWInfo suggests, all drives are at their rated speeds + the GPU
The 990s are gen4, and the 970 is gen 3,
Booting back into Bazzite now and the latest analyze plot states
Startup finished in 12.774s (firmware) + 4.644s (loader) + 1.076s (kernel) + 4.419s (initrd) + 46.161s (userspace) = 1min 9.075s graphical.target reached after 5.954s in userspace.
Unfortunately the Asrock bios for AM4 sucks and doesn't state anywhere the PCI-E state of the drives, so the only way for me to check is in terminal on Bazzite or with HWInfo64Getting systemd to initialize the drives more effectively might help.
What's the output of
?
Getting that just a sec
Wait
maybe I have to sudo for that...
nah didn't change, same message
If the drive that fstab is trying to mount isn't present, that could be increasing the boot time by quite a bit as it waits for the mount to timeout.
What's the output of ?
Do you get any output with ?
I wonder if that uuid is for my external NVME that is disconnected.
That'll do it
blank output for the 2nd one
yep that's expected for a drive that isn't connected
I had that external automounted because it typically is stationary
I just didn't bring it with me when moving my PC into the other room for a bit
(i also have a little bit of an unallocated space disaster from trying and failing to resize BTRFS....)
Oh! So I guess that would be our answer huh, if I have automounting on all, it's probably hanging on various...things that don't matter....right?
Like the disconnected NVME, and probably the empty partitions?
You can turn off the explicit automount and switch it to an on-demand automount for that drive by opening fstab in an editor (kate will handle sudo permissions when you save) and adjusting the line.
change the last line so it reads
after that, run
and you can reboot to check how it performs after.
That switches it from being mounted on boot to mounted when you have it plugged in and are trying to access it
Doing that now and checking
The command specific to that drive would be helpful in replacing the fs type (currently
auto) but with systemd handling the mounting after boot it shouldn't impact performanceLearned something new from this because I've never really messed with fstab
On reboot, Gamescope is kind of "hung" on loading user data....I'll give it a minute
Did it load in?
nope, stuck
I tty'd out to reboot one more time for good measure but its the same
boot time is measurably faster though, I timed 34 seconds before getting softlocked at Loading User Data.....
This screen.

Mashing buttons on the keyboard I managed to get to the Steam menu and press "Switch to Desktop" but that...didn't seem to work
Can you get kate back open to edit the fstab?
there's also
though it is less intuitive and requires you to use arrow keys to move a cursor around and change values
I'm familiar with nano from working on a cluster
since I can't get to a desktop period I'll have to do that in the TTY and break out the super squint
because on the 4K panel the TTY is actually for ants
Are all of the other lines still there?
I cleaned up the UUID for readability in this version of the fstab:
I also removed noauto from the line
had to retype because while I was looking at it, it "restarted" the gamescope session
and kicked me out
just a sec
oh yknow looking at it I think I clobbered it somehow
yeah oops this is user error let me fix it based on what you just pasted
each UUID= (including the /dev/disk/by-uuid line) should be starting its own line and both methods of addressing the drive by uuid are valid/correct though the UUID= is generally preferred due to readability
yeah i clobbered the uuid part when editing
i put it back and the rest of the line is the same now
If you kept noauto from the earlier suggestion it should make systemd mount the drive when it would be accessed.
Did you get it to load back up after a reboot?
rebooted and same, still hung.
I wonder if I clobbered the var/home line too? give me a sec to actually compare line by line
(I swear I just copied over the last one in fstab though...)
This is what your home line should look like:
For the last line, this would effectively revert any changes while making fstab more readable:
Image of the term I'm looking at now just for ref

Wondering wtf I broke here
Checking it over
It is worth noting that as mentioned, it eventually fails out and soft restarts switching me back out of TTY3
let's see if the mount file was created
getting back up to stand in front of the screen to type it lol, just a second
hopefully something like 7ab0846f-fcc3-4287-b8fe-365ad99b3be3.mount is there
blank output
lemme revert the line entirely for a second so I can at least get back into the system and stop squinting at the screen
Is that drive your game drive?
yeah it just has games and misc files on it
its the only drive that wasnt listed in lsblk -f earlier
so im sure that uuid has to be that one
i just typed out the original line that was there, reload, reboot. we'll see in a second if it behaves normal now
Yep!
I put this back exactly and no hang.
let me go pick the drive up off the floor and plug it in
Sorry for the toubles. The drive shouldn't affect Gamescope in that way considering that it wasn't previously present though it seems that it is requiring it somehow anyways. What happens when you reboot with the drive plugged in? Hopefully the boot time should be faster with it not timing out the mount
the story gets weirder
i plugged that drive in and its uuid is different
I have no idea wtf that is,
Wait
there's no way that's my dead SSD from august?
My system wont even post with that one connected so i cant even confirm but thats my only thought now
Does the mountpoint show anything?
if there's nothing there, you could probably safely comment out that line to prevent mount timeouts increasing boot time.
Just a single # in front of the line and if it breaks you only have to undo that.
omg bruh yeah I think that's what it is
right when I installed bazzite, I had a really old sata SSD I used as a kind of buffer while I moved data clap out and legit make the entire machine not post so I unplugged it and moved on with my life.
Let's make a copy of your working fstab before making any further changes.
Done :Check: this is quite the learning experience. Just comment out that line from fstab now?
Considering that you have now a whole backup fstab, feel free to remove that last line entirely.
You can verify that the fstab backup has the line correct with
before making the change
done and rebooting, lets see
load bearing SSD from the grave 😅 it booted just fine without the line at all
time to check analyze for our time savings
Perfect! Over halved the time and now it looks normal as with everyone else.
I think we're good here. I certainly didn't know disconnected drives could cause that quite this that way. Good learning experience too. Thanks!