💾 Archived View for tilde.town › ~mio › log › 2021-11-10-chromebook.gmi captured on 2024-05-12 at 15:32:38. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2024-05-10)
-=-=-=-=-=-=-
---
date: 2021-11-10T04:13:00Z
update: 2024-05-09T00:52:10Z
---
Google Veyron Chromebook — postmarketOS wiki
--
wsinatra got me interested in Alpine, and having previously looked into other Linux distributions for the C201, eventually 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 having other horrible hobbies tends to result in learning at a glacial pace (couldn't resist the pun).
wsinatra's website with more Alpine articles
Asus Chromebook C201 page at the Gentoo Wiki
Update 2023-08-08: the alpine-c201 scripts have moved to a shared zettelkasten.
Alpine on Asus Chromebook C201
Downloaded the generic armv7 uboot and minirootfs tarballs, then extracted them to external media before booting. It sounded straightforward enough, until the first snag.
The resulting file system wouldn't boot — the Chromebook beeped and didn't recognise a bootable operating system on the media. Completely forgot 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, had to chroot into the installation from another Linux installation and reset the root password or add a new user before it would permit login), and eventually 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, having 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.
After importing my home directory and adding some command line utilities, it was time to install a graphical desktop. i3 window manager works fantastically, 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.
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.
Already got a bit of practice with basic OpenRC commands because of the Bluetooth setup (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 that a folder of executables in my imported `~/bin` was sifted through for migration, with the result that 6-7 of them 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).
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. 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 Firefox was set aside 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.
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. Setting the output plugin to alsa after installing `alsa-plugins-pulse` enabled playback, but after a while it began to freeze mid-play.
Applications that are relatively lighter on memory are generally preferable especially given the C201 doesn't come with much RAM by today's standards. Briefly revisited another old GUI go-to, DeaDBeeF. Unfortunately couldn't get any audio output from it, and it seemed to load playlists more slowly than my recollection 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 to like in cmus was being able to listen to radio streams from a .m3u playlist, and moc wouldn't play the URLs when playlist was imported, but haven't checked the moc documentation yet to see whether there was a way to enable streaming.
After an IRC conversation about cross-compiling packages, 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 isl.gforge.inria.fr. The cloog package required isl22-dev, so couldn't proceed at this time. Another project for another day. Moved my feeble attempts at package building into its own chroot in the meantime to reduce the likelihood of accidentally breaking the host system's packages.
http://isl.gforge.inria.fr/isl-0.22.tar.bz2
Occasionally resizing some images made me 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 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. 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.
Flipped between Viewnior for viewing and cropping, and GIMP for further operations in the interval. Adding a primitive shell script invoking an image utility or library like graphicsmagick for batch resizing would do adequately, so all is not lost.
The secret to having the wireless interface come online on startup reliably, along with any proxies/VPNs on top, was NetworkManager. Initially 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, 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." :)
With a functioning Alpine system up and running, this post will 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 the Chromebook is powered down or the backlight switched off 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: