I recently did a BIOS upgrade on my main desktop machine (ASUS motherboard). It runs Ubuntu 24.04, has a dedicated AMD GPU and I use the proprietary AMD driver packages for ROCm compute support. What came as a surprise was the non-accelerated Gnome Shell experience that greeted me after the BIOS upgrade. I could tell something was off, and it didn’t take me long to notice that the KMS graphics subsystem was using some generic driver with poor acceleration. How can a BIOS upgrade cause this to happen ? Was my GPU suddenly bricked in some way ?
No, fortunately ! I just forgot about the fact that ASUS BIOS upgrades tend to mess around with the UEFI Secure boot key database, which is in essence a firmware trust store of public keys that is used to verify signatures of operating system binary artifacts (like boot loaders, kernel images and modules). After probing around for while, I discovered that attempting to load the amdgpu kernel module failed with an error related to cryptographic signature. (I cannot remember the exact message at this time.) Since a lot of other kernel modules where already loaded successfully, I figured this has to be caused by the proprietary driver being compiled (and signed) externally by DKMS.
The obvious next step was to attempt a complete re-installation of the AMD driver packages and DKMS, which I hoped would fix-up the module signature issues. But it didn’t help at all, even though a full recompilation of the AMD kernel modules was completed without any obvious error messages popping up. The resulting module was still not trusted by the kernel. (Even wiping all packages and re-installing didn’t do it.)
I wasn’t planning on spending my morning messing with the UEFI firmware keys, and so I pondered just going back to the open source AMD driver, which already comes bundled with each kernel package (and no ROCm compute support..). But then I discovered references to DKMS and a cryptographic key pair, lurking under the system directory /var/lib/shim-signed/mok:
# ls /var/lib/shim-signed/mok
MOK.priv MOK.der
That’s a certificate and private key, and «MOK» refers to the Secure Boot concept Machine Owner Key. You are normally allowed to adjust what Secure Boot trusts, if you have access to the physical machine on which it runs, which means you can modify the key database (trust store). After some research (and remembering I already did something very similar years ago), I figured I needed to try enrolling this public key into the UEFI key database:
mokutil --import /var/lib/shim-signed/mok/MOK.der
The mokutil command is used to interface with UEFI machine owner keys, and you can also check which MOKs are already enrolled using --list-enrolled.
The utility will ask for a password and you can simply invent something simple here. It is used only once as a challenge when entering the UEFI Mok manager utility after rebooting. From that firmware user interface you can then choose to enroll the new key and continue booting. After completing this step, the proprietary amdgpu kernel module loaded successfully once again and the problem was fixed.
I was disappointed by the Linux user experience here. A non-working graphics driver is not an obvious consequence of a BIOS upgrade, and had it not been for years of experience with Linux desktops, I would probably have given up much sooner. I don’t know if it’s just a bug that the key was not automatically re-enrolled by DKMS on re-installation, but that is certainly not a user friendly experience.
This is a laptop with a slightly boring, but professional and discrete design, which I like. It’s a sturdy workhorse and has a quality feel to it – typical business segment. Overall Ubuntu Linux works great and this is probably as good as it gets regarding out of the box Linux compatibility, unless going for specialized commercial Linux offerings like a System76.
There are some issues with TrackPoint smoothness relating to kernel input drivers, and you may experience issues with the keyboard.
Read on for details.
What works fine
Installation alongside side Windows 10 Pro ✓
For dual boot installation, I freed up around 300 GB of storage space for Ubuntu using Windows disk administration. Installation of Ubuntu 20.04 on new partition went without issues. Grub becomes primary boot loader with Windows as menu option.
Graphics and screen ✓
Both Wayland and Xorg sessions work fine and perform well. Brightness controls are functional and screen is surprisingly bright and crisp.
Power management and cooling ✓
The CPU cores are automatically clocked between 1,2GHz and 3,5GHz, depending on load. The fan rarely makes any noise at all on normal light weight usage, and it is subtle even when it needs to run faster.
The battery is a 51Wh SMP, and charge thresholds can be controlled at runtime. I typically set mine to stop charging at 85% when at home, to increase battery lifespan. You can control this by writing percentages to the files:
The laptop has a USB-C port for charging, and when using the accompanying 65W A/C power supply, charging is fast. It will also accept charge from other power supplies, like common mobile quick chargers, but the BIOS may issue a warning on boot if the charger is too weak.
Update 2023-01-14: you can check out the following script for a handy tool that shows Thinkpad battery information on the command line. It also displays the charge stop and start thresholds.
Suspend to RAM ✓
Suspend to RAM and resume works fine. There are some ACPI errors appearing in the kernel log upon resume:
ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PC00.RP09.PEGP.DDNT], AE_NOT_FOUND (20210730/psargs-330)
[...]
ACPI Error: Aborting method \_SB.PC00.LPCB.EC.SEN4._TMP due to previous error (AE_NOT_FOUND) (20210730/psparse-529)
I haven’t look into these, probably buggy firmware code. It does not seem to cause any real problems.
The HDA audio chip identifies as Realtek ALC257. I have not noticed any issues and it works well. The laptop speakers are a bit disappointing and sound rather weak, but I rarely rely on them anyway.
Wireless networking ✓
The wifi chip is detected as Intel(R) Wi-Fi 6 AX201 160MHz, REV=0x354 by the iwlwifi driver. No issues experienced, wireless networking is solid.
Also note that there is no RJ45 ethernet port on this laptop model.
Bluetooth ✓
Bluetooth is usually a bit buggy on Linux, and it can be a hit and miss experience, depending on the devices your are trying to connect. For the Thinkpad T14, it uses an Intel Bluetooth chip connected to the USB bus.
I’ve tested connectivity with a pair of Bose QC35 headsets and a Samsung Galaxy mobile phone, both work.
Special keys ✓
Most Fn-special keys work fine: audio controls, mic mute, brightness, flight mode. There are some that generate no key events in Xorg: Fn+F9 through F11. These are labeled with symbols for chat, answer call and hangup call.
Firmware upgrades ✓
The Thinkpad firmware can be automatically updated using the built-in fwupdmgr application. Which is a great improvement from earlier days of having to flash updates from thumb drives or being forced to use Windows.
Fingerprint reader ✓
The fingerprint reader works out of the box. You can enroll your prints in the standard Ubuntu settings app.
Webcam ✓
It works fine, but is only a 720p camera.
Problems 💀
Poor keyboard quality control
I noticed the left trackpad mouse button had erratic click detection – some clicks were missed. I primarily use the TrackPoint and rely on the physical mouse buttons beneath the space bar. Having premium on-site support, I decided to call for assistance, suspecting hardware malfunction. Lenovo sent a service technician a few days later, and the entire keyboard was replaced, at no additional cost. The new keyboard is fine.
Speaking of keyboard, the keys are a bit too hesitant and mushy for my taste. But solid.
TrackPoint cursor movement
TrackPoint cap
The [Elan] TrackPoint cursor movement is slightly rough and jittery (using Xorg), resulting in reduced precision. It is almost like not enough input events are generated per time during movement. Also, the following message is printed in the kernel log:
psmouse serio1: synaptics: Your touchpad (PNP: LEN2072 PNP0f13) says it can support a different bus.
If i2c-hid and hid-rmi are not used, you might want to try setting psmouse.synaptics_intertouch to 1 and report this to linux-input@vger.kernel.org.
I have experimented with the suggested psmouse module setting, and it does indeed result in a smoother cursor. However, it also causes TrackPoint to randomly stop working, which is a deal breaker. I have not found a solution to this problem yet, but trust it will improve with future kernels.
Swapped Ctrl and Fn-keys
Thinkpads come with physically swapped left control and Fn-key compared to most keyboards. So you have this layout on the left bottom row:
[Fn] [Ctrl] [Win] [Alt] [ Space ] …
Being an Emacs user, this can be uncomfortable, since the distance between the control key and frequently used letter combinations is too short. Not to mention having to mentally re-calibrate your typing when switching between the Thinkpad and other keyboards. Fortunately the BIOS allows you to software swap the function of these keys, so the Fn-key becomes the left control. But the Fn-key is physically smaller and provides a poorer “left control experience”.
Show Thinkpad battery info on the command line
You can use the following shell script to check your battery vitals from the command line. Copy-paste the code into a file tpbinfo, save it somewhere in your PATH and make it executable with: chmod +x tpbinfo
In August of 2020, I wrote a post about how smartphone manufacturers fail to provide a long enough period of security updates to the devices they sell. Leaving the market to itself has obviously lead to planned obsolescence being the norm for Android-based devices, where it is necessary to buy a new phone every 2–3 years to stay secure. But things might change for the better. The European Commission is planning to extend [1] its Ecodesign and Energy labelling directive to also apply to smartphone (and similar) products, and with it comes requirements to reparability and minimum security update support period. Currently proposed is a 5 year period for such products, which is great news. Going further, Germany is lobbying [2] to get a 7 year support period for updates and spare parts. It will be interesting to see the outcome of this.
On a personal note, I ended up buying a new Samsung S21 phone, after Sony stopped updates for my two year old Xperia compact. The Samsung phone is too big, but I could not find a better alternative. And I will likely get at least 4 years of updates. I have no need to replace my smartphone every 2 years and contribute to such ridiculous resource waste.
