Remark: This topic covers Arch Linux installation notes on a nitropad, created as a (self-)reminder how-to install this non-OEM/-supported Linux distro on a nitropad (x230 with default heads 1.3.1 rom).
I noticed after writing only, that the number of links is limited on this forum. Hence, decided to cripple the references at the end of the document a little to avoid rewriting.^^
As per install date April 2022, the official Arch Linux installation image is not recognised by heads yet.[1] So, it is not possible to use it directly. It is, however, straight-forward to boot a supported OEM USB-live system, mount the Arch Linux squashfs image as a guest and perform the install as per following steps.
- Preparation
To get an understanding of default partitioning with heads, I installed the minimal OEM debian image provided.[2] Since this image does not include the wireless module (iwlwifi in this case), I performed it offline. The result was a straight-forward msdos partinioning table with /dev/sda1 (boot), /dev/sda2 (lvm with vg-root and vg-swap). Following a reboot I performed a factory reset of the nitrokey[3] and changed PINs via the pre-installed nitrokey-app.
Next, I tested available installation methods for guest install.[4] Since the minimal debian image and (also) the Ubuntu live system did not support the tar option --numeric-owner, I reverted to using the Arch squashfs image. For that, prepared an USB with the OEM Ubuntu (which includes iwlwifi)[2] and a second USB medium with the squashfs image files (it should also be possible to simply have these on the extra “writable” usb-partition, which the Ubuntu live system image sets up).
After booting the OEM-Ubuntu USB live system, unsquashing and mounting the Arch squashfs was pretty straight-forward.[4] The /dev/pts mount did throw an error, but this did not impede pacman key init/checking or the chroot installation later. Also, Ubuntu mounts the resolv.conf via a symlink to a /run/systemd directory. So, it is necessary to copy the right file to the squashfs-root/etc directory.
- Installation
The Arch Linux installation guide was followed.[5] While partitioning, I opted to keep and mount the /dev/sda1 ext2 /boot partition created by debian fully intact (mostly because it contains heads’ hash files) and only wiped the rest of the partitions, re-creating a custom dm-crypt partitioning scheme.[6]
Probably due to the squashfs mount, the Arch pacstrap command failed to use UUIDs when installing the base system, but only the /dev/mapper/ devices in fstab. As this does not pose much of a problem with a single disc notebook, I kept the result for starters. Since Arch kernels are not versioned, this resulted, including the OEM debian kernel options, in something like:
linux /vmlinuz-linux cryptdevice=/dev/sdaX:root root=/dev/mapper/root rw intel_iommu=on intel_iommu=igfx_off quiet
One point to note regarding heads is to explicitly include the i915 module in the Arch initramfs via /etc/mkinitcpio.conf.[7]
A hick-up occured when trying to install the grub bootloader, throwing an error about blocklists (from the previous debian partitioning scheme).[8] Since heads’ kexec does not rely on the embedded grub payload, I decided to skip resizing the /boot partition and bootloader installation for the time being. Hence, I adjusted a /boot/grub/grub.cfg menu entry manually for the Arch initramfs/kernel combo w/ options.
The default way to enable CPU microcode updates (intel-ucode package) for Arch Linux is to specify an additional microcode initrd image for the boot loader. Since only the first initrd appears to be parsed by heads, I created a merged image to specify as a singular initrd /initramfs-merged.img in grub.cfg:
cat /boot/intel-ucode.img /boot/initramfs-linux.img > /boot/initramfs-merged.img
With that, installation was complete, taking care to exit chroot, unmount/close the dm-crypt mappers before rebooting.
- Reboot & profit
On the first reboot, heads interestingly (to me) did not warn about the new/changed /boot files until selecting the tweaked/new /boot menu item. Updating /boot checksums went swift, just as setting the Arch install as default boot later.
The microcode hack for the initrd could be automated by a pacman hook. Personally I prefer to keep such a task manual. With Arch it is perfectly fine to run a machine with /boot mounted ro, or even unmounted. For a nitropad this may even serve as good reminder to check successful /boot package updates prior to rebooting…
For similar reasons, it may be sensible to add the grub package to the ignore list of Arch’s pacman.conf, to avoid a package update overwriting heads-tracked files in /boot. (Opinions?)
References https://…
[1] github. com/osresearch/heads/issues/584
[2] docs.nitrokey. com/nitropad/ubuntu/os-reinstallation.html
[3] docs.nitrokey. com/nitropad/ubuntu/factory-reset.html
[4] wiki.archlinux. org/title/Install_Arch_Linux_from_existing_Linux#Method_B:_Using_the_LiveCD_image
[5] wiki.archlinux. org/title/Installation_guide
[6] wiki.archlinux. org/title/Dm-crypt/Encrypting_an_entire_system
[7] github. com/osresearch/heads/issues/702
[8] wiki.archlinux. org/title/GRUB#msdos-style_error_message