After Labor Day in the United States several companies discounted their hardware by up to 50%. I ended up purchasing a Lenovo ThinkPad L14 G2:
Lenovo’s parts catalog lists the Realtek 8852AE as the wireless module, which supports 802.11AX/Wi-Fi 6. Apparently, Realtek does a particularly bad job supporting Linux.
Someone on Reddit suggested looking for modules with a Lenovo Field Replacement Unit (FRU) number and not vPRO, which is some magic Intel VPN encryption technology.
The compatible section of the Lenovo Parts page for my laptop lists the Intel AX200NGW and MediaTek MT7921.
A common solution is to replace the Realtek module with an equivalent Intel module.1 A good replacement model appears to be the AX210. Intel is going to release the AX211 in Q3’21, but I couldn’t find any available yet.2 My laptop uses the 22 x 30mm form factor, although Intel apparently also has a smaller option.
There seems to be some community support for Realtek drivers outside of the normal kernel development community. I installed lwfinger/rtw89.git, which seems to function normally, although I haven’t dug into how it performs. The requirement to recompile it with every kernel update is probably enough to motivate me to purchase a relatively cheap Intel replacement. Not to mention the much better support that Intel provides.
As of 5.17 there is mainline support for the Realtek 8852AE. I updated to Fedora 35 and then installed the following Fedora 36 packages from Koji:
At some point things only seemed to have gotten worse, required very frequently reassociating to networks because all packets are dropped. Unfortunately, even that does not always fix the problem.
Looking at the commit history in drivers/net/wireless
over the last year:
ath[a-zA-Z0-9]*:
: 276iwlwifi
: 415After a very superficial review I decided to order a AX210.
Unfortunately, although there is a SIM card slot there are no wires for a WWAN module near the M.2 slot nor antennas at the front of the case.
There are numerous ways to suspend the system including
systemctl suspend
, suspending using Gnome and
echo mem > /sys/power/state
. On a few occasions I was
able to toggle the capslock and mute keys while suspended, but in those
cases the system would reboot after a minute. Normally those keys are
unresponsive, however the power button and ThinkPad LED pulse
slowly.
Using Linus’ method from Documentation/power/s2ram.txt
I
see a Magic number
in dmesg
, as well as 4
references to hash matches
.
drivers/base/power/main.c:1259
is TRACE_SUSPEND(error)
under the Complete
label in __device_suspend_noirq()
acpi PNP0C02:0b: hash matches
:
`/sys/bus/acpi/devices/PNPacpi device:0e: hash matches
platform: hash matches
I changed the SSH port, which required updating
/etc/ssh/sshd_config
and then running following
commands:
semanage port -a -t ssh_port_t -p tcp <number>
firewall-cmd --zone=public --add-service=ssh
cp /usr/lib/firewalld/services/ssh.xml /etc/firewalld/services/
I then modifyed ssh.xml
to include the new port,
followed by firewall-cmd --reload
. That change can be
confirmed with firewall-cmd --info-service=ssh
.
I next generated SSH keys with a 2nd factor physical key:
ssh-keygen -C "$(whoami)@$(uname -n)-$(date -I)" -t ed25519-sk
Unfortunately, -vvvv
returns
FIDO_ERR_UNSUPPORT_ALGORITHM
. I then installed
yubikey-manager
and fido2-tools
. Using
ecdsa-sk
instead seems to get further. I reset my FIDO2 PIN
using ykman fido access change-pin
and then it worked when
I touched the YubiKey!
Unfortunately, Gitlab does not currently support
ecdsa-sk
.
Apparently, Gnome uses GeoClue and the Mozilla Location Service to locate a device. See the ArchWiki article on System time for more information.