Alpine adventures on an Asus Chromebook C201

wsinatra got me interested in Alpine, and since I had previously looked into other Linux distributions for the C201, I tried Alpine too.

If you're looking for specific commands, have a look at this set of alpine-c201 scripts. (Notice: the scripts will download proprietary wireless/Bluetooth drivers. If you don't want them and already have a network dongle that runs with open drivers, replace the section with the drivers for your adapter.)

Otherwise, read on for a summary of two months' (and ongoing) of fumbling with mostly good results. All of this could be seriously done in a week, but I have other horrible hobbies so I'm learning at a glacial pace (couldn't resist the pun) as I go along.

Week 1

Downloaded the generic armv7 uboot and minirootfs tarballs, then extracted them to external media before booting. It sounded straightforward enough, until I encountered the first snag.

The resulting file system wouldn't boot — the Chromebook beeped and didn't recognise a bootable operating system on the media. I had forgotten the built-in bootloader was selective about the partition sizes and layout. The Arch Linux ARM website has clear instructions on this for a different model with an identical installation procedure.

There was another critical problem: where was the kernel image? An Alpine user mps posted an installation script for the Acer R13 Chromebook, which included a linux-elm package in the list. Unfortunately, no equivalent package existed yet for the C201 in the Alpine repos, either linux-veyron (the ChromeOS kernel) or linux-armv7-chromebook (mainline). However, the Arch Linux ARM linux-veyron package worked, even if the kernel version was very old (3.14.0).

After a minor confusion about the default user (unlike some distributions that have a pre-configured standard user or login password, I had to chroot into the installation from another Linux installation and reset the root password or add a new user before I could log in), eventually I arrived at Alpineland. Yay!

The next obstacle came in the form of a non-functioning built-in wireless device. The brcmfmac wireless module was loaded, but the wlan0 interface couldn't be found. Went back into chroot, imported the Broadcom wireless drivers, installed dbus, udev and WPA supplicant. Bringing up the wireless interface on startup was sometimes unreliable and I had to manually run it after logging in (though there's a workaround in week 8), but at least wireless connections work.

Ultimately it should be possible to create an image with a few basic packages like wireless drivers pre-installed, but most of the steps can be automated with shell scripts which can be easily updated to fetch the latest Alpine release.

Week 2

After importing my home directory and adding some command line utilities, it was time to install a graphical desktop. I have been using the i3 window manager, but Xfce is another relatively light option that runs well on the Chromebook hardware. Logged in again and i3 blinked to life, except there was no keyboard or mouse input inside the graphical interface. Oops, missing xf86-input-evdev and xf86-input-synaptics respectively. Evidently Alpine takes the idea of a minimal install seriously. This can be annoying or gratifying in turns — annoying when trying to track down the package that provides the needed functionality, and gratifying to see the system take shape from packages chosen by the individual.

Week 3

Successfully connected a pair of Bluetooth earphones with working audio after some trial-and-error. This requires 3 key parts: wireless drivers and the btbcm module, btattach to interface via UART, and the Broadcom utility brcm_patchram_plus triggered by udev to initialise the wireless chip. The latter was compiled from source due to Alpine's adoption of musl so existing packages built with glibc wouldn't work. Attempting to run a glibc version would output a misleading no such file or directory error. Also had to manually disable udev-settle because it was lengthening boot times to over 3 minutes by ostensibly waiting for all hardware devices to be detected and loaded.

Once the Bluetooth controller is enabled, the bluetoothctl cli utility should be able to detect it and scan for, as well as connect to, other Bluetooth devices.

From the Bluetooth setup, I got a bit of practice with basic OpenRC commands (having come to Alpine from a systemd environment) after adding an init script for btattach and adding services to different runlevels.

It was also around this time I sifted through a folder of executables in my imported ~/bin and found 6-7 no longer worked due to the glibc/musl difference. Made a list to spring onto the next unsuspecting Alpine packager (just joking, thanks Alpine maintainers for the existing packages).

Week 4

Kernel panic! Actually, it was likely not an Alpine issue, and happened after exiting bluetoothctl caused btattach to abruptly exit a few times. This appears to have been resolved by adding a few seconds' wait to the btattach init.d script.

In Firefox 89, tabs were prone to crashing on some websites, and subsequent updates to Firefox 91 (then to 93) didn't help. I don't know if it is a side-effect of running from an old kernel or the general treatment of 32-bit arm devices by some projects as a fleeting afterthought. Firefox doesn't provide arm builds for Linux on its website, basically meaning they're unsupported. The crashed tabs don't occur in other browsers, such as those based on Webkit. As it even caused some static sites without Javascript to become inaccessible, I have set aside Firefox indefinitely in the hopes it will be usable again one day.

Applied a tip from wsinatra's recent post for Alpine workstations that included installing acpid, cpufreq and tlp for better battery life per charge. Caution: install tlp at your own risk. Enabling the service caused my Alpine system to freeze randomly. YMMV.

At this point going forward, most of the changes would be quality-of-experience adjustments that aren't necessarily attributed to how Alpine runs, but make the system more pleasant to use.

Week 5

My usual go-to for music players is cmus. It's a console player, loads multiple playlists quickly and works well, usually. This time, it couldn't detect the pulse output plugin, so I set the output plugin to alsa after installing alsa-plugins-pulse. This enabled playback, but after a while it began to freeze mid-play.

I prefer applications that are relatively lighter on memory (the C201 doesn't come with much RAM by today's standards after all), and briefly revisited another old GUI go-to, DeaDBeeF. Unfortunately, I couldn't get any audio output from it, and it seemed to load playlists more slowly than what I recalled of it from years ago. Maybe it didn't like loading playlists from mounted network storage.

Eventually installed moc at wsinatra's suggestion, which worked right away. (If the interface appears unresponsive when using the file browsing navigation keys, the cursor may be hidden on some terminal colour schemes. Press shift+t to open the theme switcher and select a theme that highlights the cursor row position.)

Another feature I liked in cmus was being able to listen to radio streams from a .m3u playlist, and moc wouldn't play the URLs when I imported the playlist, but haven't checked the moc documentation yet to see whether there was a way to enable streaming.

Week 6

After an IRC conversation about cross-compiling packages, I started to set up a cross-compiling chroot for aarch64 using the aports/scripts/bootstrap.sh script in aports repository, but it timed out on fetching isl22 from http://isl.gforge.inria.fr/isl-0.22.tar.bz2. The cloog package required isl22-dev, so I couldn't proceed at this time. Another project for another day. In the meantime, I moved my feeble attempts at package building into its own chroot to reduce the likelihood of accidentally breaking the host system's packages.

Week 7

Some days I would resize some images and miss Nomacs for its editing capabilities (scale, crop, basic light/colour adjustments), as well as its batch image processing features. This is probably the one application I really missed since moving to Alpine. Wait, isn't it already in the Alpine repos? It is, but due to a build issue with one of the packages a few hops deep into the dependency chain, the application is unavailable in the repos for armv7. I ran into a build error (as yet unresolved) with pdal, the 2nd hop in the reverse direction on the chain, but it did seem possible to get Nomacs up for armv7 with more prodding.

In the meantime I flipped between Viewnior for viewing and cropping, and GIMP for further operations. Adding a primitive shell script invoking an image utility or library like graphicsmagick for batch resizing would do adequately, so all is not lost.

Week 8

The secret to having the wireless interface come online on startup reliably, along with any proxies/VPNs on top, was NetworkManager. Initially, I had been using ifupdown with WPA supplicant because it was easy to automate setup from one configuration file, minimal like the netctl config files from a previous distribution. In the process of configuring a L2TP/IPsec client that wouldn't connect, I turned to NetworkManager (specifically the nm-connection-editor from network-manager-applet, the nmtui terminal utility that came with networkmanager didn't show some types of VPN connections) and uncovered that additional side-benefit.

wsinatra can now say "I told you so." :)

Onwards

With a functioning Alpine system up and running, I'll wrap up here for now.

In summary, the hardware tested working with the veyron kernel included: wireless (with proprietary drivers), Bluetooth (with proprietary drivers), speakers, headphone jack (audio output) and the webcam. What theoretically should work, but is probably misconfigured at the moment, is the headphone jack for microphone input. Untested and possibly might not operate reliably: hibernate/suspend on closing the lid. On another distribution the wireless interface stayed offline after the lid was closed several times. Usually I power down the Chromebook or switch off the backlight with a keybinding.

It would also be great to have more coverage of armv7 devices in the Alpine documentation, which was fine for x86/x86_64 machines but somewhat sparse for arm — though to be fair, the state of arm devices including which ones have vendors working towards mainline kernel support is still a little chaotic.

Potential future projects:

Updated:  2021-11-10 04:13 UTC