I’m trying to install Linux Mint 22.3 Cinnamon on an older Gigabyte 990FXA-UD3 R5 system. The USB keyboard, mouse, and installer drive work until the live desktop loads, but the installer then reports repeated “device not accepting address” errors and all USB input stops working. Rebooting restores USB in Windows, but starting the Mint USB leads to the same problem. What should I check next?
Mint live session loses all USB input during install, any ideas?
Answers
First pin down where the failure happens. The Mint desktop launched from the USB is a temporary live session, not an installed system, so restarting it will just start that session again. If input dies there, the installer cannot finish, and Windows working after a reboot does not tell us what is failing in Linux.
If possible, try another USB stick and another port, especially a rear motherboard port rather than a case port or hub. Also note whether the keyboard and mouse stop at exactly the same time, and whether the drive light or screen continues responding. Those details can help distinguish a controller issue from a bad connection or installer media problem.
Reply to this answer
That motherboard and CPU are old enough that I would check firmware settings before chasing random boot flags. Look for USB legacy support or USB emulation and make sure it is enabled. If the firmware offers a compatibility option for booting USB devices, try it as well. Firmware menus vary, so don’t change unrelated storage settings unless you know why.
Try the compatible boot option again after checking those settings. If you can, test the same Mint USB on another computer, or try a different Mint image or USB writer. That gives you a quick way to tell whether this is tied to the PC or the boot media.
Reply to this answer
Can you get a shell in the live session before USB stops responding, or switch to a text console with a keyboard shortcut? If so, collecting the hardware and kernel messages would be useful. For example, `lsusb` can show what USB devices are detected, and system logs may include the controller errors around the time input disappears.
If the ports stop before you can run anything, the exact point in boot where it happens is still useful. The error alone does not identify a specific fix, and different boot options can affect hardware differently.
Reply to this answer
One practical test: boot with only a wired keyboard plugged into a rear USB 2.0 port, if the board has one. Leave the installer stick in a different rear port and remove other USB devices. Avoid front-panel ports and hubs for this test. If the keyboard still drops out, that’s a clearer result than testing several devices at once.
Reply to this answer
Add your answer
Answers are reviewed before publication.
C5__Latency:
The compatibility boot option gives the same result. I’ll check the USB settings in firmware and test another stick if I can.