Installing Linux on a lenovo "tablet-PC"

The keyboard has two classic USB connectors where a USB key can be plugged. In order to get to the boot menu you need to push the power button and the Volume+ button until the screen lights up. From the displayed menu you can then unactivate secure boot. You can also ask for the boot menu where the entry for the USB key should appear…

Obviously, the key should be UEFI-bootable. This is the case of the desktop-live devuan image (chimaera 4.0, I upgraded to daedalus 5.0 since then) so I used it and it worked fine except:

• sound is not working ("dummy device" shown on pavucontrol),
• I did not bother to even try the cameras (I was happy enough that the wifi went up in a snap!)

The live system allows to run an install with refractainstaller, so I wiped the windows partition and things went well… or almost!

When restarted, the tablet tries to boot the now wiped Windows install, spends quite some time "trying to repair" and running "diagnostics" before giving up. Pressing the Volume+ button allows to get to the boot menu where the "debian" entry is shown. However it then failed. It turns out that, although the system is 64 bits, the UEFI firmware is only 32 bits. I had to reboot from the live system on the USB key and then proceed as shown on https://wiki.debian.org/GrubEFIReinstall.

Although it is uncommon to have a 32 bit UEFI on a 64 bit system, this has been supported by the debian installer (and others) for a long time, and I though it would probably work. But, actually, shame on me, as this is mentionned in the readme of refractainstaller, which I only (too) quickly skimmed through:

(https://www.refracta.org/docs/readme.refractainstaller.txt)

For 32-bit grub with 64-bit system: grub-efi-ia32 package is in the root of the file system. Install the package before you run refractainstaller or install it to /target in a chroot. The installer will pause to let you do this before it installs the bootloader. It may also work if you let the installer copy the package to /target during the installation.

Now I was able to boot devuan by going into the boot menu (damn Volume+ button). I read/learned quite a bit about the UEFI boot process¹, became confident debian was properly set as the first entry in the boot menu and so should be selected by default… which was not the case, it was still trying to boot the wiped-out Windows system!

Here's the details of what efibootmgr displays:

root@gnougnoute:/home/deleuzec# efibootmgr
BootCurrent: 0002
Timeout: 2 seconds
BootOrder: 0001,0002,2001,2002,2003
Boot0001* debian
Boot0002* Windows Boot Manager
Boot2001* EFI USB Device
Boot2002* EFI DVD/CDROM
Boot2003* EFI Network
root@gnougnoute:/home/deleuzec# efibootmgr -v
BootCurrent: 0002
Timeout: 2 seconds
BootOrder: 0001,0002,2001,2002,2003
Boot0001* debian        HD(1,GPT,ca7a85d0-edfe-489a-8c58-ce07bd9ffbb6,0x800,0x82000)/File(\EFI\debian\grubia32.efi)
Boot0002* Windows Boot Manager   HD(1,GPT,ca7a85d0-edfe-489a-8c58-ce07bd9ffbb6,0x800,0x82000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7: .0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}....................
Boot2001* EFI USB Device        RC
Boot2002* EFI DVD/CDROM RC
Boot2003* EFI Network   RC
root@gnougnoute:/home/deleuzec#

Also, if I go through the boot menu to explicitely select the debian entry, BootCurrent is indeed set to 0001.

At some point, not finding any setting I could change, I started to suspect the firmware, contrary to UEFI boot menu specs, to be hardcoded to boot the microsoft boot manager by default. I decided to try and overwrite the debian bootai32.efi to Microsoft/Boot/bootmgfw.efi and… that worked!

root@gnougnoute:/home/deleuzec# ls -l /boot/efi/EFI/debian/grubia32.efi
-rwx------ 1 root root 106496 21 août  13:46 /boot/efi/EFI/debian/grubia32.efi
root@gnougnoute:/home/deleuzec# ls -l /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi
-rwx------ 1 root root 106496 21 août  13:54 /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi
root@gnougnoute:/home/deleuzec# diff /boot/efi/EFI/debian/grubia32.efi /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi
root@gnougnoute:/home/deleuzec#

Not sure why I had to do that, could be that the UEFI implementation is broken (that does happen, according to https://wiki.osdev.org/Broken_UEFI_implementations). Looking again at the spec I found the following that could be an explanation, since booting from the debian entry failed on first time (because of my mistake about 32 vs 64 bit UEFI):

https://uefi.org/specs/UEFI/2.10/03_Boot_Manager.html

The platform firmware may also implement value added features in the boot manager if an exceptional condition is discovered in the firmware boot process. One example of a value added feature would be not loading a UEFI driver if booting failed the first time the driver was loaded.

Although this would not be correct anyway since the sentence is about UEFI drivers, while a boot loader is a UEFI application.

Simply needs the firmware from the non-free package firmware-intel-sound.

Screen orientation is portrait by default, which is essentially unusable when using the keyboard. I usually have slim as the display manager, but I couldn't find how to set the screen orientation so I selected lightdm as it allows to run setup scripts.

Screen orientation can be set with xrandr, but you also want to set up xinput for rotating the touch screen! In the end, I created two shell scripts to set screen orientation:

/usr/local/bin/set-landscape.sh

#!/bin/sh
xrandr -o right
xinput set-prop "FTSC1000:00 2808:1015" --type=float "Coordinate Transformation Matrix" 0 1 0 -1 0 1 0 0 1

/usr/local/bin/set-portrait.sh

#!/bin/sh
xrandr -o normal
xinput set-prop "FTSC1000:00 2808:1015" --type=float "Coordinate Transformation Matrix" 1 0 0 0 1 0 0 0 1

and setup lightm.conf TODO

[Seat:*]
greeter-setup-script=/usr/local/bin/set-landscape.sh

This is for X. For also having text consoles in landscape, the kernel needs to be passed the fbcon=rotate:1 parameter. To do this permanently, /etc/default/grub must be edited to contain:

GRUB_CMDLINE_LINUX_DEFAULT="fbcon=rotate:1 quiet"

before to run update-grub.

The keyboard is not especially comfortable, so I expect to do most of the administration remotely. I installed my ssh public key in .ssh/authorized_keys and disabled password authentication:

/etc/ssh/sshd_config

PasswordAuthentication no

Also, when using NetworkManager, the network is brought up only when the user who configured the connection logs in. That means I would need to login physically before being able to login with ssh…

In order for the network connection to be brought up at boot time, the connection has to be made "Available to all users" (right click on the nm applet, then edit the connection to select the appropriate setting).

I plan to use the tablet w/o the keyboard most of the time (I mean, if I want to use a keyboard, I'd rather use a laptop), so I basically need:

• install and configure a virtual keyboard,
• select applications, configure system and apps to that as much operations as possible can be done without the virtual keyboard.

I chose onboard for the virtual keyboard. It turns out the second item is far from trivial! I'll describe that in another post… when I'll have solved a nasty touchscreen issue!

to be continued…