Those using Ubuntu 19.10 might have noticed this suddenly stopped working. And this can be directly correlated with the latest kernel update.
If you dwelve into details, you can see the following with kernel 5.3.0-40 (previous, working version):
uname-a
Linux 5.3.0-40-generic #32-Ubuntu SMP Fri Jan 31 20:24:34 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux``sudo journalctl -b|grep multitouch
hid-multitouch 0018:04F3:261A.0001: input,hidraw0: I2C HID v1.00 Device [ELAN9038:00 04F3:261A] on i2c-ELAN9038:00
hid-multitouch 0003:045E:096F.0005: input,hiddev2,hidraw4: USB HID v1.11 Mouse [Microsoft Surface Type Cover] on usb-0000:00:14.0-7/input3
If you check it under latest kernel 5.3.0-42, you’ll see a bit of an issue:
uname-a
Linux 5.3.0-42-generic #34-Ubuntu SMP Fri Feb 28 05:49:40 UTC 2020 x86_64 x86_64 x86_64 GNU/Linuxsudo journalctl -b|grep multitouch
hid-multitouch 0018:04F3:261A.0001: report is too long
hid-multitouch 0018:04F3:261A.0001: item 0108 parsing failed
hid-multitouch: probe of 0018:04F3:261A.0001 ^^failed with error -22^^
hid-multitouch 0003:045E:096F.0005: input,hiddev2,hidraw3: USB HID v1.11 Mouse [Microsoft Surface Type Cover] on usb-0000:00:14.0-7/input3
If you browse kernel team Bugzilla, you’ll find there is already a bug report for this issue and issue has already been merged to kernels 5.5 and 5.6. Unfortunately, Ubuntu 19.10 uses a 5.3 kernel so we’ll need to wait a bit.
The next best thing is to temporarily downgrade our kernel. For this the easiest method is to just update /etc/default/grub to use third entry of the second menu (Advanced, old kernel) as the default:
As I started traveling a bit more recently, I went into search for a small laptop I can carry with me. As an alternative to my 17" work and 15" personal laptop, I wanted to go much smaller. Here comes Surface Go.
It’s not a powerful device by a long shot and any heavy load is out of question. That is doubly so for the one I selected - with 4 GB RAM and only a 64 GB disk. What worked in its favor was a really cheap price (Craigslist) and reasonably mainline components ensuring Linux compatibility. Yep, I wanted to use this as my portable Linux machine.
The first step was to create a bootable media. I personally use Rufus if doing it from Windows. For those doing it from Linux, there is an excellent page with other options available. What you want is MBR-based FAT32 format. If you use GPT, all you’ll get is GRUB command line.
The easiest way to install Ubuntu is if you start from Windows. Go to Recovery Options and select Restart now. From the boot menu then select Use a device and finally use Linpus lite. If Linpus lite doesn’t appear, select EFI USB device and repeat the process. For some reason Linpus option appears every second boot for me. If you are using Ubuntu, there is no need to disable secure boot or meddle with USB boot order as 19.10 fully supports secure boot (actually Microsoft signs their boot apps).
From there on, you can proceed with Ubuntu installation as you normally would do. For me that meant going with Minimal and no other changes. If you select third party drivers, you will have to setup UEFI password but I’ve found that Surface doesn’t need such special treatment.
PS: If you do want to mess with boot order, start with the Surface Go powered off. While holding Volume Up button, press Power button, and then release Volume Up. This will give you UEFI menu. There you can change boot order and/or disable Secure Boot. To reset BIOS settings to the default values, use F9 key.
PPS: Between the time I wrote this post and its publishing time, any further travel became unlikely due to COVID-19. There goes my reason for getting this laptop. :)
Booting from the USB is easy enough if you have Windows installed. Just go to Recovery Options and restart from there. But what if you installed Linux on your Surface Go an you want to get Windows back?
Yes, you can meddle with BIOS an change boot order there. But there is an easier way - just use GRUB.
To enter GRUB on Surface Go, just press Escape multiple times while booting. Once there, press c to enter command mode. All magic will happen here.
First “magic” part will be finding USB drive. For that just write ls and you will be presented with a list. Depending how you had your drive setup, you might be able to recognize it. If you used MBR it will be something like (hd0,msdos1) and if you used GPT it will be slightly different (hd0,gpt1). Frankly, that’s the probably single biggest reason I use MBR for my recovery drives - since all else uses GPT, it makes it painfully obvious which drive is correct one.
With drive selected, we just need to “chainload” it:
I find Surface Go quite nicely working with Ubuntu. If you are searching for a small capable Linux machine, it’s hard to beat it. However, one issue is really annoying. Its WiFi driver.
Fortunately, there is a nice guide on Reddit on how to fix this. Unfortunately, you will need to fix it again and again as system will overwrite your changes upon many (e.g. kernel) upgrades.
Well, not anymore. I created a package that automates this task. Each time WiFi driver gets its board.bin replaced, this package will change it back. One thing less to think about.
You can download package here or check build it yourself.
To install it, use the command line (GUI route doesn’t work without Internet access).
I am a big fan of ZFS and I have it installed on every Linux/Unix machine I own. Including the machine I use for playing with Docker containers. And it was that machine where I saw a bunch of ZFS snapshots with weird random hexadecimal names. And it wasn’t one snapshot, nor two - it was hundreds of them. So I deleted them.
Guess what, Docker build started complaining:
error creating zfs mount: mount system/root/a4f339f95f920b918bb23290a3e831dc22477bc76ef0d3496224fc424e65ec67:/var/lib/docker/zfs/graph/a4f339f95f920b918bb23290a3e831dc22477bc76ef0d3496224fc424e65ec67: no such file or directory
Well, I guess that sorted who was to blame for all those long snapshots. You see, Docker gets smart if it detect ZFS and does a lot of smart things. Unfortunately those smart things result in a lot of snapshots. And I don’t like people (or software) messing with my ZFS. And obviously Docker didn’t like me messing with it either. :)
Fortunately, the solution is easy enough. One should reconfigure Docker to use overlay2 storage driver instead of ZFS one and short daemon restart later one can continue playing with Docker without having to deal with ZFS snapshot hell.
Now only if I could remember this when I reinstall the OS…