Installing Arch Linux on the Pinebook Pro
Obsolescence Notice (June 2021): I’m no longer running Arch Linux proper on my Pinebook Pro, due to the disappearance of the pacman repos I relied on for Arch Linux compatibility. Instead I’m using a minimal Manjaro install on the unstable branch with full-disk encryption, which is close enough to my previous Arch Linux setup for my purposes. See here for a more recent article describing how I set it up.
Note: Here is the original article for historical purposes, but don’t actually follow this as a guide.
I recently received my Pinebook Pro, which shipped with Manjaro pre-installed on the eMMC storage. I went through the initial setup process to create an account, which seemed pretty slick. Unfortunately I selected
es_US.UTF-8 as the locale by accident, and I can’t speak a lick of Spanish. Instead of spending several minutes fishing around blind for language settings in the now-incomprehensible desktop environment into which I was thrust, I decided to wipe the entire thing and install Arch Linux instead.
(I mean, I would have wiped it and installed Arch Linux eventually even if I hadn’t messed up the locale selection. The timeline was just accelerated a bit.)
This isn’t a review of the Pinebook Pro yet–though my initial impressions are very positive–it’s just a brief story of how I got Arch Linux installed and booting from the eMMC storage. Make sure you read the whole thing first if you’re using this as a walkthrough, because I’m the type of guy who ends up configuring his computer with a language he can’t even speak so you know I made other errors along the way.
Also, I’m writing this in June of 2020. If the current date that you’re reading this is substantially later than that, then I’d first like to congratulate you and the rest of the Human race for actually surviving 2020. What is the future like? How’s the whole global warming thing? Also you might want to think about looking for a more up-to-date guide.
There’s a pre-built flashable and bootable Arch Linux image for the Pinebook Pro available over on GitHub. Download it.
I used a different computer running Arch Linux for this step, but in theory you could do this on the Pinebook Pro itself using the default Manjaro installation (assuming you selected the correct locale and can actually operate it). Insert the SD card and use
lsblk to discover its device name. In my case it was
mmcblk0 but it could be different for you. You want the root device name and not a specific partition if there are any.
The image you downloaded from Github was probably compressed (has a
.xz file extension), so you’ll need to decompress it first.
The next step is to burn it to your SD card. You’ll probably want one that’s at least 8GB. Careful with this one. If you have the wrong device name in the second argument to this command you’ll lose everything on whatever storage device that is. Probably needs to run as
sudo for example).
This will take a while, but once it’s done you can put the SD card into your Pinebook Pro and power it on to boot into Arch Linux.
Unless, that is, you’re like me and decided to re-use an older SD card (perhaps that was once used in a Nintendo 3DS that your kids have since destroyed through sheer lack of respect for anything they own). I learned the hard way that the Pinebook Pro cannot read from a 16GB Kingston Micro SDHC card. Two of them, in fact (both kids have managed to destroy two separate Nintendo 3DSes), that work fine on my other computer.
Trying to boot with my Kingston SDHC cards inserted resulted in the power light turning on, but nothing else ever happening. When I inserted either card after booting into Manjaro and tried to read them, it detected the cards and reported the correct sizes, but did not show any partitions and attempting to read them or do anything else resulted in Input/Output errors.
It was only as I was dejectedly loading up Pine64’s website to see if they had some kind of ticket system where I could report my faulty Micro SD slot that I decided to try a third card I happened to have laying around. This one was a 128GB Sandisk Class 10 Micro SDXC card (left over from when I upgraded my Switch to a 256GB card). That one worked fine and booted me straight into Arch. I guess the Pinebook Pro only likes newer SD cards.
I was sitting there, pleased as punch, staring at the root prompt in my minimal Arch Linux install running off the SD card, when it dawned on me that I had no idea what to do next. I’ve installed Arch from scratch countless times on everything from Raspberry Pis to MacBook Pros, but my experience was limited to writing pre-baked images to bootable SD cards for ARM devices and using the Arch install scripts for everything on non-ARM devices. Installing Arch to an ARM device’s internal storage from a pre-baked SD card was new territory for me.
The first thing I tried was based on the Arch Wiki about how to install Arch Linux from an existing Arch Linux install. I was skeptical about whether the standard installation guide would apply to ARM devices, so I decided to go for the option where you copy the filesystem instead.
One of the first guides I found to get Arch Linux onto the Pinebook Pro was this one on the Pine64 forum that describes how to do it from scratch using certain bits from the Manjaro installation. Since the majority of that work has already been done to generate the pre-baked bootable SD image, I figured I could skip a lot of that and just use the guide for the piece that I was least sure of–how to write the boot partition on the Pinebook Pro’s eMMC.
In a typical Arch installation, you would create two partitions on your target device–one for the boot partition which you would format as FAT32, and one for the root filesystem which you would format as ext4 or some other linux-specific filesystem. Then you’d use
pacstrap to load Arch onto the root filesystem and manually copy the boot files over to the boot partition.
The forum guide does not resemble that at all. Instead of having boot files that you copy to a FAT32 partition, it has you create your root partition with a starting sector at a certain offset, then later use
dd to manually write a couple different boot images directly to the starting sectors of the device.
fdisk /dev/mmcblk2, created a new partition table with
n to create a new partition and entered
65536 as the starting sector (since that’s what the guide said to do), then finished that process and wrote my changes to the eMMC. Then I formatted with
mkfs.ext4 /dev/mmcblk2p1 and mounted with
mount /dev/mmcblk2p1 /mnt.
Easy right? Just have to recursively copy everything from the root partition of the SD card to the mounted partition on the eMMC.
After witnessing the wall of errors and realizing that you don’t actually want to copy everything including
/proc, and hilariously also copying
/mnt into itself, hit
ctrl-C to get yourself out of that misguided mess, run
rm -rf /mnt/* and just pretend you never tried to do any of that in the first place.
The Arch wiki gives this suggestion to copy an existing Arch install to a new device:
The only problem with that is that
rsync isn’t available on the SD card. Not a problem! A quick dip into
wifi-menu followed by
pacman -Syy and
pacman -S rsync had that problem solved in a jiffy. Running the above command then properly transferred Arch Linux from the SD card to the internal eMMC storage.
I’ll admit, this step felt like a leap of faith to me. Using the forum post I linked earlier, I came up with these commands as how to make the eMMC bootable:
Would those seemingly very specific
seek values apply even though I’m using a different pre-built Arch Linux image instead of whatever Manjaro-based stuff the rest of the forum post was referencing? I didn’t know.
But what’s the worst that could happen? YOLO!
I’ve bricked phones before that cost more than the Pinebook Pro, but usually not until after I’ve actually used the phone for at least a year first. This would have been my first time bricking a non-phone device, and also my first time bricking a device within hours of receiving it. My heart sank when it failed to respond at all when trying to boot without the SD card.
Thankfully, booting from the SD card still worked, so my Pinebook Pro would survive at least until after my next attempt.
At the time I’m writing this, the
README for the Arch image I’m using has this little message from its author:
Note: I have not tried writing this image to eMMC as I would not be able to recover it if something went wrong. Do that at your own risk and be sure you can fix it if something goes wrong.
Again, not being super familiar with how boot partitions and EFI and all of that jazz works, I’m not sure just how dangerous doing that would be. If something interrupted the process of writing the image to the eMMC storage or otherwise caused it to fail, wouldn’t booting from the SD card still work and let you try again? Or could writing the image somehow affect the device’s ability to boot at all? I don’t know.
But what’s the worst that could happen? YOLO!
I put the SD card back into my other computer, re-flashed the Arch image, then created a new partition on it with
fdisk and formatted it as ext4 and copied the
archlinux.img to it.
After booting the Pinebook Pro back to Arch using the SD card, I mounted the new partition I had created and, with baited breath, flashed the pre-baked Arch image to the eMMC storage.
Once that completed (thankfully without incident), I ran
poweroff, remved the SD card, crossed my fingers, and booted the Pinebook Pro back up.
BAM! Never had any doubt. Welcome to Arch Linux.
The first thing I realized after completing my joyous victory laps was that my root partition was only 2GB in size, much smaller than the full capacity of the Pinebook Pro’s 64GB eMMC module.
In order to resize an existing partition to use unallocated sectors of a storage device, you actually need to delete and recreate it first. So I booted back into the SD card and used
fdisk to do that. The trick is to make a note of the partition’s starting sector, then delete it, then create a new partition that starts at the same sector but uses the rest of the disk. You should get a prompt when you delete the partition about also deleting the ext4 signature, to which you should answer
no. Once the new partition is created, use
p to save your changes to the eMMC.
After the new larger partition has been created in place of the old one, you need to tell the existing filesystem that it’s got more space now:
Now you can mount it and check how big it is and it should be the full size of the eMMC storage.
Once I finished all of the above, I booted back into Arch off the eMMC and ran through the checklist of setup stuff from the official Arch install guide like setting the system clock, generating an
fstab, setting up the locale (ideally to one for which you can understand the language), vconsole settings, creating a user, etc.
pacman -Syyu on a fresh install of Arch and then deciding which packages to install is a thrill that I can only assume is comparable to sucking large quantities of cocaine into your nasal passage using a rolled up hundred dollar bill. But if you’re an Arch user you don’t need me to tell you that.
I bought a sheet of 10 of these for $10 several years ago and have not regretted it for a single second. I have six left after using this one. I wonder what kind of machine will be blessed with my final sticker, years from now.
In hindsight, I still wonder if the
arch-install-scripts method of setting up Arch would work for the ARM distribution. If I ever need to do this again, I would probably write the pre-baked image to the eMMC, but then delete and reformat the root partition and see if I could follow the normal Arch installation guide using
arch-chroot all the way through to a fresh, bootable system. Ultimately I think you’d end up with essentially the same result. The primary benefit I can see doing it that way would be the ability to set up full disk encryption.
Anyway, after I’ve had more time to play with the Pinebook Pro I’ll probably write more about it. For now I’m very happy with it as a secondary laptop for writing (this blog post, for example) and light web browsing using vimb.
I was finally able to get this thing booting with LUKS encryption, including a graphical password prompt using plymouth. Here are the rough steps I took (I can make another post with a better guide if anyone is interested):
- Boot into SD.
- Mount and backup your unencrypted
/dev/mmcblk2partition to the SD card (use the
rsynccommand detailed in step 7 above).
fdiskto delete your unencrypted partition on the eMMC.
- Create a new bootable partition beginning at the same sector with a size of
+128M, and another partition starting at the next sector after that one ends that fills the rest of the eMMC.
- Format the first partition using
mkfs.ext4, this will be your unencrypted boot partition.
cryptsetupas in the Arch Wiki to set up the second partition as
cryptrootand then format it as ext4.
- Mount the second partition to
/mntand then create a
/mnt/bootdirectory and mount the first partition to that.
- Use the
rsynccommand to restore the backup you took earlier back into
genfstab -U /mntto create a new fstab at
arch-chroot /mntto get into your restored installation.
- Follow the “Configuring mkinitcpio” steps in the Arch Wiki linked above. When editing
/etc/mkinitcpio.confyou should also update the
MODULESline like so (it will kind of work without this, but the screen doesn’t turn on during boot so you’d have to type your decryption password blind):
MODULES=(panfrost rockchipdrm drm_kms_helper hantro_vpu analogix_dp rockchip_rga panel_simple arc_uart cw2015_battery i2c-hid iscsi_boot_sysfs jsm pwm_bl uhid)
- Follow the “Configuring the bootloader” step from the wiki, only make your edits to the
/boot/extlinux/extlinux.conf. When you’re in there, also remove
/bootfrom the front of all the file paths (since
/bootis on its own partition now you want it looking at the root instead).
- Should be able to reboot into your encrypted root now. Next step is to install plymouth from the AUR and follow the Arch Wiki again if you want a graphical password prompt.
Short Permalink for Attribution: rdsm.ca/1y8px