I have no problem with the time it takes to boot to the login screen but once it has the system is frozen (no mouse or keyboard control) on the login screen for about 30 seconds.
The funny thing is that if I modify the boot to go to the command line and then do an
init 5
then there seems to be no problem with a delay.
I don’t see any delay in the system logs but here are the logs so you can see for yourself - any clue as to what could be the cause of this would be appreciated.
I’ve never seen that kind of systemd-analyze output (firmware/loader/kernel/initrd/userspace … I only ever get kernel/initd/userspace, that’s it). Obviously an overwhelming span of time is spent within firmware initialisation (»24.411s (firmware)«, much too long) which I would find inacceptable even for a complex server setup (with non-local iSCSI/RAID hardware and/or NUMA and/or external clusters of computing cores on gfx cards whatnot) nowadays. Frankly, this feels more like a long timeout after not being able to find some missing firmware. What could it be?
Reg_gie, could you describe your hardware in more detail, please?
During Leap 15 installation, was any hardware attached that now isn’t anymore?
For comparison, here’s my rather minimal setup (4–5 years old Core i5, Samsung SSD, Mini-ITX ASUS board, NVidia 1050, 8GB RAM):
▶ **systemd-analyze time**
Startup finished in 215ms (kernel) + 727ms (initrd) + 748ms (userspace) = 1.691s
rig:~ ▶ **systemd-analyze blame**
531ms dev-sda1.device
290ms display-manager.service
172ms systemd-journal-flush.service
112ms NetworkManager.service
95ms systemd-udevd.service
81ms upower.service
71ms polkit.service
45ms klog.service
41ms systemd-logind.service
26ms systemd-udev-trigger.service
23ms rtkit-daemon.service
20ms user@1000.service
19ms sys-kernel-debug.mount
18ms dev-hugepages.mount
17ms udisks2.service
17ms systemd-remount-fs.service
16ms systemd-modules-load.service
14ms systemd-tmpfiles-setup.service
12ms systemd-tmpfiles-setup-dev.service
12ms dev-mqueue.mount
11ms systemd-update-utmp.service
10ms systemd-fsck-root.service
10ms systemd-tmpfiles-clean.service
9ms systemd-sysctl.service
9ms systemd-journald.service
6ms dracut-shutdown.service
5ms dev-disk-by\...]08ff.swap
4ms systemd-random-seed.service
3ms systemd-user-sessions.service
2ms systemd-update-utmp-runlevel.service
2ms kmod-static-nodes.service
1ms systemd-vconsole-setup.service
▶ **systemd-analyze critical-chain**
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.
graphical.target @745ms
└─display-manager.service @454ms +290ms
└─systemd-user-sessions.service @450ms +3ms
└─network.target @449ms
└─NetworkManager.service @337ms +112ms
└─dbus.service @302ms
└─basic.target @301ms
└─sockets.target @300ms
└─dbus.socket @300ms
└─sysinit.target @300ms
└─swap.target @300ms
└─dev-disk-by\…]08ff.swap @294ms +5ms
└─dev-disk-by\…]08ff.device @294ms
(These are values from this morning; my best boot time under Leap 15 was 1.378s about a week ago; I’ve adopted several boot-time optimisations, e.g. generating a custom, uncompressed initrd using dracut etc.)
As systemd is not showing a possible culprit I would look at the boot log using “sudo journalctl -b” and keeping the time in mind, check if you see any suspicious messages around the 30 seconds freeze.
I suggest you try booting with “plymouth.enable=0” on the kernel command line. This is just as a test, to see if plymouth is involved.
On the boot menu, hit ‘e’. Scroll down to the line that starts “linux” (or possibly “linuxefi”). Scroll to the right. If there is a string “splash=silent” replace that with “plymouth.enable=0”. Otherwise just append " plymouth.enable=0" to the end of the line. Don’t include the quotes that I show there.
I remember seeing something similar on a system with a fuzzy bluetooth adapter that on occasion hijacked the USB bus for tens of seconds preventing the keyboard input from being read during that time.
If that is your case, make sure that USB peripherals, even internal ones, are disabled and see if that makes a difference.
Nope, no change in hardware with the only exception being the usb stick that I used into install Leap but that is disabled in the repo. manager so I don’t see that being an issue. Here is a summary of my hardware:
So I rebooted and took note of exactly when it froze and then looked with “sudo journalctl -b” and although this doesn’t represent the fully 30+ secs. it does cover about 20 secs so it could be something to do with it. The only problem is I don’t know how to determine what should be or is at usb 3-10. I tried putting “usbcore.autosuspend=-1” on the kernel boot command line but that didn’t make any difference.
Jan 21 20:01:05 quark NetworkManager[1515]: <info> [1548126065.3405] manager: NetworkManager state is now CONNECTED_GLOBAL
Jan 21 20:01:05 quark nm-dispatcher[1773]: req:4 'connectivity-change': new request (3 scripts)
Jan 21 20:01:05 quark nm-dispatcher[1773]: req:4 'connectivity-change': start running ordered scripts...
Jan 21 20:01:08 quark kernel: usb 3-10: device descriptor read/all, error -110
Jan 21 20:01:08 quark kernel: usb usb3-port10: attempt power cycle
Jan 21 20:01:09 quark kernel: usb 3-10: new high-speed USB device number 9 using xhci_hcd
Jan 21 20:01:14 quark kernel: usb 3-10: device descriptor read/8, error -110
Jan 21 20:01:20 quark kernel: usb 3-10: device descriptor read/8, error -110
Jan 21 20:01:20 quark kernel: usb 3-10: new high-speed USB device number 10 using xhci_hcd
Jan 21 20:01:25 quark kernel: usb 3-10: device descriptor read/8, error -110
Jan 21 20:01:30 quark kernel: usb 3-10: device descriptor read/8, error -110
Jan 21 20:01:30 quark kernel: usb usb3-port10: unable to enumerate USB device
I pulled up my motherboard layout and traced USB 3-10 and it goes to the USB connectors on the front of my case and there is nothing plugged in there. It’s possible that the port is just bad so I’m going to disable it in my BIOS and see if that makes any difference and then I’ll edit this with the result.
Okay that didn’t work it’s still detecting the port. Come to think of it I remember thinking that one or two of the front ports wasn’t working anymore, this might be a hardware failure.
Is there anyway to tell Leap to ignore/not wait on a particular USB port?
Funny enough before I saw this answer I just changed my CPU cooler, the pump was dying and the new one had a USB connection… one with LEDs is not something I wanted it was just what Corsair had available as a warranty replacement, anyway, I had no free USB ports on the mother board so I pulled the plug to ports 9/10 which wasn’t the USB 3.0s going to the front but the 2.0 ones that were going to spare unused USB ports on the back. I plugged in the USB connection from the Corsair cooler and the problem just went away.
How never used ports being changed out could fix this problem I don’t know but it’s fixed.