Fedora on the Surface Pro 7

January 16, 2021 - 5 minutes read - 872 words

So I recently got a new Surface Pro 7 from work and decided to make it a replacement for my aging Macbook Pro as a mobile UNIX box. I really never found a replacement for my old eeePC and this looked like it could be a viable candidate. I decided to go with Fedora 33 since I’m doing more work with RPM based distributions lately and Arch seemed like a lot of effort. I wanted something that had a similar level of “just works” to my Mac and I am happy to leave the tweaking to my desktop where I’m less likely to lock myself out permanently. Thankfully, the nice folks at the linux-surface repository are working on a patched kernel that supports the Surface hardware and they have a RPM distribution for Fedora pre-made.

Basic Installation

I started out by booting up Windows 10 and installing all of the available firmware updates through Windows Update. One trick that I found was you can avoid having to set up an online Microsoft account by just refusing to connect to wifi while doing the initial setup. When the initial setup is done you can connect to grab the updates you need. Once that was done I shrunk the Windows partition by about 100GB with the Disk Management tool and rebooted with my Fedora Workstation USB key.

The installation was surprisingly painless, the only thing I changed from the default was to choose ext4 on LVM thin partitions for the filesystem instead of btrfs. Once the install was done I rebooted and got started on the install instructions from GitHub.

sudo dnf config-manager \
  --add-repo=https://pkg.surfacelinux.com/fedora/linux-surface.repo
sudo dnf install --allowerasing kernel-surface iptsd libwacom-surface
sudo systemctl enable iptsd
sudo dnf install surface-secureboot

Additionally, the kernel update service unit in the instructions works fine for updates to the kernel but for the initial installation you need to run the command manually.

sudo grubby --set-default /boot/vmlinuz*surface*

Once that is done it is time to reboot and finish up the SecureBoot installation.

Issues with Kernel 5.10.6-1

One thing that did come up while installing the Surface kernel was some of the RPM scriptlets failed to execute correctly with the error below.

Running transaction
  Preparing        :                                                        1/1 
  Upgrading        : kernel-surface-5.10.6-1.fc33.x86_64                    1/2 
  Running scriptlet: kernel-surface-5.10.6-1.fc33.x86_64                    1/2 
sort: fflush failed: 'standard output': Broken pipe
sort: write error

gzip: stdout: Broken pipe

gzip: stdout: Broken pipe
sort: write failed: 'standard output': Broken pipe
sort: write error

  Running scriptlet: kernel-surface-5.9.16-1.fc33.x86_64                    2/2 
  Cleanup          : kernel-surface-5.9.16-1.fc33.x86_64                    2/2 
  Running scriptlet: kernel-surface-5.9.16-1.fc33.x86_64                    2/2 
  Verifying        : kernel-surface-5.10.6-1.fc33.x86_64                    1/2 
  Verifying        : kernel-surface-5.9.16-1.fc33.x86_64                    2/2

The result being that the Surface kernel was not showing up correctly in the GRUB boot menu when rebooting. Reinstalling the package didn’t seem to help but rebuilding the initramfs and configuring GRUB manually seems to sort the problem out. The following should get everything back in working order.

sudo dracut --force --regenerate-all --verbose
sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg

Now, since I am certifiable, I decided to hook the new tablet/laptop up to my home FreeIPA install. During the first boot of Fedora I was given the option to do an “Enterprise Login” instead of the default local account. This was another, “works surprisingly smoothly,” situation and I was able to get everything registered and running with little to no fuss.

PolicyKit Configuration

The only hiccup in the enterprise login situation came up when I tried to install software through the GNOME software GUI. This uses PolicyKit and by default only allows members of the wheel group to perform administrative actions. My FreeIPA setup instead uses a desktop-admins group for this purpose so I need to add some configuration in /etc/polkit-1/rules.d. It is important to start the rule filename starts with a lower number than the 50-defaults.rules file so that it is loaded first.

// 40-desktop-admin.rules
polkit.addAdminRule(function(action, subject) {
  return ["unix-group:desktop-admins", "unix-group:wheel"];
});

This bit of JS sets PolicyKit to allow both destkop-admins and the wheel group to perform administrative actions. This way if the FreeIPA connection falls over at some point in the future I can set up a local account and get back in to fix things.

Video Acceleration

The last thing I wanted to get working was proper hardware video acceleration. Going off of this blog post I installed the RPMFusion repositories and installed the driver packages.

sudo dnf -y install intel-media-driver libva libva-utils ffmpeg

The blog post suggests using libva-intel-driver or libva-intel-hybrid-driver but the Surface Pro 7’s graphics card isn’t supported by either of those packages. When I tried to test it with vainfo the error suggested using the intel-media-driver package instead. Once everything is installed I tested it with the following.

$ vainfo
libva info: VA-API version 1.9.0
libva info: Trying to open /usr/lib64/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_9
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.9 (libva 2.9.0)
vainfo: Driver version: Intel iHD driver for Intel(R) Gen Graphics - 20.3.0 ()
vainfo: Supported profile and entrypoints
      VAProfileNone                   :	VAEntrypointVideoProc
...

Now that the drivers are in place we need to configure Firefox to use the hardware acceleration. Opening up about:config in Firefox I toggled the gfx.webrender.enabled flag to true then restarted Firefox. With that, Firefox is running videos super smooth and my new laptop is ready to go!