I’ve been living with my old Dell XPS 15 for a long time now, more than 10 years. It’s not young, but it’s still fast by modern standards, and it’s loyal. Over the past months, it has even become one of the main characters in one of my recurring blog themes: fixing kernel issues on Ubuntu 24.10 and understanding what really happens when Linux boots.
At some point, I was confident. Maybe too confident.
I had studied the boot process in detail — firmware handover, GRUB, kernel loading, initramfs, device initialization. I wrote guides, tested scenarios, broke things on purpose, and fixed them again. I honestly believed I understood the boot process well enough to predict its behavior.
Then one morning, my laptop proved me wrong.
I powered it on, expecting the usual quick flash of the GRUB menu followed by an automatic boot. Instead, GRUB stopped. Completely. The menu appeared and just stayed there, waiting for me to choose a kernel — forever.
No countdown.
No timeout.
No automatic boot.
Just silence.
At first, I wasn’t worried. This was Linux, after all. My brain immediately jumped to the most obvious explanation: updates. Surely a kernel update had slipped in, added a new entry, and confused GRUB about what to boot by default.
I checked everything.
Installed kernels? Normal.
Default entry? Correct./etc/default/grub? Exactly as it should be.
Regenerate GRUB just in case? Done.
Nothing changed. GRUB still waited for me like a very polite but extremely stubborn butler.
That’s when suspicion shifted to the BIOS.
Recently, I had been experimenting with power and USB settings. My goal was to keep the laptop permanently connected to a USB-C docking station and wake it from suspend using a keyboard or mouse. It sounded simple. It wasn’t.
Most of my input devices are Bluetooth, which already makes wake-up behavior unreliable. I had tweaked several BIOS options trying to make it work. So naturally, I assumed I had broken something there.
I restored the BIOS configuration back to what I remembered as the original defaults. Rebooted.
GRUB was still there.
Waiting.
Judging.
At this point, the situation became surreal. Nothing in software explained the behavior. GRUB was configured correctly, the system was clean, and yet the bootloader refused to proceed unless I manually selected an entry.
Then, almost accidentally, everything changed.
I picked up the laptop to move it — and noticed something sticking out of the side. A tiny USB dongle. The receiver for my keyboard. Left there from some earlier experiment, completely forgotten.
On a whim, I pulled it out.
Rebooted.
GRUB appeared.
Started counting down.
Booted automatically.
Just like nothing had ever happened.
The culprit wasn’t a kernel update.
It wasn’t GRUB configuration.
It wasn’t the BIOS.
It was a tiny USB input device.
As it turns out, GRUB treats certain input devices very seriously. If it detects active or persistent input hardware, it may decide that a human is present and waiting — and therefore disable the timeout entirely. From GRUB’s point of view, this is correct behavior.
From my point of view, it looked like the bootloader had achieved inner peace and decided to meditate indefinitely.
By the time I realized this, my head was already full of half-remembered commands, configuration files, and theories that turned out to be completely irrelevant. And that’s precisely how the following post was born.
The lesson is simple, and yet painfully familiar:
not every Linux problem lives in a config file 😄.
Sometimes the solution isn’t another command, another log, or another reinstall. Sometimes it’s just removing a small piece of plastic from a USB port.
And sometimes, Linux reminds you — very gently — that confidence is good, but humility boots faster.