Hello all,
I’ve noticed that my bootup time takes longish, and while it is not a deal breaker i’ve devoted some time to troubleshooting. I am by no means a linux expert and need some help with this.
I’ve also tried messing with AI assistants that claim that it’s the problem with initrd stage because it’s waiting for timeout from my second (samsung) nvme where my windows are installed for dual boot. The drive is not in fstab.
bazzite@SectorNik:~$ systemd-analyze plot > boottime.svg
bazzite@SectorNik:~$ systemd-analyze time
Startup finished in 23.566s (firmware) + 4.661s (loader) + 1.707s (kernel) + 1min 6.444s (initrd) + 11.600s (userspace) = 1min 47.981s
graphical.target reached after 6.801s in userspace.
bazzite@SectorNik:~$ systemd-analyze blame | head -40
1min 7.316s sys-module-fuse.device
1min 7.227s sys-devices-LNXSYSTM:00-LNXSYBUS:00-MSFT0101:00-tpm-tpm0.device
1min 7.227s dev-tpm0.device
1min 7.224s sys-devices-platform-serial8250-serial8250:0-serial8250:0.2-tty-ttyS2.device
1min 7.224s dev-ttyS2.device
1min 7.224s sys-devices-pnp0-00:04-00:04:0-00:04:0.0-tty-ttyS0.device
1min 7.224s dev-ttyS0.device
1min 7.221s dev-ttyS1.device
1min 7.221s sys-devices-platform-serial8250-serial8250:0-serial8250:0.1-tty-ttyS1.device
1min 7.219s sys-devices-platform-serial8250-serial8250:0-serial8250:0.3-tty-ttyS3.device
1min 7.219s dev-ttyS3.device
1min 7.215s dev-tpmrm0.device
1min 7.215s sys-devices-LNXSYSTM:00-LNXSYBUS:00-MSFT0101:00-tpmrm-tpmrm0.device
1min 7.208s sys-module-configfs.device
1min 7.161s dev-disk-by\x2did-nvme\x2deui.0025385751a189bc\x2dpart1.device
1min 7.161s dev-disk-by\x2dpath-pci\x2d0000:0e:00.0\x2dnvme\x2d1\x2dpart-by\x2dlabel-SYSTEM.device
1min 7.160s dev-disk-by\x2dpath-pci\x2d0000:0e:00.0\x2dnvme\x2d1\x2dpart-by\x2dpartuuid-7e10266b\x2d1e37\x2d451c\x2db70a\x2dc4e21f9b4d31.device
1min 7.160s dev-nvme1n1p1.device
1min 7.160s dev-disk-by\x2ddiskseq-2\x2dpart1.device
1min 7.160s dev-disk-by\x2dpath-pci\x2d0000:0e:00.0\x2dnvme\x2d1\x2dpart-by\x2duuid-E88D\x2d281A.device
1min 7.160s dev-disk-by\x2dpath-pci\x2d0000:0e:00.0\x2dnvme\x2d1\x2dpart1.device
1min 7.160s dev-disk-by\x2dpath-pci\x2d0000:0e:00.0\x2dnvme\x2d1\x2dpart-by\x2dpartnum-1.device
1min 7.160s dev-disk-by\x2dpartuuid-7e10266b\x2d1e37\x2d451c\x2db70a\x2dc4e21f9b4d31.device
1min 7.160s sys-devices-pci0000:00-0000:00:02.2-0000:0e:00.0-nvme-nvme1-nvme1n1-nvme1n1p1.device
1min 7.160s dev-disk-by\x2did-nvme\x2dSamsung_SSD_990_EVO_Plus_2TB_S7U7NU0Y740046D\x2dpart1.device
1min 7.160s dev-disk-by\x2dlabel-SYSTEM.device
1min 7.160s dev-disk-by\x2dpartlabel-EFI\x5cx20system\x5cx20partition.device
1min 7.160s dev-disk-by\x2dpath-pci\x2d0000:0e:00.0\x2dnvme\x2d1\x2dpart-by\x2dpartlabel-EFI\x5cx20system\x5cx20partition.device
1min 7.160s dev-disk-by\x2did-nvme\x2dSamsung_SSD_990_EVO_Plus_2TB_S7U7NU0Y740046D_1\x2dpart1.device
1min 7.160s dev-disk-by\x2duuid-E88D\x2d281A.device
1min 7.159s dev-disk-by\x2did-nvme\x2dSamsung_SSD_990_EVO_Plus_2TB_S7U7NU0Y740046D\x2dpart4.device
1min 7.159s dev-disk-by\x2ddiskseq-2\x2dpart4.device
1min 7.159s dev-disk-by\x2did-nvme\x2dSamsung_SSD_990_EVO_Plus_2TB_S7U7NU0Y740046D_1\x2dpart4.device
1min 7.159s dev-disk-by\x2dpartuuid-72039166\x2d9d28\x2d4356\x2da643\x2d19b6285c792b.device
1min 7.159s dev-disk-by\x2dpath-pci\x2d0000:0e:00.0\x2dnvme\x2d1\x2dpart-by\x2duuid-2AB68BD3B68B9E47.device
1min 7.159s dev-disk-by\x2dpath-pci\x2d0000:0e:00.0\x2dnvme\x2d1\x2dpart-by\x2dpartnum-4.device
1min 7.159s dev-disk-by\x2did-nvme\x2deui.0025385751a189bc\x2dpart4.device
1min 7.159s dev-disk-by\x2dpath-pci\x2d0000:0e:00.0\x2dnvme\x2d1\x2dpart-by\x2dpartuuid-72039166\x2d9d28\x2d4356\x2da643\x2d19b6285c792b.device
1min 7.159s dev-disk-by\x2duuid-2AB68BD3B68B9E47.device
1min 7.159s dev-disk-by\x2dpath-pci\x2d0000:0e:00.0\x2dnvme\x2d1\x2dpart-by\x2dlabel-Recovery.device
bazzite@SectorNik:~$ systemd-analyze critical-chain initrd-switch-root.target
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.
initrd-switch-root.target
└─systemd-resolved.service @2.081s +715ms
└─systemd-tmpfiles-setup.service @1.878s +171ms
└─systemd-journal-flush.service @1.793s +83ms
└─ostree-remount.service @1.781s +3ms
└─var.mount @1.760s +9ms
└─dev-nvme0n1p3.device
bazzite@SectorNik:~$ journalctl -b -u dracut-initqueue --no-pager | tail -100
stu 29 12:45:27 bazzite systemd[1]: Starting dracut-initqueue.service - dracut initqueue hook...
stu 29 12:46:32 bazzite systemd[1]: Finished dracut-initqueue.service - dracut initqueue hook.
stu 29 12:46:32 bazzite systemd[1]: dracut-initqueue.service: Deactivated successfully.
stu 29 12:46:32 bazzite systemd[1]: Stopped dracut-initqueue.service - dracut initqueue hook.
bazzite@SectorNik:~$
And this is what the AI spat out based on that:
Your slow boot is caused by a ~60‑second device wait in the initrd for TPM, serial ports, FUSE, and your Samsung NVMe, not by services in normal userspace.
What the data shows
systemd-analyze time→ initrd = 1min 6s, everything else is reasonable.
systemd-analyze blameshows lots of.deviceunits all around 1min 7s:
sys-module-fuse.device
dev-tpm0.device,dev-tpmrm0.device,MSFT0101:00-tpm…
dev-ttyS0/1/2/3.device(serial8250)Many aliases for your
Samsung SSD 990 EVO Pluspartitions
This pattern is classic for a udev / dracut timeout while waiting for devices, then continuing when the wait expires.The
dracut-initqueuelog is short because dracut itself exits successfully after that long wait; it is not crashing, just timing out on hardware discovery.Likely causes
From similar Fedora/Bazzite and other distro reports:
A device the initramfs thinks it needs (TPM, serial ports, or an NVMe path from an old config) never appears, so udev waits ~60–70s.
Extra device aliases for the Samsung NVMe (by‑id, by‑uuid, by‑label, etc.) all inherit the same timeout, which is why you see many 1m7s
.deviceentries.TPM (MSFT0101) and serial8250 devices are frequent offenders; some systems fix this by blacklisting or telling dracut/systemd to ignore them when not needed.
Concrete next steps to speed it up
These are safe, incremental tests; try them one at a time so you can see which one helps.
Check for stray mounts / crypttab entries
Show
/etc/fstaband/etc/crypttaband look for any entries pointing to disks or labels that no longer exist (old Windows or recovery partitions, unplugged drives, etc.).Comment out any such lines, then reboot and re‑measure
systemd-analyze time.Tell dracut not to care about unneeded stuff (hostonly)
Bazzite uses dracut; on Fedora‑style systems you can enable host‑only initramfs so it only includes drivers for your actual root device:
bash
sudo mkdir -p /etc/dracut.conf.d
echo 'hostonly="yes"' | sudo tee /etc/dracut.conf.d/hostonly.conf
sudo dracut --regenerate-all --forceReboot and check if initrd drops from ~66s to a few seconds.
Experiment with blacklisting troublesome devices in initrd
To test whether TPM and serial ports are the culprits, add a temporary kernel parameter in GRUB:
At GRUB menu, edit the Bazzite entry and append:
text
rd.driver.blacklist=tpm,tpm_tis,tpm_crb,serial8250,serial_coreBoot once with that and see if initrd time collapses.
If it helps, this can be made persistent via a drop‑in in
/etc/kernel/cmdlineor equivalent for Bazzite. Similar approaches are used in other distros to fix long waits on/dev/tpmrm0and serial devices.Regenerate initramfs after cleaning up
After adjusting fstab/blacklists:
bash
sudo dracut --regenerate-all --forceThen re‑check with:
bash
systemd-analyze time
systemd-analyze blame | head -20If you paste
/etc/fstab(and say whether you actually use TPM for anything like BitLocker or secure boot integration), it is possible to give a very precise “remove this line / add this option” recommendation.
Now I don’t know enough if it makes sense or not, but if anyone could take a look and give some comments I’d be grateful.