Ayufan prepares Debian and Ubuntu images and packages for the Pine Rock64, RockPro64, and PineBook Pro. These images contain custom kernels and bootloaders specifically for the Pine ARM boards they target.

I recently installed the 0.8.0rc6 Rock64 image on my device, and wanted to share my experience. The documentation was not the most clear, but the process to flash the image to an SD card and plug the power in is simple enough to not necessarily need an explanation. Boot went without a hitch – the device quickly acquired a lease and I was able to SSH in with the default user and password (rock64).

Default services

After getting a shell, I was surprised by how many services were running out of the box. From memory, there was:

NetworkManager

systemd-networkd

dhcpcd

dhclient

wpa_supplicant

Avahi

systemd-resolved

polkitd

systemd-logind

dbus

systemd-journald

rsyslogd

systemd-udevd

ntpd

opensshd

I can only assume the breadth of networking services is provided as an earnest attempt to establish connectivity by any means necessary, but many of them have overlapping responsibilities and are likely not necessary.

Customization steps

I gradually peeled back the networking services by stopping each one, verifying that the connection remained intact, then disabling and masking the service and testing with a reboot.

I left the ifupdown started dhclient process intact, but this may not have been the best choice. I am currently plagued by a 90s systemd timeout because the ifupdown provided services ( networking.service and ifup@.service ) are conflicting with each other. I will likely switch to using busybox’s DHCP client in the future to work around this issue.

[edit] The timeout was caused by wpa_supplicant@.service waiting for one of the ifupdown services.

My next steps were to trim the other services and lock down SSH access. Currently, I am left with ntpd, sshd, dhclient, and udev. I plan to enable busybox’s syslog daemon, and trigger logrotate using snooze.

Odd jobs

The default repositories are unfortunately a frankenstein of official Debian repositories, ayufan’s self-hosted debian repo, and a xenial pinned PPA. I doubt that the Debian community will care to support such a setup.

There are some curious files on the image’s rootfs, such as /usr/local/sbin/rock64_fix_performance.sh , which is run both as a cron @reboot job and a systemd service. Whether this special sauce is necessary or even beneficial is beyond my knowledge, but the documentation of these artifacts is limited and many of them are strewn about on the image. Ideally scripts like this would live in /usr/lib/ayufan-rock64 and be shipped in Debian packages so that they can be updated.

Concluding thoughts

Overall, the distro is put together fairly well, but there is certainly room for improvement. Getting closer to a stock Debian rootfs should be a primary goal, as this will ensure the long term viability of the distro. Ensuring that every file shipped on the image can be accounted for with dpkg or regenerated by the running system is equally important. One off scripts that cannot be updated are an unfortunate time bomb.

Thank you, ayufan, for helping create a working solution. I hope my feedback helps improve your distribution.