Skip to main content
Topic: Kernel 5.4.1 broke sway (Read 168 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Kernel 5.4.1 broke sway

pacman -Suy installed kernel 5.4.2, and then sway could not start. I resolved this by installing linux-hardened which uses an older 5.3 kernel.

If I try to start sway, it seems like nothing happens. Instead of starting the wayland GUI, the machine just keeps displaying the console, although the cursor stops blinking. It is possible to switch to another virtual console and kill sway - so the machine is not hanging. "strace sway" seems to indicate that sway is looping, doing "recv_msg" or some such and never proceeding.

Is there a way to get the 5.4.1 kernel package that the upgrade removed?

Re: Kernel 5.4.1 broke sway

Reply #1
Do you have multiple GPUs on your machine? Try specifying a specific GPU with "WLR_DRM_DEVICES=/dev/dri/card0 sway" (change card0 to card1 or whatever) if you do. On my laptop, sometimes the card order switches and I have no idea why. When it tries to launch with the wrong GPU (the nvidia optimus one), it has the behavior you described (tty freezes but you can just switch to a new one and kill the process).

I'm running 5.4.2 and sway right now just fine (although I'm technically using a version compiled from git and not the release version but still).

Re: Kernel 5.4.1 broke sway

Reply #2
5.4.1 kernel:
5.4.1 kernel headers:

Alternatively, try testdisk / photorec and search for only .xz files? But as the files would not have their original names you would need to examine the contents or something to find the right one. Probably quicker to use the links above.
Code: [Select]
$ for f in recup_dir.*/*; do echo $f >>outputfile.txt; tar -tf $f 2>/dev/null >>outputfile.txt; done
Then search the resulting file for "linux" or something and see what the file name was. But when I tried this out of interest I didn't actually recover any old kernel packages, but then I don't have lots of free space on this partition plus I recovered to a dir on the partition itself to try out the theory so was overwriting some of the deleted items as I recovered others. Didn't take long with an ssd, only a few minutes.