USB Keyboard Causing Slow Boot

NicWelds

Member
Joined
Mar 24, 2026
Messages
58
Reaction score
71
Credits
448
Running Xubuntu 24.04 on an 8 year old Acer Nitro laptop. No other operating systems installed.

For quite some time now I've been experiencing a seemingly random intermittent delay when my laptop boots. I recently identified it as being caused by my USB keyboard just by observation. The problem never happens when the keyboard is disconnected but happens around 50% of the time when the keyboard is connected.

The delay happens before the GRUB menu. The screen blacklight comes on but the screen stays black for approximately 20 seconds then the Acer logo appear and it stays there for another 10 to 20 seconds. Once grub shows up everything operates at it's normal pace.

So far I've looked through the boot logs but I couldn't see anything obviously wrong in there. I went through the UEFI settings and disabled USB boot with no change. That's the only USB related setting that I could see in there. The keyboard itself works fine. My current solution is to unplug it before starting the computer but I was hoping someone could point me in the right direction to fix it properly.
 


Is there more than one usb port on the laptop?

If so, change ports
 
Simple solution...don't use the USB keyboard.
1774598206870.gif


I have a wireless mouse for my Laptop but I wouldn't use a USB keyboard when there's one on the Laptop.
1774598423242.gif
 
Is there more than one usb port on the laptop?

If so, change ports
I'm pretty sure I tried the other USB ports but there is a USB C port and I do have an adapter. maybe I'll try that.
Simple solution...don't use the USB keyboard. View attachment 30991

I have a wireless mouse for my Laptop but I wouldn't use a USB keyboard when there's one on the Laptop. View attachment 30992
I like my keyboard. I mainly use my computer at my desk so I have the laptop up high to make it comfortable to look at but using the keyboard at that height isn't very comfortable.
 
@NicWelds, your possible solutions are fairly straightforward.

Look in bios to see if there is any setting that affects the keyboard/usb port

Try the other ports again....be sure (it will only take a few minutes) and try the adapted usb c port

Buy a wireless keyboard.(last resort)

either the current keyboard has a fault, or, the usb posts have a fault (look in bios....do other things you plug into a usb port behave correctly
 
No success so far. All USB ports have the same problem and there are no USB related settings in the UEFI.
 
No success so far. All USB ports have the same problem and there are no USB related settings in the UEFI.
Sounds like the keyboard driver is detecting the keyboard and then occupying itself with some checks or processing of some sort before it passes itself on to the system, or something like that :-) .

Here are the kernel parameters that are often used for different issues with keyboards. Not all, if any, will apply in your case. The list is taken from the kernel Documentation:
Code:
    i8042.debug    [HW] Toggle i8042 debug mode
    i8042.unmask_kbd_data
            [HW] Enable printing of interrupt data from the KBD port
                 (disabled by default, and as a pre-condition
                 requires that i8042.debug=1 be enabled)
    i8042.direct    [HW] Put keyboard port into non-translated mode
    i8042.dumbkbd    [HW] Pretend that controller can only read data from
                 keyboard and cannot control its state
                 (Don't attempt to blink the leds)
    i8042.noaux    [HW] Don't check for auxiliary (== mouse) port
    i8042.nokbd    [HW] Don't check/create keyboard port
    i8042.noloop    [HW] Disable the AUX Loopback command while probing
                 for the AUX port
    i8042.nomux    [HW] Don't check presence of an active multiplexing
                 controller
    i8042.nopnp    [HW] Don't use ACPIPnP / PnPBIOS to discover KBD/AUX
                 controllers
    i8042.notimeout    [HW] Ignore timeout condition signalled by controller
    i8042.reset    [HW] Reset the controller during init, cleanup and
                 suspend-to-ram transitions, only during s2r
                 transitions, or never reset
            Format: { 1 | Y | y | 0 | N | n }
            1, Y, y: always reset controller
            0, N, n: don't ever reset controller
            Default: only on s2r transitions on x86; most other
            architectures force reset to be always executed
    i8042.unlock    [HW] Unlock (ignore) the keylock
    i8042.kbdreset    [HW] Reset device connected to KBD port
    i8042.probe_defer
            [HW] Allow deferred probing upon i8042 probe errors

I cannot say which, if any at all, may apply to your hardware, but in the past a few have been necessary for use here.

In my notes I have another parameter: i8042.dritek=1 which resolved a problem for a laptop user but I haven't needed to ever use that one.

Another one someone used successfully was: pnpacpi=off for a keyboard that didn't respond at all on a laptop.

All in all, there's a bit to try out. It's wise to try one option at a time, though multiple options can be useful too, but in the first instance, to see the effects, one at a time makes sense. Some will obviously not apply, but a list is a list, so there you have it.

Edit: for aid is setting kernel parameters one can check out here: https://linuxconfig.org/how-to-set-kernel-boot-parameters-on-linux
 
Last edited:
Sounds like the keyboard driver is detecting the keyboard and then occupying itself with some checks or processing of some sort before it passes itself on to the system, or something like that
You could always replace the keyboard, (just buy a cheapie) or borrow one to see if you get the same result.

Have you made any changes to the kernel being used on your laptop lately?
 
Two key boards on a Laptop is like two of these in a car......
1774827913818.jpeg


1774828003559.gif
 


Follow Linux.org

Staff online

Members online


Top