Hardware Linux

Ubuntu 20.04 on Thinkpad T14 gen 2 (Intel)

AnnouncedLate 2021
CPU, GPU, RAMIntel i5-1135G7 @ 2.40GHz 4 cores (8 threads), Iris Xe graphics, 16GiB soldered DDR4 3200 MHz (and one free slot for upgrades)
Screen14″ FHD (1920×1080) IPS 300nits Anti-glare
StorageSK Hynix NVMe 512GB
Lenovo part number 20W000R1MX (Lenovo Product Specification Reference)


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.

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.

Power usage in suspended state is nothing out of the ordinary. I would have liked to have hibernate option available, but this is apparently disabled due to locked down kernel and secure boot.


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 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.


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
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

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”.


Enable HTTP/2 with Apache+PHP on Ubuntu

I recently made the necessary adjustments to my Apache+PHP server to support the HTTP/2 protocol. This newer protocol comes with performance advantages and support is widespread by now. Depending on existing Apache server configuration, it is not always trivial to enable, due to specific requirements for HTTP/2 with Apache. This especially applies if you’re using PHP with the classic mod_php Apache module.

Here is a summary of the setup I used before, when my web server only supported HTTP/1.X:

  1. Ubuntu 20.04 LTS
  2. Apache 2.4 web server with the classic prefork multi processing module.
  3. mod_php for server side PHP script execution.
  4. Fully https-enabled site with certificate from Let’s Encrypt.
  5. WordPress for publishing.

Points 2 and 3 will require changes.

The Apache multi processing module (often referred to simply as an «MPM») must be switched to the generally recommended mpm_event. Since mod_php is not compatible with the multi threaded mpm_event, an alternative must be used for PHP script execution. The recommended approach is to setup PHP as a FastCGI service and have Apache proxy requests to this service for actual script execution. So the big difference here is that PHP code will execute outside of the Apache server processes, thereby decoupling Apache’s execution environment and request handling from PHP.

The steps in the following sections all apply to Ubuntu 20.04 and Debian in general (package versions may vary). There are some handy command line tools to configure the modular Apache server, which we will be using. Assuming nothing goes wrong, no significant downtime will occur when following these steps.

1. Setting up the PHP FastCGI service

Disable and remove the classic mod_php package, since it is no longer needed:

# Disable Apache mod_php:
a2dismod php7.4

# Optionally remove packages, no longer be needed:
apt autoremove libapache2-mod-php\*

Install the PHP FastCGI process manager package:

apt install php-fpm

The service should be automatically started. The package provides the following information after a successful installation:

NOTICE: Not enabling PHP 7.4 FPM by default.
NOTICE: To enable PHP 7.4 FPM in Apache2 do:
NOTICE: a2enmod proxy_fcgi setenvif
NOTICE: a2enconf php7.4-fpm
NOTICE: You are seeing this message because you have apache2 package installed.

So let’s just do what is recommended:

a2enmod proxy_fcgi setenvif
a2enconf php7.4-fpm

The proxy_fcgi module is required so that Apache can proxy requests to FastCGI services. The second command enables proxy configuration specific to the service setup by the php7.4-fpm package.

If you have customizations to php.ini, you will have to copy those from the old mod_php configuration file to the separate php-fpm configuration. These are the relevant files:

# old mod_php config file no longer in use:

# new php-fpm config file:

Finally, you can test that PHP still works on your web site after the switch to php-fpm, before moving on:

apache2ctl configtest
systemctl restart apache2

2. Switch to event multi processing module in Apache

Disable mpm_prefork, then enable mpm_event:

a2dismod mpm_prefork
a2enmod mpm_event

If those commands succeed, then restart Apache and test that your site still works:

apache2ctl configtest
systemctl restart apache2

3. Enable the HTTP/2 protocol

a2enmod http2
systemctl restart apache2

Now you can open your browser developer tools and do a page load of your site. If using https, then your browser should negotiate HTTP/2 with the server, and you will see that logged as the protocol. All done.

If not using https however, then you cannot really take advantage of HTTP/2. In theory it is supported, but most browsers will only use it over TLS connections. The protocol is then referred to as “h2”, meaning HTTP/2 over secure transport.

Tuning mpm_event and php-fpm

You can tune the Apache event MPM by editing the following configuration file:


The PHP FastCGI process manager service can be tuned by editing:


Summary of setup after enabling HTTP/2

  1. Ubuntu 20.04 LTS
  2. Apache 2.4 web server with the event multi processing, http2 and proxy_fcgi modules enabled.
  3. PHP-fpm for server side PHP script execution.
  4. Fully https-enabled site with certificate from Let’s Encrypt.
  5. WordPress for publishing.


Hardware Linux

VirtualBox + Secure Boot + Ubuntu = fail

Here are the steps I did to enable VirtualBox to work properly in Ubuntu with UEFI Secure Boot fully enabled*. The problem is the requirement that all kernel modules must be signed by a key trusted by the UEFI system, otherwise loading will fail. Ubuntu does not sign the third party vbox* kernel modules, but rather gives the user the option to disable Secure Boot upon installation of the virtualbox package. I could do that, but then I would see an annoying “Booting in insecure mode” message every time the machine starts, and also the dual boot Windows 10 installation I have would not function.

*Ubuntu 16.04 on a Dell Latitude E7440 with BIOS A18, and with a dual boot Windows 10 installation.

Credit goes to the primary source of information I used to resolve this problem, which applies specifically to Fedora/Redhat:

And a relevant Ask Ubuntu question:

Steps to make it work, specifically for Ubuntu/Debian

  1. Install the virtualbox package. If the installation detects that Secure Boot is enabled, you will be presented with the issue at hand and given the option to disable Secure Boot. Choose “No”.
  2. Create a personal public/private RSA key pair which will be used to sign kernel modules. I chose to use the root account and the directory /root/module-signing/ to store all things related to signing kernel modules.
    $ sudo -i
    # mkdir /root/module-signing
    # cd /root/module-signing
    # openssl req -new -x509 -newkey rsa:2048 -keyout MOK.priv -outform DER -out MOK.der -nodes -days 36500 -subj "/CN=YOUR_NAME/"
    # chmod 600 MOK.priv
  3. Use the MOK (“Machine Owner Key”) utility to import the public key so that it can be trusted by the system. This is a two step process where the key is first imported, and then later must be enrolled when the machine is booted the next time. A simple password is good enough, as it is only for temporary use.
    # mokutil --import /root/module-signing/MOK.der
    input password:
    input password again:
  4. Reboot the machine. When the bootloader starts, the MOK manager EFI utility should automatically start. It will ask for parts of the password supplied in step 3. Choose to “Enroll MOK”, then you should see the key imported in step 3. Complete the enrollment steps, then continue with the boot. The Linux kernel will log the keys that are loaded, and you should be able to see your own key with the command: dmesg|grep 'EFI: Loaded cert'
  5. Using a signing utility shippped with the kernel build files, sign all the VirtualBox modules using the private MOK key generated in step 2. I put this in a small script /root/module-signing/sign-vbox-modules, so it can be easily run when new kernels are installed as part of regular updates:
    for modfile in $(dirname $(modinfo -n vboxdrv))/*.ko; do
      echo "Signing $modfile"
      /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 \
                                    /root/module-signing/MOK.priv \
                                    /root/module-signing/MOK.der "$modfile"
    # chmod 700 /root/module-signing/sign-vbox-modules
  6. Run the script from step 5 as root. You will need to run the signing script every time a new kernel update is installed, since this will cause a rebuild of the third party VirtualBox modules. Use the script only after the new kernel has been booted, since it relies on modinfo -n and uname -r to tell which kernel version to sign for.
  7. Load vboxdrv module and fire up VirtualBox:
    # modprobe vboxdrv

The procedure can also be used to sign other third party kernel modules, like the nvidia graphics drivers, if so is required. (I have not tested that myself.)