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:
- Package the veyron kernel
- Research into running a newer kernel, most likely mainline
- Package the applications on the pending list where feasible