This just happened to me. I got it working, but I am baffled as to what happened. Can anyone suggest an explanation?
Generally, I keep a headset plugged into the USB but will occasionally unplug it for listening. This is Ubuntu Maté 18.04.
I was playing around, reading up on Linux arcana (minor, not major), playing the occasional YouTube video. When I decided to plug the headset in, the sound did not switch over as it usually does. When I opened he Sound properties, the headset (out and in) were both disabled despite repeated unplugging and replugging.
I tried suspending, but when I pressed enter to revive it, the screen was a pattern of black and white rectangles, and totally unresponsive. Terminal would not open, keyboard lighhtes did not come on.
I did the drastic step of holding down the power key and restarting. FSCK ran, found 9 inodes with the wrong dtime, fixed each of them and exited with status = 1
It booted OK, all systems working.
But what happened?
Was there anything else I could have done?
I welcome suggestions on another subject description, if that would help others…
the first few times my screen became unresponsive, i did the very same thing. i button-punched it off and dealt with the consequences when i restarted which often involved needing to run fsck to recover. some time after that i discovered tty’s by accident i believe.
my first thought is that if your screen becomes unresponsive, it would be a good idea to make your way into a tty by pressing ctrl + alt + F2-F6 (one of the keys F2 through F6, not all five). if i recall correctly, the commands available in tty are limited so i would suggest just rebooting. once you get back into the desktop, you can do your best to troubleshoot.
as far as the question of what happened goes, i think you would need to look at system logs. the first two methods i usually use are dmesg and journalctl. dmesg --level=err is usually a shorter list and should point out any major issues. dmesg --level=warn on my system is a much longer list and can be quite extensive. one of the issues with dmesg output is that it doesn’t show a timestamp. adding the -H option will do so . journalctl is usually much longer even still. journalctl -r will at least give you results in reverse chronological order so the most recent events show first.
it occurred to me while writing this part that if the screen lockup occurs again (here’s to hoping it doesn’t and was a one-off event, but just in case), you could run journalctl -r in the tty to see if anything stands out before a reboot.
i have a log viewer called lnav installed that makes looking through most of that a bit easier in case that is of interest.
1 Like
sorry to keep adding more posts, but i thought of one more place to look. in your home folder there should be a hidden file called .xsession-errorrs. that may also have info on why your desktop stopped responding.
1 Like
Here is the result of this command:
dmesg -H --level=error
cliff@cliff-desktop:~$ dmesg -H --level=err
[Jun 9 17:12] systemd-fstab-generator[290]: Failed to create unit file /run/systemd/generator/dev-disk-by\x2duuid-581aee02\x2ddc67\x2d4f06
[ +0.285292] systemd[283]: /lib/systemd/system-generators/systemd-fstab-generator failed with exit status 1.
[ +34.766457] usb 1-1.1: 2:1: cannot get freq at ep 0x1
[Jun 9 17:13] usb 1-1.1: 2:1: cannot get freq at ep 0x1
[ +0.002107] usb 1-1.1: 1:1: cannot get freq at ep 0x81
The freeze-up was probably at 17:12, as indicated, but I don’t know how to interpret the rest.
can you paste your fstab? it can be found in /etc.
is swap actually listed twice?
1 Like
No, there is one swap on /dev/sda5 and another on /dev/sdb5. The one I use is sdb, and some other distros to try out are on sda. Long story why that is.
but they are both listed on your fstab as shown above?
1 Like
Well, I’ll be!!
I had no idea.
Is this an issue? Or just a peculiarity?
i’ve never used a system with two different swap partitions, but they definitely (most probably? Universally Unique identifier) shouldn’t have the same uuid. my suggestion is to check the uuid of the one you want to use with ubuntu. blkid -o list will show them for you.
1 Like
The SWAP on /dev/sda5 is not listed at all, while the /dev/sdb5 one is identified as [SWAP]
I take it that is good news, and the extra UUID in fstab is just redundant.
redundant, yes, but i’m not sure in a purely benign way. my guess is that’s where the dmesg error comes from as at startup your system is trying to say two different partitions with the same “name” are swap.
Would it be safe to just edit that entry out? or maybe REM it out?
i believe the safer path would be to comment out that line with a # and then reboot to see if the dmesg error returns. i would have a backup in place just in case though. i always make one before playing with any system setting. in theory you don’t need swap to boot, but i would make that backup just to be extra sure.
1 Like
I think the problem is either solved or under control.
- I REMed out that UUID with # and it booted without error.
- The only dmesg error left is this:
usb 1-1.1: 2:1: cannot get freq at ep 0x1
This type of error is reported, in many variations, as a problem with audio. Sometimes playback, sometimes a sound card, sometimes a headset. That is also the most immediate thing that triggered the problem, when I plugged in the headset after playing back awhile thru speakers.
But how to keep it from happening again?
where are you seeing this reported?
the complete error
usb 1-1.1: 2:1: cannot get freq at ep 0x1
is appearing entirely in Russian sites.
The last section:
cannot get freq at ep 0x1
is found a bit more frequently.
Finally, changing the numbers thus:
cannot get freq at ep __ x __
yields lots of discussions about audio difficulties.
Where? Hey, just google string searches in quotes.