Just some semi-random notes about getting Devuan ARM images and installing a slightly odd one on a Pine RockPro64 board.
Arm Versions Of Devuan
Like many OS providers, Devuan doesn’t really give a damn about ARM chips. That’s unfortunate (for ALL of the providers…) as ARM chips are everywhere. Phones, tablets, Mac low end devices, some ChromeBooks, SBCs of a dozen+ makers and a whole lot more.
The current high end ARM chips beat low end x86 chips in performance tests. This is only going to get worse as we’re hitting the end of the road on Moore’s Law and prior patents are expired or expiring. The original ARM as RISC (reduced instruction set computer) has given way to ARM CISC (Complex …) what with the aarch64 instruction architecture letting you run v7 32 bit or even v6 16 bit instructions, and having versions with multiple pipelines for predictive execution. In short, ARM chips can now be fairly high performance AND they are dirt cheap. A nice combination.
But whatever. Folks are STILL fixated on “Intel” x86 / AMD64 architecture. Partly just because it is mostly just “one thing” to deal with and all the developer sorts have it as their workstation these days. Dumb, but ‘it is what it is’. So ‘moving on’…
Devuan likes to hide where you go to get ’embedded’ or ARM chip versions. Now it looks like to some extent they have “punted” to the user community. So, in prior times, it was in their “Download” page. It isn’t there anymore, as it was moved to the “files” site / URL.
https://www.devuan.org/get-devuan
Notice how much is devoted to x86 and how ARM is told to basically “go fish”:
ISO Guide for i386 and amd64
desktop-live (1.2 GB): Explore the default Xfce desktop before installing. Then install easily and quickly from the live session using the refractainstaller. Firmware is installed but can easily be removed.netinstall (~300 MB): Preferred by more experienced users to create servers, minimal systems but also includes choice of several Desktop Environments (DEs). Not to be used for offline install. Internet connection and available bandwidth needed because all but the core components are downloaded during the installation process. The “expert install” allows user to opt out of firmware installation and a choice of alternate bootloader. A default install will provide firmware.
server (~670 MB): CD1 of a 4 CD set that allows for a complete off-line server/minimal installation. The remaining CDs offer several desktop choices and a limited selection of additional software.
CD2: Xfce (installable from tasksel) and LXDE.
CD3: MATE (installable from tasksel) and Openbox window manager.
CD4: Cinnamon (installable from tasksel) but requires CD2 and CD3 to install.
desktop (4 GB): Use this DVD if there is no network available and/or a need for multiple offline installations. The image contains several desktop choices and additional software options. LXQt and KDE are only available on DVD.minimal-live (~460 MB): A full-featured, console-based recovery tool with a focus on accessibility for visually-impaired and blind users. Uses the refractainstaller.
Note that these Devuan installation ISOs are signed with the key of the developer in charge of them. All developers keys are listed on the Team page.
Installation Media for amd64, arm64, armel, armhf, i386 and ppc64el
netboot: Files for PXE install, mini.isos and installer disk images for some specific boards can be found in the appropriate directory for your $ARCH at
https://pkgmaster.devuan.org/devuan/dists/beowulf/main/installer-$ARCH/current/images/
embedded: The Devuan community provides discussion and information about available ARM images and download locations.
Sigh. Yeah, go fish in the forum and hope nobody is a Bad Guy trolling for a catch.
A typical mirror looks like:
File Size ↓ Date ↓ Parent directory/ - - archive/ - 2019-Nov-21 22:55 devuan_ascii/ - 2019-Nov-22 22:37 devuan_beowulf/ - 2020-Mar-28 05:11 devuan_jessie/ - 2019-Oct-18 04:54 MIRRORS.txt 895 B 2017-May-06 11:15 README.txt 1.3 KiB 2018-Jun-07 11:56 devuan-archive-keyring.gpg 9.3 KiB 2020-Aug-26 06:30 devuan-devs.gpg 85.2 KiB 2019-Dec-18 00:18 devuan_ascii.torrent 1.7 MiB 2021-Jan-19 01:11 devuan_beowulf.torrent 1.2 MiB 2021-Jan-19 01:13 devuan_jessie.torrent 1.3 MiB 2017-May-25 17:54
Now you might think you could just go into the release and download the needed image. Maybe yes, sometimes no… (this one is Leaseweb).
Devuan Jessie, for example, looks like this:
Index of /devuan/devuan_jessie/ File Name ↓ File Size ↓ Date ↓ Parent directory/ - - desktop-live/ - 2017-Oct-19 17:05 embedded/ - 2017-May-31 11:12 installer-iso/ - 2017-May-24 06:39 minimal-live/ - 2017-May-18 18:48 virtual/ - 2017-May-23 11:22 README.txt 1.4 KiB 2017-May-24 09:51
And their bias shows already in calling ALL ARM builds “embedded”. Is a ChromeBook “embedded”? A Mac? My cell phone? Heck even the SBC I’m using right now as my Desktop? Nope.
But whatever… Looking in “embedded” we find:
Index of /devuan/devuan_jessie/embedded/ File Name ↓ File Size ↓ Date ↓ Parent directory/ - - u-boot/ - 2017-May-23 11:19 README.txt 3.0 KiB 2017-May-31 11:12 SHA256SUMS 857 B 2017-May-23 11:19 SHA256SUMS.asc 1.5 KiB 2017-May-23 11:20 devuan_jessie_1.0.0_arm64_raspi3.img.xz 175.2 MiB 2017-May-23 11:20 devuan_jessie_1.0.0_armel_raspi1.img.xz 171.5 MiB 2017-May-23 11:13 devuan_jessie_1.0.0_armhf_chromeacer.img.xz 231.0 MiB 2017-May-23 11:14 devuan_jessie_1.0.0_armhf_chromeveyron.img.xz 234.6 MiB 2017-May-23 11:15 devuan_jessie_1.0.0_armhf_n900.img.xz 154.8 MiB 2017-May-23 11:15 devuan_jessie_1.0.0_armhf_odroidxu.img.xz 154.1 MiB 2017-May-23 11:16 devuan_jessie_1.0.0_armhf_raspi2.img.xz 171.6 MiB 2017-May-23 11:14 devuan_jessie_1.0.0_armhf_sunxi.img.xz 151.8 MiB 2017-May-23 11:17
An OK list of systems with existing ports. Raspberry Pi. Some ChromeThings. The N900 phone (I think…). In theory the Odroid XU family (though I’ve had issues with it). Then SunXi is for several boards with particular processors. Things like Banana Pi I think… Things with an Allwinner SOC (System On Chip – the computer guts on an SBC).
But that was then, this is now…
What’s in the latest release:
Index of /devuan/devuan_beowulf/ File Name ↓ File Size ↓ Date ↓ Parent directory/ - - desktop-live/ - 2020-May-31 23:57 installer-iso/ - 2020-Jun-01 02:18 minimal-live/ - 2020-May-31 23:59 README.txt 1.3 KiB 2020-Mar-13 11:20 Release_notes.txt 13.1 KiB 2020-Jun-13 14:06
Gee, none of those pesky ’embedded’ things…
IFF you dig into the Release Notes file, you can find yet more places to “go fish”:
### Getting Devuan 3 Beowulf
Devuan 3 Beowulf is available for i386, amd64, armel, armhf, arm64 and
ppc64el platforms. Installer isos and live CDs can be downloaded at:
When you look in files.devuan what do you get?
../ desktop-live/ 31-May-2020 23:57 - installer-iso/ 01-Jun-2020 02:18 - minimal-live/ 31-May-2020 23:59 - README.txt 13-Mar-2020 11:20 1308 Release_notes.txt 13-Jun-2020 14:06 13K
Hmmm… still no ’embedded’…
IF you dig around long enough in the form link, Such as this page: https://dev1galaxy.org/viewtopic.php?id=3351, you find them talking about arm-files.devuan…
Which has:
Devuan Trial ARM Images ../ README.txt 19-Nov-2020 21:44 5671 SHA256SUMS 25-Dec-2020 13:50 688 devuan_beowulf_3.0.0_arm64_npir2s_0.2.img.xz 20-Dec-2020 23:10 468M devuan_beowulf_3.0.0_arm64_orangepi_one_plus_0...> 25-Dec-2020 13:51 462M devuan_beowulf_3.0.0_arm64_rockpi4_0.2.img.xz 05-Apr-2020 23:49 525M devuan_beowulf_3.0.0_arm64_rockpro64_0.2.tar.xz 08-May-2020 18:34 249M devuan_beowulf_3.0.0_armel_rpi1_0.3.img.xz 05-Apr-2020 23:49 473M devuan_beowulf_3.0.0_armhf_olinuxino_lime2_0.5...> 04-Jun-2020 21:39 456M
Note that it says “TRIAL” images. As in ‘community built stuff that might work and in who knows what configuration”. So, OK… It’s a young port, limited staff, their sandbox. I’m choosing to play in it. It does work. There are not a lot of other SystemD free options either. So “suck it up and chew some sand”.
Of all the systems listed, only the Raspberry Pi and RockPro64 are ones I’ve got. (My Orange Pi is an H3 chip build, that one is an H6 chipset and ‘different’). BUT, the good news is that I’ve got a RockPro64 that’s been a pain to get a non-SystemD system onto and running. SO figured I’d give it a go.
(“somewhere” on their site I read “something” that said they were pushing ARM devo / porting out to the community, but don’t care to dig around and find it again just now…)
So looks like longer term, I’m going to become an involuntary Systems Programmer / Developer for ARM Linux ports. I’m sort of on the edge of that as an advanced Systems Admin / Programmer, but not thrilled at the involuntary voluntary workload it offers…
RockPro64
Note that the other listed choices end in .img so you just dd (copy) that image onto a uSD card and boot. Note too that RockPro64 says “tar.xz”. An xz compressed tar image. OK…
I downloaded it. “unxz”ed it. Then tar xvf extracted it. This is what you get:
ems@OdroidN2:~/RockPro/devuan_beowulf_3.0.0_arm64_rockpro64_0.2$ ls README.txt mkitnow part1 part2 part3 part4 part5 ems@OdroidN2:~/RockPro/devuan_beowulf_3.0.0_arm64_rockpro64_0.2$ ls -l total 1867704 -rw-r--r-- 1 ems ems 468 May 7 2020 README.txt -rwxr-xr-x 1 ems ems 467 Jan 20 02:27 mkitnow -rw-r--r-- 1 ems ems 4096000 May 8 2020 part1 -rw-r--r-- 1 ems ems 4194304 May 8 2020 part2 -rw-r--r-- 1 ems ems 4194304 May 8 2020 part3 -rw-r--r-- 1 ems ems 117440512 May 8 2020 part4 -rw-r--r-- 1 ems ems 1782579712 May 8 2020 part5
The “readme” is really more of a script that needs an edit:
ems@OdroidN2:~/RockPro/devuan_beowulf_3.0.0_arm64_rockpro64_0.2$ cat README.txt
!# /usr/bin/env bash
# Please Identify the sdcard, What is your disk( /dev/sdx )?
sdX=/dev/sdb
# Prepare the disk **sdX** :
sudo parted ${sdX} --script mklabel gpt \
unit s \
mkpart idbloader 64 8063 \
mkpart uboot 16384 24575 \
mkpart none 24576 32767 \
mkpart boot 32768 262143 \
mkpart rootfs 262144 3743744 \
set 4 boot on \
set 4 esp on \
print
# Write partitions to the disk **sdX**:
for n in {1..5..1};do sudo dd if=part${n} of=${sdX}${n} conv=sync; done
When run on Armbian, it complained that the first line did not work (that /usr/bin/env even though I have it in my search path) so I think it is the difference between systems that the “!#” was not correctly interpreted. Whatever, it went on to work anyway. /usr/bin/env is just to set up an isolated environment from your regular area with all new values for environment variables and such. A bit of reasonable but not necessary paranoia.
As my uSD card in carrier ended up as /dev/sdb anyway, I didn’t even need to edit it.
What this script does is use “parted” to set the partition table on the uSD card, create the partitions, and put the right flags on them, then it does a ‘for loop’ to copy the ‘parts’ unpacked from the tar ‘tape’ into the right partitions. It worked, whatever…
You end up with “The Usual” system with way too small a root partition to install anything much, but without the ‘auto grow’ function set to grow it to fill available free space on the card at first boot.
It then DID boot, but only to a CLI interface. Next I got to add a windows system… and add some users who were not root. Default passwd was “toor” for root. I changed that immediately.
So where am I now?
I’ve got windows installed, and I’ve got a user on it (“minime” ;-) and I’ve done a posting from it using Chromium. I’ve also moved /var and /home onto separate partitions that I made on the uSD card using ‘gparted’, the Graphical partition editor that’s way easier to use (and did that on Armbian using a different boot uSD card…). So now it looks like:
Filesystem 1K-blocks Used Available Use% Mounted on /dev/root 1680656 1154956 422276 74% / devtmpfs 975888 0 975888 0% /dev tmpfs 196908 2644 194264 2% /run tmpfs 5120 4 5116 1% /run/lock tmpfs 393800 0 393800 0% /dev/shm /dev/mmcblk1p4 111063 26227 79102 25% /boot /dev/mmcblk1p6 4062912 623796 3229404 17% /var /dev/mmcblk1p7 8191416 78844 7693144 2% /home /dev/mmcblk1p8 1051700 606752 389860 61% /usr/share tmpfs 393800 192 393608 1% /tmp tmpfs 984528 0 984528 0% /sys/fs/cgroup tmpfs 196904 4 196900 1% /run/user/1002
Why not just ‘grow’ the / (root) partition? Because in gparted I saw that it was ext4. You will remember that there was an incompatible ‘improved’ ext4 rolled out. IF an older ext4 is touched by a newer system, it becomes unusable on the older system. For that reason, I have moved back to all my partitions being ext3 if at all possible. I only leave the initial booted root partition as ext4 on a new build, and that only because changing all the boot-crap to look for ext3 is a pain (AND a new install ext4 doesn’t need to work on an older system, though I may want to edit, repair, or copy off stuff from the other file system areas on a system using some older one.
Eventually this issue will “go away”. Perhaps when a sane new EXT5 is rolled out (what OUGHT to have been done with ext4+1 instead of screwing up your ability to read partitions on other systems…). But until that day, I’m not touching ext4 unless the alternative is painful to a greater degree. Besides, ext3 works fine too.
But, in fact, I likely ought to have grown / (root) by some amount. As it was, after installing a few bits, the /usr/share was growing enough to use up the available space. (Anyone remember when /var was created to ‘hold all the stuff that changes’… but now other folks have gone to putting more ‘stuff that changes’ in places other than /var. Oh Well…)
“Someday” I’ll redo all of this from scratch again to clean up the unclean bits. For now I’m still in the ‘discovery’ phase where you find out what all works, what doesn’t, will it work well enough, and what strange bits are in THIS build.
But hey, it’s working. What more do you want? /sark;
I do still need to install some bits, but most of the big stuff is here now. Libreoffice, GIMP, a couple of windows systems.
Installing LXDE was at first a no-go. Then I found out I needed to do:
apt-get install task-lxde-desktop
not just lxde… and now it’s working.
In Conclusion
So there you have it. What I’ve been doing today instead of looking at the Political Bull Shit Show in D.C.
There is something cathartic about the nature of work.
I’m also very pleased that I can now more readily put the RockPro64 into my regular work rotation. I’d been using it as an Armbian system (and still have that uSD chip and will use it sometimes still), but quasi-resented the need to use SystemD calls to do various maintenance / admin stuff. (Yeah, good to have the skill. No, don’t want it…)
This will also give me a chance to play with Devuan 3.0 Beowulf (that only now has transitioned to stable…) so I can see what-all might be different or not quite ready yet. Which reminds me:
On my first attempt at:
apt-get update
It failed. The message was that I had to explicitly accept that the release level had changed from (something) to stable. That’s done with an option to apt-get. ” –allow-releaseinfo-change” So you need to do:
apt-get --allow-releaseinfo-change update
to get past that.
Things you learn… But this also says the image in the tar file was made prior to that shift of release level. Just sayin’ that it isn’t that new nor built on stable, so an upgrade does matter.
That kind of covers this particular episode of Adventures In ARM Linux Land. In the end, I got a usable system, but NOT by anything that ought to be a production method.
IMHO, Devuan needs to make ARM more production if they intend to gain any ground in the huge turf of devices and systems that use ARM chips, and THAT is a rapidly growing part of total computes. Not just the IOT embedded devices, but ChromeBooks, Macintosh systems, phones, tablets and a whole lot more. Including my desktops.
So something good happened today. Even in the present political hurricane of lies and deception, you can find a quite eye of truth and success. All you need to do is look for it, or create it.
Musings from the Chiefio 
My Christmastide reading this year included Linux Format Annual 2021 – there’s a section in that specifically on Chromebooks and installing Linux either alongside or instead of ChromeOS. Possible links of interest (I’ll leave out the header so as (I hope) not to trip the too-many-link switch) would include:
# For modifying firmware when needed, preferably not bricking the thing:
mrchromebox.tech
# Crouton, scripts that set up a Linux chroot on ChromeOS:
goo.gl/fd3zc (Hate linking to them but I guess they ‘have an interest’ …) and
github.com/dnschneid/crouton
# chrx – boot Chromebook straight into Linux:
github.com/reynhout/chrx#chromebooks
# Crostini – uses ChromeOS’s built in hypervisor to run a Linux VM; the official list of supported devices is at:
bit.ly/lxf250crostini
chrx’s preferred system is GalliumOS, which integrates the original Chromebook touchpad driver “so that delightfully swipey experience need not be lost” (it’s quotes like that, as much as the price of mags these days, which keep me down to a one-a-year fix) – though having said that, a look at their page reveals that an ARM version is ‘unlikely’.
They also mention ‘several’ Kali builds for small ARM machines, but the link on the page didn’t work on the net. That could turn a Chromebook into a machine an old sysadmin could play with.
I almost wish I had one to play with myself – still, my 1.8GHz Dell netbook running on antiX will do for now … one of these years I’ll get round to clearing out some of my old junk to make space for some new junk ;-)
Pingback: Raspberry Pi M3 i2p Server Full Install | Musings from the Chiefio