img | ||
README.md |
Linux on the Lenovo ThinkPad Z13
Unfortunately, the ThinkPad Z-series looks to be dead. Lenovo has not announced a third generation despite 2 new generations of CPU coming out. I was really looking forward to replacing this first-gen unit when the new ones came out, but that will not be possible.
12/25/2024 - Update: Debian Sid had a nasty habit of getting the /boot/ partition filled up. I reinstalled NixOS but the ddterm
extension I have grown to love didn't work correctly; I found several Issues pages about it where people had identical problems but they were all marked "solved" in older versions of NixOS and none of the workarounds listed in there got the thing working properly.
That said, I am back on Fedora. The Howdy beta version was never properly packages for Debian so I could never get facial recognition authentication to work. Fedora lags behind Debian Sid by maybe a week (at least in regards to kernel packages) and frankly, I've grown accustomed to dnf
at this point. Arguably, dnf
has a superior search to apt
and I have found that Fedora's automatic search for missing packages when running commands to be fantastic.
I do genuinely miss the snapshot-style versioning in NixOS. I know that Fedora Silverblue exists, but Flatpak versions of Firefox don't work with my password manager extension (KeePassXC-Browser) and I do like ot have multiple copies of Firefox, which looks like a pain in Fedora Atomic versions. Maybe I'll give it a shot eventually - I'm not particularly fond of the password manager I'm using, as-is.
11/28/2024 - Update: I made an attempt to try out Debian Stable, but issues did arise with suspend almost immediately, so I just went back to Sid. I have had one failure to wake so far, which, frankly, is better than any OS prior even with all the workarounds I tried to implement.
11/22/2024 - Update: I'm back on Debian Sid. So far, so good - but there's still testing to be done, especially in regards to suspend.
The short and sweet (as of April 28, 2024): Fedora seems to be the winner here. It has so far required the least amount of finagling to get things working (particularly Howdy), it hands-down has the lowest power consumption, and has more software support than either Debian (disappointingly - as this is what all of my server boxes run) or NixOS (at least for standard repos.) Arch has as much up-to-date software, but is generally harder to configure and has more update issues.
There is pretty much always a chance I'll return to NixOS, as it was the most reliable and configurable, but new issues are more difficult to address when they come up.
NixOS
On NixOS, I had power issues any time I switched off of the 6.5 kernel. I think that I may have found a fix for this on Arch, but given the amount of work it would have taken to rapidly test fixes, I likely never would have gotten there.
It was actually demoralizing to realize I had to give it up - but I just could not take it any longer. Arch is quite literally the opposite - not exactly stable, but very forgiving for small mistakes and quick to test new packages.
Arch Linux
I'd been using Arch as my primary OS for about five years before switching over to NixOS. At that point, I was tired of the huge amount of updates that had to be done every week (I made extensive use of the AUR and build a lot of packages from source, foolishly.) One thing I have learned from my time on NixOS is that less is more - the bloat of unnecessary packages would create unmanageable tangles of packages.The Nix package manager was a godsend for this - the ability to just try a package in a temporary environment made so I didn't need to install bizarre esoteric software I would only use once.
However, the Nix package manager still works great on Arch!
Fedora
So, on to Fedora. Arch proved annoying, again. Whereas things were always available, configuration and dependencies ended up being hellish. So, on to Fedora.
Configuring Howdy in Arch was fairly straightforward with some instructions form the Arch Wiki (which also broke on an update literally the next day), but it was a different story in Fedora. After adding the howdy-beta COPR repo, installation was straightforward and face validation via sudo worked great - but it simply wouldn't work at the GDM login screen.
The trick here was to setup an SELinux module as follows:
#Turning off SELinux
sudo setenforce 0
#open a new terminal window and run a sudo command to kick off howdy authentication - this teaches SELinux how it works, I guess
sudo ping google
#Turn SELinux back on
sudo setenforce 1
#This generates a security module, which we'll import next
ausearch -c python3 | audit2allow -m howdy >howdy.te
sudo checkmodule -M -m -o howdy.mod howdy.te
sudo semodule_package -o howdy.pp -m howdy.mod
sudo semodule -i howdy.pp
Source: linuxreviews.org / archive.is
Debian
My love for apt
and hate for dnf
have both been wildly overstated. Debian Sid has problems that make it unusable as a laptop OS for me, at least on this laptop.
Everything comes back to Debian. All the packages are for Debian (or Ubuntu). Chasing my tail in circles to get to the point of any issue while hoping that Fedora's pretty-up-to-date-but-not-quite-up-to-date packages would work have driven me insane. I hate dnf
, I hate RPMFusion. Debian let me switch to "unstable" with just a few little switches and now everything is hunky dory.
Maybe next I'll install Ubuntu and actually just enjoy a functional OS instead of being a freak.
Enable the fingerprint reader with the following:
sudo apt install fprintd libpam-fprintd
Miscellaneous Fixes and Tweaks
GPU Crashes
12/25/2024 - Update again: The problem came back with kernel version 6.12. The same fix still works. The issue happened on both Debian and Fedora, so it seems like it's in the kernel itself.
11/22/2024 - Update to all of this: This issue seems to have either a.) eventually killed the motherboard AND display panel, or b.) be completely unrelated and I have a SECOND dying motherboard and display panel, as the issue came back even with this fix applied. Lovely! I'm trying out Debian Sid for the time being to see if it's any more reliable. For now, this fix is not applied.
Starting with Linux kernel 6.1, "Panel Self Refresh" or PSR, will cause crashes. You must stop this from running in order to get reliable resume.
Sometimes this causes awful performance, sometimes the screen displays graphical glitches (which I was interpreting as contrast issues.) On occasion, I have also experienced random graphical glitches (mostly at the login screen) and occasional GDM crashes.
A new kernel paramter needs to be set; we can do it in Fedora like so. First, edit /etc/default/grub
and add the following to GRUB_CMDLINE_LINUX
amdgpu.dcdebugmask=0x210
Then run the following commands to rebuild GRUB_CMDLINE_LINUX
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
sudo dnf reinstall shim-\* grub2-efi-\* grub2-common
Suspend Issues
11/25/2024 - Update: This still happens from time-to-time, but it is fairly rare. The udev rule still needs to be applied to create some sense of stability, however.
11/22/2024 - Update: Still testing, but this issue has not come up during a full day of use on Debian Sid running kernel version 6.11.9.
As of April 2024, if you run a kernel newer than 6.0, chances are that you NEED this to have sleep work properly!
So, as mentioned earlier, all versions of the Linux kernel (with the bizarre exception of 6.5) would cause my laptop to occasionally fail to wake from sleep (or go into sleep - I never got this nailed down, since Nix made rolling back very very very simple.) What seems to have worked (as of April 29, 2024 on kernel version 6.8.7):
#/etc/udev/rules.d/99-avoid-i2c-wakeup.rules
KERNEL=="i2c-ELAN06A0:00", SUBSYSTEM=="i2c", ATTR{power/wakeup}="disabled"
NixOS udev rule: Things are a little different in NixOS, since you cannot just create a udev *.rules
file. Add the following ot your configuration.nix
file:
services.udev.extraRules = ''
KERNEL=="i2c-ELAN06A0:00", SUBSYSTEM=="i2c", ATTR{power/wakeup}="disabled"
'';
Source: Arch Wiki / archive.is
ℹ️ What is this doing?
i2c-ELAN06A0:00
is the hardware address of the haptic trackpad. Apparently, it causes the laptop to occasionally wake from sleep immediately after being told to suspend. Between that and immediately jamming the laptop into my bag when I put it to sleep, I was creating an overheating issue. Theoretically, this will solve the issue.
💡 Tip
If you are visiting here from the future with a newer generation of Z13, or with some other AMD-based laptop with suspend issues, here's how to find your problematic i2c device!
ls /sys/bus/i2c/devices/*/power/wakeup
The format of the device name should be i2c-ELAN0679:00 or i2c-MSFT0001:00. Run this command to block it from waking the system:
sudo echo disabled > /sys/bus/i2c/devices/<device_name>/power/wakeup
Power Profile Daemon Tweaks
Some smaller tweaks I added to change the power profile when the AC adapter is plugged in or unplugged:
nano /etc/udev/rules.d/60-onbattery.rules
# Rule for when switching to battery
SUBSYSTEM=="power_supply",ENV{POWER_SUPPLY_ONLINE}=="0",RUN+="/usr/share/power-profiles/power-saver.sh"
nano /etc/udev/rules.d/61-onacpower.rules
#Rule for when switching to AC Power
SUBSYSTEM=="power_supply",ENV{POWER_SUPPLY_ONLINE}=="1", RUN+="/usr/share/power-profiles/performance.sh"
nano /usr/share/power-profiles/power-saver.sh
#!/bin/sh
#set performance profile through D-bus
powerprofilesctl set power-saver
nano /usr/share/power-profiles/performance.sh
#!/bin/sh
#set high performance profile through D-bus
powerprofilesctl set performance
Don't foget to make them executable
sudo chmod +x /usr/share/power-profiles/power-saver.sh
sudo chmod +x /usr/share/power-profiles/performance.sh
Pros and Cons
NixOS | Arch | Debian | Fedora |
---|---|---|---|
✓ Easily reproduced | ✓ Excellent wiki (helpful with ALL other options, too) | ✓ Large package base | ✓ Lots of official documentation |
✓ Nix configs make big changes easy | ✓ AUR has almost everything | ✓ apt is fine | ✓ LOTS of pre-compiled packages |
✗ Awful documentation | ✗ Many packages need to be built from source | ✗ Mostly replaced by Ubuntu, as far as broad support | ✗ |
✗ Least amount of community support | ✗ Frequent system-breaking upgrades | ✗ /boot partition fills up on every install, somehow | ✓ Everything just works with very little adjustment |
✓ Snapshots are part of the core OS | ✗ This is cowboy land - AUR packages can easily break things | - Package manager is reliable | - Package manager is reliable |
✓ Most stable | ✗ Least stable | ✓ Most stable (on my servers) | ✓ Turns out to be quite stable |
Timeline
November 2024-????
Installed Debian Sid at the end of November. I'm going to try to be a good boy and use Flatpaks more often and stop crudding up my systems. My servers that are running Docker containers never have a single issue, and I cannot help but think that my cowboy-style of package management is a root cause. Oops.
April 2024-November 2024
Fedora was used daily as my main OS for work, scripting, VMs and (very occasional) gaming. It mostly worked well for this. I started running into issues when I bought a Cisco-compatible Ethernet-to-USB serial cable for programming access points. Through a hub, it just didn't work. Aside from that, 7 months of crud had built up in my system from constantly trying to add packages - I wound up with Arch Linux in slow motion, which is entirely my own fault.