Greeter slow to come up after boot

MNT Reform
1

After an update some weeks / months ago - I don’t recall when exactly - there started to be a weird pause after the machine is done booting up before I can log in or do anything at all.

This seems to happen with any greeter - be it gdm3, greetd. or no greeter at all and just plain old text-mode getty: the kernel boots up, systemd starts all the services, then I either get a blank text screen with a cursor at the top, or a blank graphical screen with the mouse cursor, for 10 to 15 seconds, until a login prompt or a login screen finally shows up. During that delay, the machine seems properly frozen: I can’t seem to switch VTs or anything.

I’ve been looking up and down the internet for a solution to this, but I can’t seem to find anything - at least nothing that solves the problem. I’m starting to wonder if it’s Reform-specific. Has anybody noticed this?

2

You can try using systemd-analyze to find any service that takes too much time, and slows up your boot time.

3

I find systemd-analyze generally not terribly useful, because it tells you how long things take to start, but it totally fails to tell you that they can very well be starting in parallel.

systemd-analyze critical-chain is the most useful option, but that doesn’t mean I can do something about it. For instance, on my machine, it says:

graphical.target @5.619s
└─power-profiles-daemon.service @5.446s +170ms
  └─multi-user.target @5.440s
    └─lm-sensors.service @3.218s +2.219s
      └─basic.target @3.135s
        └─sockets.target @3.134s
          └─uuidd.socket @3.132s +71us
            └─sysinit.target @3.095s
              └─systemd-binfmt.service @2.699s +391ms
                └─proc-sys-fs-binfmt_misc.mount @2.893s +191ms
                  └─systemd-journald.socket @1.141s +107us
                    └─system.slice @1.011s
                      └─-.slice @1.011s

multi-user is al but mandatory, and I’m 99% certain Bad Things™ will happen if I knock out lm-sensors or power-profiles.

As for graphical - that’s Wayland > XWayland > DM / greeter starting up, I believe that’s - at least partly - the bit that somehow makes the machine unresponsive for x number of seconds, and that’s the bit I’ve been trying to speed up by applying various tricks I found on the internet, such as disabling accessibility in gdm3, installing a native Wayland greeter to avoid starting XWayland, etc… But there’s nothing for it: whatever I do, there is always that pause of several seconds.

4

I try to remember to regularly let gitlab keep system image artifacts and I listed them in this table:

You could try out and benchmark if things were different a while ago.

5

This has “brick the laptop” written all over it :slight_smile:

I can live with a few seconds delay each time I boot. So I think I’ll pass.

6

@O.o what comes immediately to mind:

  • Do you use an encrypted SSD?
  • Do you have “aes” showing up in cat /proc/cpuinfo?
  • If not, please sudo reform-flash-uboot emmc
7
  • No
  • Yes
  • Why? The machine already boots off emmc. Besides, it’s not a kernel boot lag but some userspace stuff taking more time than it should to start. Not to mention, this lag started after an apt upgrade.
8

I think minute’s theory was that missing aes (which happens with certain older u-boot blobs which include TF-A) would result in the CPU doing more work than it otherwise would by handling aes in hardware. Thus probably also the question about encrypted SSD. We have a check for this now as part of sudo reform-check but you already checked manually.

9

Ah right okay, I get it.