Crazy Long Boot Time (Almost 3 Mins w/NVMe)

General system Kernel, boot, graphics & hardware
1

So my system has crazy long boot times.
When booting it gets stuck running something that starts a timer which has to run down before it can continue the boot process, but whatever it is doing is both slow and I suspect also broken.

It has done this on my previous two installs of EndeavourOS to bare metal internal SSD’s and it continues to do it after this current 3rd install onto a external SSD connected via USB.

The issue is something that only happens with EndeavourOS as other distro’s I have tested don’t have this issue, whatever the issue is, the other distros I have tested include:

  1. MXLinux
  2. Tuxedo OS
  3. Debian Linux
  4. Fedora KDE
  5. Bazzite KDE

Also note that although I haven’t tested it recently, back when I did use Manjaro LInux I never had this issue, but back then when I switched to EndeavourOS I immediately encountered this issue with the new install within as week of installation of EndeavourOS, so this is a long standing issue that has now been going on for YEARS, I have just not had the patience to face trying to fix it.

I had a look at what it says every time it boots and it looks like it is something to do with my drives, but I still don’t understand what it is or how to diagnose the issue yet alone fix the issue.
I have spent a few hours looking online across many many months and haven’t yet found anyone with my exact issue.

I have got a copy of some system logs which I will try to attach to this post via a link, hopefully they contain information that is useful in finding the cause.
As it currently stands my boot times average about 2 Minutes and 50-ish seconds, sometimes it can be a second or two quicker or slower but it is already so long that I haven’t ever noticed it being slower or faster due to how long it already takes.

This issue happens on a fresh install of EndeavourOS or at least within 2-3 reboots when first setting up the system, so whatever it is, it seems to be automatically getting configured without my input and then just binding itself to the system.

Here is the link to the logs:
https://0x0.st/8tbC.txt

Thanks to anyone who can help.

2

Opinion: 11 seconds isn’t bad (blame). I have no experience with encrypted drives, but I’m gonna bet it’s a complication there.

3

11 seconds for one component of the boot process? Given I used to boot Windows 10 from a SATA 6Gbps drive connected via USB in under 11 seconds total boot time I would argue that 11 seconds is pretty slow.

But that 11 seconds is nothing compared to the mountain of 5 second actions taking place that add up to well over 1 minute 30 seconds, something is not right, it keeps on saying it MUST take 1:30 to do a task during the boot process, no explanation as to why, and it seems to repeat the text it shows during boot too like it is looping on itself.

so something is definitely a miss.

4

Yes, but it doesn’t show in the logs provided which imply the system is ready to use in 11 seconds.
We can only go on what you give us…

5

What doesn’t show?
The 5 seconds instances do, right below the 11 second task it has a bunch of tasks taking between 4.7 seconds - 5.6 seconds each and it has what I would estimate to be about 20-30 entries of that going on.
The actual decryption takes 11 seconds at most per drive, so like I say something else is going on to cause all those similar actions to mess up during the boot process.

6

systemd-analyze critical-chain ?

7

Here are the results of the command:

The time the unit took to start is printed after the "+" character.

graphical.target @1min 32.524s
└─power-profiles-daemon.service @1min 32.467s +55ms
  └─multi-user.target @1min 32.462s
    └─cups.service @1min 32.407s +51ms
      └─network.target @1min 32.395s
        └─wpa_supplicant.service @1min 32.339s +53ms
          └─basic.target @1min 31.058s
            └─dbus-broker.service @1min 31.008s +44ms
              └─dbus.socket @1min 30.982s
                └─sysinit.target @1min 30.950s
                  └─tpm2.target @1min 30.903s
8

This looks to me to be the issue.

9

How could I look into this further?
What about TPM2 might be causing the issue?

I have a hardware TPM 2.0 Module installed, and strangely I don’t have secureboot enabled with EndeavourOS as it isn’t an option (or wasn’t when I set this system up) in the installer. I don’t think EndeavourOS even officially supports SecureBoot by default, it is something I would need to manually configure, assuming of course that the TPM2 it references is linked to secureboot not being enabled (which would be ironic given it isn’t in use).

10

I have found this article and I am going to try the suggestions mentioned here to see what results I get.
Article Link:

Would TPM2 trigger disk issues though? How would that work I wonder?

11

I don’t use TPM 2.0 so I am afraid I cannot be of further help. I just notetd that that .target required a significant amount of time to start.

Here is what Archwiki says about TPM. May be relevant for you. Specifically the LUKS part.

12

No, for the time in the userspace.

I think you should run the command :

systemd-analyze

with no option, so you can see the time spent by the bios, the bootloader, the kernel and the init.

1 Like
13

I followed what was suggested here by running the following command and then rebooting my system, I had the quickest Linux Boot Times I have ever experienced with any system.

The command I ran:
systemctl mask dev-tpmrm0.device

With that command my problem has resolved itself.

Thank You to Everyone that helped guide me to the solution that I needed.
I wish you all a great day, Peace!

UPDATE:
Fixing this problem also fixed another issue I was having which can be found here… This has been one wild ride that is for sure! -

1 Like
14

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.