Internet connection and touchpad not working on Ubuntu 22.04 after a force shut down
After a force shutdown on Ubuntu 22.04, installed on a Lenovo Legion 5, the OS seems to have lost its ability to recognize the built-in touchpad or to connect to the internet.
For the backstory...
The computer was suspended. I went to go wake it up. The power button light indicated that it was awake, but nothing was responding and the screen remained black. Pressing the power button again did nothing, and plugging it in did nothing.
I'd been having issues with the graphics driver, so I assumed that had crashed. I gave it a few minutes to see if anything would happen, but a few minutes later there was no change in status, and I was in a rush because I needed my computer to run stuff for business things. I force shut down the computer by holding down the power button and then rebooted it.
Upon reboot, I discovered that the internet was not working on the device and that the touchpad wasn't working. The mouse wouldn't respond at all.
Since I was in a rush, I shut down the computer again (using the keyboard) and booted up Windows instead. The touchpad and the internet connection worked on Windows just fine.
A few hours later, I booted into Ubuntu again and encountered the same problems. Before all of this, before I had suspended the computer initially, I may have had the touchpad disabled (using the keyboard shortcut for that) because I was doing some keyboard-only use for an accessibility course (I'm fairly experienced on that front but I figured I'd give it a whirl anyway).
Back to later, using the terminal and xinput, I found out that Ubuntu wasn't recognizing that the touchpad existed at all. I did try to reenable it using the keyboard shortcut, but that didn't work, and I couldn't find anything in the settings to enable the mouse.
When I got home, I attached it to an Ethernet connection and tried to run repair packages in recovery mode, but it still wasn't connecting to the internet despite the wired connection and me running the "enable networking" option in recovery mode beforehand.
On a live boot of Ubuntu 20.04, the networking and the touchpad work as expected. I was able to run xinput from my 22.04 filestyem via the 20.04 boot, and the outcome was normal (i.e. my touchpad was recognized), and I verified that the touchpad was set to "enabled". However, upon booting up into the 22.04 system, it still wasn't working.
Is there anything I can do to possibly fix these issues, or is the OS corrupted and I just have to back up my files and reinstall Ubuntu?
1 answer
This won't be an exact answer. I think with the way it's described, there could be many reasons why the issue manifests. However, the good news is that the live ISO works, therefore the problem is NOT a bug in the Linux kernel or Ubuntu OS.
I think that if you did a fresh install of Ubuntu, your hardware would probably work again (there are exceptions - for example my laptop's wifi works with the arch live ISO, but the base arch install needs some additional setup for it to work). Unfortunately you would also lose your installed packages and your user configuration. If that is okay, stop reading here and do a fresh install, because IIRC it takes ~20 min to install Ubuntu and it is very unlikely that you can do troubleshoot this in less time.
To avoid a fresh install, you would have to systematically compare the live env and your own system. Luckily in Linux everything is a file, so you can use tools like diff for this.
There are going to be many differences between the live ISO and your system. I would say the first step is to figure out whether the issue is system level or OS level. Simply create a new user account, reboot (in case your normal account somehow modifies the system on login) and login as the new one. If the issue persists (I'm guessing it will), you can consider it system level.
- User level configs are, in the vast majority of cases, under
~. If the problem is in your home dir, possibly somewhere like~/.config. List all dirs withls -a ~and start copying them over one by one into the new user until the new user also breaks. You can then expeirment with subdirs until you find the exact file and line that causes it. - System level configs are mostly in
/etc. There are also things like the configuration of the kernel or bootloader, which are elsewhere, but the good news is that usually these in turn are also controlled from/etc. For example,/boot/grub/grub.cfgcontains Grub settings and the initial image but they are generated from/etc/default/grubwithupdate-grub. So you can diff the live ISO's/etcvs your existing system's/etcand see if you find anything suspicious. You can then try to copy over the live ISO's version of the file to see if that fixes it. Be careful though, some files in/etcmight break your system if you revert them to the live ISO's version (for example,/etc/fstabon the live ISO will be wrong for your actual OS), so read up on each file before messing with it.
Also, if the problem is user-level that means your existing home dir is "clean" (which is likely - it's hard to disable devices from ~). That means that if you do decide to do a fresh install, you can simply copy over your old home dir to the new install, and restore your settings. Your packages will still be a lost, but you can export a list of them and then batch-install it in the new OS (I would suggest posting a separate question for how to do this).
0 comment threads
1 comment thread