Of FrankenSystems Builds & dist-upgrade Devuan Arm

To some extent this will be a ‘work in progress’ for a little while. After I’m done I’ll remove this ‘heads up’. For now, I’m going to document what I remember from doing it a few times, and then when I do it some more, clean up the details.

There’s 2 different processes being documented here. One is the “normal” Debian / Devuan / Ubuntu distribution upgrade via the “apt dist-upgrade’ command. This lets you take, for example, a Devuan Ascii 2.0 release from the mirror site and turn it into a Devuan Beowulf 3.0 release via changing the entries in /etc/apt/sources.list and using the command “apt-get dist-upgrade” (then waiting a few hours for “stuff to happen” ;-)

The other is creating a “FrankenSystem” via grafting together parts of other divergent systems. In particular, a Devuan “Userland” (all those programs you normally use and interact with) over the system side stuff (kernel, dtb device tree bundle, kernel modules, firmware, /boot commands) from some other system already ported to your computer.

That 2nd one works when the kernel is of a compatible release level to the userland in question and when the base system is ported to that SBC (Single Board Computer) while the userland is one that works on that base system and is compatible with that hardware (so, for example, aarch64 code runs on ARM 64 bit processors and armhf code runs on V7 32 bit AND ARM v8 64 bit processors.

I made one FrankenSystem that used a v7 armhf 32 bit userland on an aarch64 64 bit kernel and device drivers. I did that back when the aarch64 userland still had some buggy bits like browsers and I wanted things a bit more stable. It also can use memory more effectively.

Note that there are some “issues” with this. A FrankenSystem can have minor incompatibilities if the kernel level is not exactly right (though usually only major numbers matter). Doing “upgrades” are mostly limited to “apt upgrade” as a “dist-upgrade” will try to touch parts from the base that was supporting the graft, and that may or may not work out well.

But mostly, so far, it has worked reasonably well for me. I’ve even got one uSD chip for the Raspberry Pi where there’s a /boot with 2 boot.cmd lines and swapping them lets me boot either as a 64 bit or a 32 bit userland. (Or even boot a Gentoo image).

This can be a bit exotic when you first start looking at it, but at the core of it, it isn’t all that hard, really. THE most important thing is to have a GOOD backup copy of any system you are going to Franken Up or dist-upgrade before you start. That way you can always fall back and try again. The other is to have some OTHER uSD card or emmc chip you can boot so that you can fix minor mistakes without an entire restart.

One example of that. Say you have a v7 32 bit system at mmcblk0s1 and a v8 64 bit system at mmcblk0s2. Somewhere in /boot (that is sometimes an ms-dos FAT partition) will be a boot command. It may be boot.cmd or boot.ini or something else. In it will be a description of the partition to boot up. If, in changing that from s1 to s2 you also changed it to mmcblk1s2 your system will not boot. Notice that little “1” that crept in in front of the ‘2’? That points it to a card that doesn’t exist… Easy to fix. Boot up your spare system image, plug the uSD into a USB adapter. Mount it as a file system and edit the boot command to what it ought to be. (I’ve done that more than I care to admit…). Similarly, your 0s1 might be an ext4 file system but you build 0s2 as ext3 and forgot to change that token in the string. Instead of “dead in the water” you have “boot alternate image and edit the file to make it right.” MUCH less traumatic.

So with that, on to the show.

Doing A dist-upgrade Of Devuan

Devuan, with the latest release, have made ARM chip “support” a “community build” thing. That is fine for them, but sucky for any Noobs who just want to install and run their operating system. I hope they get more traction and a bit more money and can actually embrace the ARM chip world…

The really “good news” is that the older Ascii 2.0 build is still in the download mirrors so you can install it, then do a distribution upgrade to the newest Beowulf 3.0 build. I’ve done that on the Raspberry Pi and on the Odroid XU4.

The basic process here is pretty darned simple:

1) Download and install a Devuan ASCII image.
2) Configure /etc/apt/sources.list for Beowulf (change ascii to beowulf).
3) As root, issue “apt dist-upgrade”
4) Go eat lunch and have a slow coffee… it can take a while.
5) Reboot.

This site has a nice overview / intro to doing it in Debian / Ubuntu. Mostly it differs from what I did in that I don’t bother taking out the trash (“autoremove”) along the way.


Let’s walk through that release upgrade cycle with a Raspberry Pi running Devuan ASCII. First you get the image and install it.


Devuan Release Archive
u-boot/ 06-Jun-2018 11:28 –
README.txt 06-Jun-2018 11:28 2795
SHA256SUMS 06-Jun-2018 11:28 2412
SHA256SUMS.asc 06-Jun-2018 11:28 1528
ddroid-2018-06-05.zip 06-Jun-2018 11:28 6M
devuan_ascii_2.0.0_arm64_raspi3.img.xz 06-Jun-2018 11:28 153M
devuan_ascii_2.0.0_arm64_raspi3.tar.gz 06-Jun-2018 11:28 221M
devuan_ascii_2.0.0_armel_raspi1.img.xz 06-Jun-2018 11:28 145M
devuan_ascii_2.0.0_armel_raspi1.tar.gz 06-Jun-2018 11:28 210M
devuan_ascii_2.0.0_armhf_beagleboneblack.img.xz 06-Jun-2018 11:28 146M
devuan_ascii_2.0.0_armhf_beagleboneblack.tar.gz 06-Jun-2018 11:28 205M
devuan_ascii_2.0.0_armhf_chromeacer.img.xz 06-Jun-2018 11:28 189M
devuan_ascii_2.0.0_armhf_chromeacer.tar.gz 06-Jun-2018 11:28 281M
devuan_ascii_2.0.0_armhf_droid4.img.xz 06-Jun-2018 11:28 132M
devuan_ascii_2.0.0_armhf_droid4.tar.gz 06-Jun-2018 11:28 185M
devuan_ascii_2.0.0_armhf_n9.img.xz 06-Jun-2018 11:28 134M
devuan_ascii_2.0.0_armhf_n9.tar.gz 06-Jun-2018 11:28 186M
devuan_ascii_2.0.0_armhf_n900.img.xz 06-Jun-2018 11:28 131M
devuan_ascii_2.0.0_armhf_n900.tar.gz 06-Jun-2018 11:28 188M
devuan_ascii_2.0.0_armhf_n950.img.xz 06-Jun-2018 11:28 134M
devuan_ascii_2.0.0_armhf_n950.tar.gz 06-Jun-2018 11:28 186M
devuan_ascii_2.0.0_armhf_odroidxu4.img.xz 06-Jun-2018 11:28 144M
devuan_ascii_2.0.0_armhf_odroidxu4.tar.gz 06-Jun-2018 11:28 205M
devuan_ascii_2.0.0_armhf_raspi2.img.xz 06-Jun-2018 11:28 152M
devuan_ascii_2.0.0_armhf_raspi2.tar.gz 06-Jun-2018 11:28 215M
devuan_ascii_2.0.0_armhf_sunxi.img.xz 06-Jun-2018 11:28 131M
devuan_ascii_2.0.0_armhf_sunxi.tar.gz 06-Jun-2018 11:28 183M

I’m going to assume you can do the basic installation already (if not, there’s other articles posted). Note that before too long Ascii will be archived off somewhere else, so download any images you think you might want “some day” for this dist-upgrade path.

Here’s the contents of the README.txt file:

Devuan ASCII ARM builds

These are the images offered. I kindly ask of you to test them out and
report all weirdness as a Devuan bug (bugs.devuan.org), or on the
#devuan-arm IRC channel.

SHA256SUMS are signed with parazyd's GPG key that can be found in the
Devuan Developers' Keyring: https://files.devuan.org/devuan-devs.gpg

Master fingerprint is:

	0333 7671 FDE7 5BB6 A85E  C91F B876 CB44 FA1B 0274

The login credentials for these images are:


Consult https://git.devuan.org/sdk/arm-sdk/blob/master/doc/quirks.md
to see if there is anything you should know about a specific image.

Currently supported images:

	* Acer Chromebook (chromeacer)
	* Veyron/Rockchip Chromebook (chromeveyron)
	* Nokia N900 (n900)
	* Nokia N950 (n950)
	* Nokia N9 (n9)
	* Motorola Droid 4 (droid4)
	* Odroid XU (odroidxu)
	* Odroid XU4 (odroidxu4)
	* Raspberry Pi 0 and 1 (raspi1)
	* Raspberry Pi 2 and 3 (raspi2)
	* Raspberry Pi 3 64bit (raspi3)
	* Beaglebone Black (beagleboneblack)

Allwinner boards with mainline U-Boot and mainline Linux can be booted
using the sunxi image, and flashing the according u-boot blob found in
the u-boot directory here. The filenames are board-specific, but this
file is commonly known as "u-boot-sunxi-with-spl.bin".

Currently supported Allwinner boards:

	* Olimex OLinuXino Lime (A10)
	* Olimex OLinuXino Lime (A20)
	* Olimex OLinuXino Lime2 (A20)
	* Olimex OLinuXino MICRO (A20)
	* Banana Pi (A20)
	* Banana Pro (A20)
	* CHIP (R8)
	* CHIP Pro (GR8)
	* Cubieboard (A10)
	* Cubieboard2 (A20)
	* Cubietruck (A20)
	* Cubieboard4 (A80)
	* Cubietruck Plus (A83t)
	* Lamobo R1 (A20)
	* OrangePi2 (H3)
	* OrangePi Lite (H3)
	* OrangePi Plus (H3)
	* OrangePi Plus 2E
	* OrangePi Zero (H2+)
	* OrangePi (A20)
	* OrangePi Mini (A20)
	* Allwinner-based q8 touchscreen tablet (A33)


other useful documentation can be found here:
	* https://www.raspberrypi.org/documentation/installation/installing-images/mac.md

	Download the image you want:
	; curl -O https://files.devuan.org/devuan_ascii/embedded/devuan_ascii_2.0.0_armhf_sunxi.img.xz

	Download the shasums and the signature:
	; curl -O https://files.devuan.org/devuan_ascii/embedded/SHA256SUMS
	; curl -O https://files.devuan.org/devuan_ascii/embedded/SHA256SUMS.asc

	; gpg --verify SHA256SUMS.asc && sha256sum -c SHA256SUMS

	dd the raw image to a medium of your choice (little less than 2GB):
	; xzcat devuan_ascii_2.0.0_armhf_sunxi.img.xz | sudo dd of=/dev/mmcblk0 bs=2M

	In case it's a sunxi image, grab your respective u-boot blob, and flash it:
	; curl -O https://files.devuan.org/devuan_ascii/embedded/u-boot/Cubieboard2_defconfig.bin
	; sudo dd if=Cubieboard2_defconfig.bin of=/dev/mmcblk0 bs=1024 seek=8 && sync

Note that since the “Allwinner” Chinese chips are in a lot of boards, the sunxi image works on many boards.

After the instal and first boot, you get to do the the update / upgrade cycle.

Then as root, edit the /etc/apt/sources.list file:

root@devuan:/# more /etc/apt/sources.list
## package repositories
deb http://pkgmaster.devuan.org/merged ascii main contrib non-free
deb http://pkgmaster.devuan.org/merged ascii-updates main contrib non-free
deb http://pkgmaster.devuan.org/merged ascii-security main contrib non-free
#deb http://pkgmaster.devuan.org/merged ascii-backports main contrib non-free

## source repositories
#deb-src http://pkgmaster.devuan.org/merged ascii main contrib non-free
#deb-src http://pkgmaster.devuan.org/merged ascii-updates main contrib non-free
#deb-src http://pkgmaster.devuan.org/merged ascii-security main contrib non-free
#deb-src http://pkgmaster.devuan.org/merged ascii-backports main contrib non-free

I’m not building packages from sources, so the deb-src entries are commented out with a leading “#” pound sign.

Change the “acsii” to “beowulf” (or whatever the next release level is for your system) and save it.

Then do the update / upgrade / dist-upgrade cycle. It will take a while…

I like to do an “update / upgrade to bring the ASCII up to newest state before doing the dist-upgrade. It probably doesn’t matter, but by having everything the newest possible, it might avoid some chain dependencies where some Beowulf update depends on a newest ASCII library that isn’t in place.

How long the update / upgrade and dist-upgrade will take depends on how much stuff is installed and how out of date your system might be. Clearly it is faster to dist-upgrade a minimal system, then install your applications like LibreOffice and Gimp. But I’m updating a fully configured system here, so these times are ‘worst case’ candidates…

Before doing updates / upgrades, check your available free space:

ems@devuan:~$ df
Filesystem     1K-blocks     Used Available Use% Mounted on
/dev/root        8226232  4457556   3399944  57% /

I’ve got 3.4 GB free. That’s way more than enough I think.

root@devuan:/# apt-get update          
Get:1 http://pkgmaster.devuan.org/merged ascii InRelease [33.2 kB]
Get:2 http://pkgmaster.devuan.org/merged ascii-updates InRelease [26.0 kB]
Get:3 http://pkgmaster.devuan.org/merged ascii-security InRelease [26.3 kB]
Get:4 http://pkgmaster.devuan.org/merged ascii-security/main arm64 Packages [603 kB]
Get:5 http://pkgmaster.devuan.org/merged ascii-security/main Translation-en [309 kB]                                  
Fetched 998 kB in 11s (90.0 kB/s)                                                                                     
Reading package lists... Done

root@devuan:/# time apt-get upgrade
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer required:
  cracklib-runtime gdisk gvfs-common gvfs-libs libatasmart4 libcdio-cdda1 libcdio-paranoia1 libcrack2 libgdata-common
  libgdata22 libgoa-1.0-0b libgoa-1.0-common liboauth0 libpwquality-common libpwquality1 libudisks2-0
Use 'apt autoremove' to remove them.
The following packages will be upgraded:
  ca-certificates libcaca0 libservlet3.1-java libupnp6 libzmq5 linux-libc-dev login passwd wpasupplicant
9 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 5334 kB of archives.
After this operation, 24.6 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 http://pkgmaster.devuan.org/merged ascii-security/main arm64 login arm64 1:4.4-4.1+deb9u1 [785 kB]
Get:2 http://pkgmaster.devuan.org/merged ascii-security/main arm64 passwd arm64 1:4.4-4.1+deb9u1 [949 kB]
Get:3 http://pkgmaster.devuan.org/merged ascii-security/main arm64 ca-certificates all 20200601~deb9u2 [168 kB]
Get:4 http://pkgmaster.devuan.org/merged ascii-security/main arm64 libcaca0 arm64 0.99.beta19-2.1~deb9u2 [336 kB]
Get:5 http://pkgmaster.devuan.org/merged ascii-security/main arm64 libservlet3.1-java all 8.5.54-0+deb9u6 [404 kB]
Get:6 http://pkgmaster.devuan.org/merged ascii-security/main arm64 libupnp6 arm64 1:1.6.19+git20160116-1.2+deb9u1 [143 kB]
Get:7 http://pkgmaster.devuan.org/merged ascii-security/main arm64 libzmq5 arm64 4.2.1-4+deb9u4 [180 kB]
Get:8 http://pkgmaster.devuan.org/merged ascii-security/main arm64 linux-libc-dev arm64 4.9.258-1 [1545 kB]
Get:9 http://pkgmaster.devuan.org/merged ascii-security/main arm64 wpasupplicant arm64 2:2.4-1+deb9u9 [824 kB]
Fetched 5334 kB in 5s (984 kB/s)       
Preconfiguring packages ...
(Reading database ... 119546 files and directories currently installed.)
Preparing to unpack .../login_1%3a4.4-4.1+deb9u1_arm64.deb ...
Unpacking login (1:4.4-4.1+deb9u1) over (1:4.4-4.1) ...
Setting up login (1:4.4-4.1+deb9u1) ...
Installing new version of config file /etc/securetty ...
(Reading database ... 119546 files and directories currently installed.)
Preparing to unpack .../passwd_1%3a4.4-4.1+deb9u1_arm64.deb ...
Unpacking passwd (1:4.4-4.1+deb9u1) over (1:4.4-4.1) ...
Setting up passwd (1:4.4-4.1+deb9u1) ...
(Reading database ... 119546 files and directories currently installed.)
Preparing to unpack .../0-ca-certificates_20200601~deb9u2_all.deb ...
Unpacking ca-certificates (20200601~deb9u2) over (20200601~deb9u1) ...
Preparing to unpack .../1-libcaca0_0.99.beta19-2.1~deb9u2_arm64.deb ...
Unpacking libcaca0:arm64 (0.99.beta19-2.1~deb9u2) over (0.99.beta19-2.1~deb9u1) ...
Preparing to unpack .../2-libservlet3.1-java_8.5.54-0+deb9u6_all.deb ...
Unpacking libservlet3.1-java (8.5.54-0+deb9u6) over (8.5.54-0+deb9u5) ...
Preparing to unpack .../3-libupnp6_1%3a1.6.19+git20160116-1.2+deb9u1_arm64.deb ...
Unpacking libupnp6 (1:1.6.19+git20160116-1.2+deb9u1) over (1:1.6.19+git20160116-1.2) ...
Preparing to unpack .../4-libzmq5_4.2.1-4+deb9u4_arm64.deb ...
Unpacking libzmq5:arm64 (4.2.1-4+deb9u4) over (4.2.1-4+deb9u3) ...
Preparing to unpack .../5-linux-libc-dev_4.9.258-1_arm64.deb ...
Unpacking linux-libc-dev:arm64 (4.9.258-1) over (4.9.246-2) ...
Preparing to unpack .../6-wpasupplicant_2%3a2.4-1+deb9u9_arm64.deb ...
Unpacking wpasupplicant (2:2.4-1+deb9u9) over (2:2.4-1+deb9u8) ...
Setting up libzmq5:arm64 (4.2.1-4+deb9u4) ...
Setting up linux-libc-dev:arm64 (4.9.258-1) ...
Setting up wpasupplicant (2:2.4-1+deb9u9) ...
Setting up libservlet3.1-java (8.5.54-0+deb9u6) ...
Processing triggers for libc-bin (2.24-11+deb9u4) ...
Setting up libupnp6 (1:1.6.19+git20160116-1.2+deb9u1) ...
Processing triggers for man-db ( ...
Processing triggers for dbus (1.10.28-0+deb9u1+devuan2) ...
Setting up libcaca0:arm64 (0.99.beta19-2.1~deb9u2) ...
Setting up ca-certificates (20200601~deb9u2) ...
Updating certificates in /etc/ssl/certs...
0 added, 0 removed; done.
Processing triggers for libc-bin (2.24-11+deb9u4) ...
Processing triggers for ca-certificates (20200601~deb9u2) ...
Updating certificates in /etc/ssl/certs...
0 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...


real	3m8.682s
user	0m20.043s
sys	0m25.729s

So 3 minutes and 5 MB of ‘archives’ in /var/cache/apt. Not bad for a simple upgrade cycle.

Now we do the dist-upgrade. Edit the sources file with the editor of your choice. I’m “old school” so use vi, but ed, sed, emacs, even the horrible “nano” that’s very hand-holdy will do. “root@devuan:/# vi /etc/apt/sources.list”

If you are worried, save a copy of the original copy with something like “cp /etc/apt/sources.list /etc/apt/OLD_sources.list” and be happy.

Change ascii to beowulf.

After the edit:

cat /etc/apt/sources.list
## package repositories
deb http://pkgmaster.devuan.org/merged beowulf main contrib non-free
deb http://pkgmaster.devuan.org/merged beowulf-updates main contrib non-free
deb http://pkgmaster.devuan.org/merged beowulf-security main contrib non-free
deb http://pkgmaster.devuan.org/merged beowulf-backports main contrib non-free

## source repositories
#deb-src http://pkgmaster.devuan.org/merged beowulf main contrib non-free
#deb-src http://pkgmaster.devuan.org/merged beowulf-updates main contrib non-free
#deb-src http://pkgmaster.devuan.org/merged beowulf-security main contrib non-free
#deb-src http://pkgmaster.devuan.org/merged beowulf-backports main contrib non-free

The last time I did this, I did another update / upgrade and then the dist-upgrade. I think you can just jump straight to the dist-upgrade, but I’ve not tested it. So I’m just going to 2-step it again.

As the listings are large, I’ll not paste it all in here. Just the start and end bits.

Note that I put the command “time” in front of the upgrade command so it reports how long it took at the end. That’s entirely optional.

so “time apt-get upgrade” tells how long it took, but “apt-get upgrade” will do the same actual work. Oh, and I’ve seen some folks with just “apt upgrade”. I’m not sure if that’s a distribution variation or just an alias or what. I’ve not cared enough to find out and I’ve typed apt-get for so many years I’ve usually typed it before thinking about it. Maybe someday I’ll find out if the “-get” part is optional or irrelevant…

root@devuan:/# time apt-get update
Get:1 http://pkgmaster.devuan.org/merged beowulf InRelease [33.2 kB]
Get:2 http://pkgmaster.devuan.org/merged beowulf-updates InRelease [26.0 kB]
Get:3 http://pkgmaster.devuan.org/merged beowulf-security InRelease [25.6 kB]
Get:4 http://pkgmaster.devuan.org/merged beowulf-backports InRelease [26.3 kB]
Get:5 http://pkgmaster.devuan.org/merged beowulf/main arm64 Packages [7860 kB]
Get:6 http://pkgmaster.devuan.org/merged beowulf/main Translation-en [6295 kB]                                        
Get:7 http://pkgmaster.devuan.org/merged beowulf/contrib arm64 Packages [38.5 kB]                                     
Get:8 http://pkgmaster.devuan.org/merged beowulf/contrib Translation-en [44.1 kB]
Get:9 http://pkgmaster.devuan.org/merged beowulf/non-free arm64 Packages [54.0 kB]
Get:10 http://pkgmaster.devuan.org/merged beowulf/non-free Translation-en [88.2 kB]
Get:11 http://pkgmaster.devuan.org/merged beowulf-updates/main arm64 Packages [9532 B]
Get:12 http://pkgmaster.devuan.org/merged beowulf-updates/main Translation-en [6839 B]
Get:13 http://pkgmaster.devuan.org/merged beowulf-updates/non-free arm64 Packages [608 B]
Get:14 http://pkgmaster.devuan.org/merged beowulf-updates/non-free Translation-en [673 B]
Get:15 http://pkgmaster.devuan.org/merged beowulf-security/main arm64 Packages [264 kB]
Get:16 http://pkgmaster.devuan.org/merged beowulf-backports/main arm64 Packages [454 kB]
Get:17 http://pkgmaster.devuan.org/merged beowulf-backports/main Translation-en [308 B]
Get:18 http://pkgmaster.devuan.org/merged beowulf-backports/contrib arm64 Packages [8764 B]
Get:19 http://pkgmaster.devuan.org/merged beowulf-backports/non-free arm64 Packages [22.1 kB]
Fetched 15.3 MB in 39s (386 kB/s)                                                                                     
Reading package lists... Done

real	1m41.967s
user	0m16.950s
sys	0m3.469s

So 15 MB is not that much, and 1 3/4 minutes. Now for the long upgrade part. Realize this is only the first long part of the total dist-upgrade cycle…

root@devuan:/# time apt-get upgrade
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Calculating upgrade... Done
  xscreensaver xserver-common xserver-xorg-input-libinput xserver-xorg-input-wacom xserver-xorg-legacy xxd xz-utils yelp-xsl zlib1g
707 upgraded, 0 newly installed, 0 to remove and 453 not upgraded.
Need to get 269 MB of archives.
After this operation, 33.1 MB of additional disk space will be used.
Do you want to continue? [Y/n]

I’ve got the 269 MB of space, but 707 packages to upgrade will take a while.

In the middle of the unpacking setting up stuff it asks permission to restart services. I just answered ‘yes’ and went on. This does mean you need to check the screen every so often for that point though… This snippet is after the ncurses menu asking permission where I chose the “yes” option:

Setting up libpam0g:arm64 (1.3.1-5) ...
Checking for services that may need to be restarted...Checking init scripts...

Restarting services possibly affected by the upgrade:
  cron: stopping...starting...done.

Services restarted successfully.

This process is largely I/O bound. CPU usually showing between 10% and 15% in htop, though with some bursts to higher. Mostly is shows red D short term ‘disk’ waits for /usr/bin/dpkg and worker processes as this is largely a “bit shoveling” operation to the uSD card. Memory running about 400 to 500 MB used with the browser open. If you want it a lot faster, put /usr and /var on real disk partitions… or a USB SSD Device. But then you are spending more than the computer cost ;-)

It finally completed after 76 minutes. At that point I launched the browser again to update this entry, and launched htop again, and copied some text from the terminal… and the system hung. Not sure why, but I did a powerfail to recover it. After the reboot it’s fine again. Likely it’s a bad idea to launch a bunch of programs in the middle of a system update ;-)

So we’re into this about 1.5 hours so far, and that’s about 1/2 way. Next will be the “apt-get dist-upgrade”, then we’re done.

root@devuan:/# time apt-get dist-upgrade
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Calculating upgrade... Done

It then lists a bunch of installed and no longer used programs to remove, which I’ll do later with “apt autoremove”.

  xserver-xorg-video-fbdev xserver-xorg-video-nouveau xserver-xorg-video-radeon xserver-xorg-video-vesa xterm yelp zsh zsh-common
450 upgraded, 380 newly installed, 10 to remove and 1 not upgraded.
Need to get 712 MB of archives.
After this operation, 954 MB of additional disk space will be used.
Do you want to continue? [Y/n]

So another 712 MB of archives. Glad we checked that big free space now ;-) Total of almost 1 GB to be used. 450 packages to upgrade and 388 new, total of 830. I’d guess about another 1.5 hours to go…

After downloading the 830 packages, this step too asks you some questions, so check the screen from time to time. I chose UTF-8 for the consol and told it to guess the best character set.

It then goes on to all the unpacking and installing steps and again tells you to exit screensavers as it is upgrading them. You get to answer that you did that.

Toward the end, the background changed to the horrid Ox Blood / red that they have chosen for Beowulf. I’ll change that tomorrow as I described doing in an earlier posting comment.

Then it reaches completion:

etting up libreoffice-help-en-us (1:6.1.5-3+deb10u6) ...
Setting up chromium (88.0.4324.182-1~deb10u1) ...
Installing new version of config file /etc/chromium.d/default-flags ...
Installing new version of config file /etc/chromium.d/extensions ...
Setting up zsh (5.7.1-1) ...
Setting up gvfs:arm64 (1.38.1-5) ...
Setting up task-xfce-desktop (3.54+devuan4) ...
Setting up task-lxde-desktop (3.54+devuan4) ...
Processing triggers for dictionaries-common (1.28.1) ...
Processing triggers for initramfs-tools (0.133+deb10u1) ...
Processing triggers for ca-certificates (20200601~deb10u2) ...
Updating certificates in /etc/ssl/certs...
0 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...

Processing triggers for libvlc-bin:arm64 (3.0.12-0+deb10u1) ...
Error: Timeout was reached

real	99m1.164s
user	8m53.184s
sys	7m43.733s

About 100 minutes. Over 1.5 hours, but OK, still a pretty good guess.

When it completes, reboot and you are done.

But What If There Is No Build For My SBC?

This is where a FrankenSystem comes in. You install another operating system, like an Armbian Ubuntu or Debian, then replace all the “Userland” stuff with Devuan bits.

Again, the key steps are to preserve all the stuff from the base installation that matters (kernel, kernel modules, firmware, device tree bundle dtb, /boot stuff), assure the kernel is a compatible release level, and then swap in the userland from a Devuan of appropriate architecture. An aarch64 or armhf or even armel (32 bit v6 build for R.Pi Model 1)

Sidebar on Arch Types: The oldest arch you are likely to encounter is a v6 from the original Raspberry Pi Model 1. This is mostly a deprecated architecture and unless you have some specific need, can be ignored. Then ARM went to the 32 bit v7 armhf or hard-float build that knows how to use the hardware for floating point. You will see this one a lot. For the newer ARM chips with a 64 bit architecture, they can run both of those prior two instruction sets, but their native instruction set is aarch64 and that’s the most efficient (though it does take up more memory). So don’t be too surprised if you see an armhf “userland” running on an aarch64 system base.

In some cases you will find you just don’t have the needed parts to assure your FrankenSystem will work. There many not be a base system that works for the available Devuan userland, or there may be some other incompatibility. For example, while Debian at one time had a Debian userland running on a BSD kernel, they have abandoned that project as the difficulty exceeded the utility. Not all parts can be grafted together easily. That’s why I stay with Debian base and Devuan userland. So far they are strongly compatible.

For a FrankenSystem, the basic process is:

1) Install an Armbian, either Ubuntu or Debian depending on the boot loader type used and your preferences / what the Devuan system expects.
2) Copy off parts you will want to save for reuse, and make a backup copy of the whole thing for ‘restart’ if something goes wrong. The saved bits will be the /boot partition, the boot blocks at the start of the uSD card image (more on that later), the dtb (usually in /boot), the firmware and modules (in /usr IIRC) and the kernel (also in /boot).
3) Replace the userland with a Devuan userland (which means you have it on some other disk or SD partition somewhere to copy from…)
4) Adjust the boot command as needed.
5) Test it and fix what was screwed up.

I usually have done this via putting a Devuan in a 3rd partition on the uSD card and leaving the base system intact in the first partition (/boot) and 2nd partition (userland). That way it is just a question of adjusting the boot.cmd to point at the base or Franken partition to boot one or the other. Makes recovery from mistakes and omissions a bit easier and you end up with the ability to run both systems ;-)

An early example of my doing this is here:

That’s the general outline. I’ll add specifics and screen captures of gparted disk layouts and more as I do another of these and capture the specifics.

Realize that there are at least 2 major boot methods you may encounter and these will have differences in the exact boot.cmd or boot.ini and exactly how the boot process runs. I’ll try to document both or at least point at places for more information.

Oh, and each hardware maker has slightly different weird bits in how they boot up the hardware. Expect that and expect some things may be different.

I’ll build the FrankenSystem model in the next few days and update here. For now, it’s after midnight and I’m needing to sleep 8-)

Update Two:

I’m starting the Franken System Build, but I think I’ll put it in a separate posting as this one is already long.

For now, the first step is to pick a base system to use to underlay your overlay system. For this, you look at the kernel available and what dtb (device tree bundle) is needed / usable.

I’m going to do the Orange Pi One. A couple of reasons. First off, not much is avialable for it so it will be more of a challenge. Second, the ONLY official OS types are all SystemD (Ubuntu from the vendor, Debian and Ubuntu from Armbian). It is also something of an underused SBC (Single Board Computer) and as sales are not large, not a lot of folks have worked on polishing up OS versions for it.

This makes it both a good candidate for my use (as I need the non-SystemD product) and for the demonstration of the process (as it is likely to be about as hard as they come with little help out there.).

As a counter point, I’m posting this update using a “Community Build” Devuan 3.0 Beowulf image that I just downloaded with out much else needed on my part. Someone else already did all the work. There are some choices they made that I don’t like, so I did need to do some customizing, and I may still have a “Do Over” just to get one exactly like I want it; but the fact is that it exists and no such exists for the Orange Pi One.

First step is to look at the available resources.

A visit to the Armbian downloads page gives a choice of a big fat Ubuntu Focal release or a Debian Buster. Just below in very tiny type is a link to “other choices” that’s lets you see a bit more than the Right Now set:


Note the “Kernel” column. ALL of the supported set are on 5.10.y (where the minor digit y can vary day to day). You can get a Command Line Only Buster or a Desktop version (321 MB vs 577 MB) or a CLI Focal Ubuntu at 256 M. They are recent, just a few days ago build. There’s also a ‘test build’ on kernel 5.11.6 but we don’t need to go all experimental

Recommended download
Builds were tested for booting and basic operations.
Variant	EU	USA	Asia	Torrent	User space	Kernel	Integrity check	Size	Last modified
Buster					stable	5.10.y	SHA 	 ASC	321M	Mar 9 2021
Buster xfce desktop					stable	5.10.y	SHA 	 ASC	577M	Mar 9 2021
Focal					stable	5.10.y	SHA 	 ASC	256M	Mar 9 2021

Test builds
Builds were made automatically from the trunk with unknown support status. Use at your own risk!
Variant	Global	China	Torrent	User space	Kernel	Integrity check	Size	Last modified
Hirsute		n/a	n/a	unstable	5.11.6	SHA 	 ASC	260M	Mar 17 2021

Why does one need a particular kernel? 2 major reasons:

1) Some application was built against a Library that uses some particular recent facility. This is not that common in the basic programs of Linux as most of them were designed ages ago against a general stable library and interface. It can bite you if you get too far away from the build target, but that’s usually with major number changes.

2) The specific devices used in your hardware may get incorporated into the kernel over time. This is far more common. Some vendor comes out with a new whiz-BANG! SOC System On Chip or Ethernet or Video Core and the kernel has no idea how to “make it go”. A special purpose “device driver” is needed. For a long time this will come in a bundle of device drivers – the Device Tree Bundle. Over time, the more popular hardware gets “kernel support” meaning that the kernel developers decided there’s enough of that stuff sold to justify making the kernel bigger by incorporating the device drivers.

THE major effect of #1 on a FrankenSystem is that trying to put a new userland on an OLD kernel is increasingly likely to fail the older the kernel is with respect to the userland. It can range from “everything works” to “some application I never use is squirrelly” to “won’t even boot”. To mitigate this, try to keep the Userland as close in time to the Kernel / Modules / Libraries / Modules as possible.

THE major effect of $2 on a FrankenSystem is that you may end up with a bigger DTB than needed as some of it is the kernel now on your newer system, or you may find that DTB from the new system is just not complete enough to work on an older kernel. So to avoid this you try to match the DTB to the Kernel you are using and get both from “about the same time”.

This sounds a lot harder than it is. Often just using a recent kernel / dtb with “whatever” userland is fine. We’ll see if that is true for the O.Pi One…

In my packrat archives I’ve got:

root@RPro64:/WD3/ext/Linux_Depricated/Armbian# ls -l *Orange* 
-rw-r--r-- 1 ems  ems  336060972 Mar 20 22:43 Armbian_21.02.3_Orangepione_buster_current_5.10.21.img.xz
-rw-r--r-- 1 1616 1616 262138584 Feb 17  2019 Armbian_5.75_Orangepione_Debian_stretch_next_4.19.20.7z
-rw-r--r-- 1 1616 1616 205369698 Feb 17  2019 Armbian_5.75_Orangepione_Ubuntu_bionic_next_4.19.20.7z

A 5.10.21 kernel build and a 4.19.20 build. That ought to be enough choice to match close enough to Devuan Beowulf. On the RockPro64 we have a 5.6.10 and that ought to work OK with a userland build for 5.10.x:

root@RPro64:/WD3/ext/Linux_Depricated/Armbian# cat /boot/boot.cmd 
setenv macaddr da 19 c8 7a 6d f4

#setenv devtype mmc
#setenv devnum 1

#part uuid ${devtype} ${devnum}:1 idbloaderuuid
#part uuid ${devtype} ${devnum}:2 ubootuuid
#part uuid ${devtype} ${devnum}:3 noneuuid
#part uuid ${devtype} ${devnum}:4 bootuuid
#part uuid ${devtype} ${devnum}:5 rootfsuuid

setenv bootargs "earlyprintk debug=on earlycon=uart8250,mmio32,0xff1a0000  console=tty1 console=ttyS2,1500000n8 root=/dev/mmcblk1p5 rw rootfstype=ext4 fsck.repair=yes net.ifnames=0 video=eDP-1:1680x1050@60 video=HDMI-1:1680x1050@60 bootsplash.bootfile=dev1-arm16.png"
# ubootpart=${bootuuid}
setenv fdtfile rockchip/rk3399-rockpro64.dtb

if load ${devtype} ${devnum}:4 ${kernel_addr_r} vmlinuz; then
  if load ${devtype} ${devnum}:5 ${fdt_addr_r} usr/lib/linux-image-5.6.10/${fdtfile}; then
    fdt addr ${fdt_addr_r}
    fdt resize 65536
    fdt set /ethernet@fe300000 local-mac-address "[${macaddr}]"
    booti ${kernel_addr_r} - ${fdt_addr_r};

At the Orange Pi site, there choice is:


Ubuntu Image updated:2018-04-09

A 2 year old Ubuntu build…

Which, BTW, refuses to download from the Google Drive repository without enabling 3rd party cookies, and is a 5.3.5 kernel anyway so not that interesting.

For comparison, the image presently on my Orange Pi One from several years back is runn a 3.4.113 kernel, so anything will be a lot newer.

root@RPro64:/WD3/ext/Linux_Depricated/Armbian# ls /SD/ext/boot
System.map-3.4.113-sun8i  bin	   boot.bmp  boot.scr		   initrd.img-3.4.113-sun8i  script.bin.bak  uInitrd-3.4.113-sun8i  zImage
armbianEnv.txt		  bin.old  boot.cmd  config-3.4.113-sun8i  script.bin		     uInitrd	     vmlinuz-3.4.113-sun8i

But this answers one big question for me. Can I just “franken up” my present install? And that answer is “that would not be wise”. TWO major numbers back on the kernel? That’s a problem. (SunXi was terribly slow about moving to recent kernels for quite a long time…)

That means the first 2 Big Decisions are made:

1) Not going to use my present running system as a base and just uplift it.

2) A fresh install likely ought to be a 5.x.y kernel and as close to 5.6.y as I can reasonably get. (Or whatever number is on the kernel of the Devuan aarch64 Devuan I use as my userland donor system).

With that, I’m off to do a bit more download / archive stuff, and then continue with things once I’ve got some answers.

Note that Armbian has a lot more choices hiding under “archived versions” link on that page and also note that the boot loader is often different between Ubuntu and Debian, so you may like one more than the other or find it works easier to Franken up a working boot.


Index of /archive/orangepione/archive/
Armbian_19.11.3_Orangepione_bionic_current_5.3...> 19-Nov-2019 08:04           205101864
Armbian_19.11.3_Orangepione_buster_current_5.3...> 19-Nov-2019 08:06           287822681
Armbian_19.11.3_Orangepione_buster_current_5.3...> 19-Nov-2019 08:07           610764753
Armbian_19.11.3_Orangepione_stretch_current_5.3..> 19-Nov-2019 08:05           269050022
Armbian_19.11.6_Orangepione_bionic_current_5.4...> 05-Jan-2020 12:03           205652362
Armbian_19.11.6_Orangepione_buster_current_5.4...> 05-Jan-2020 12:04           291915354
Armbian_19.11.6_Orangepione_buster_current_5.4...> 05-Jan-2020 12:05           622691111
Armbian_19.11.6_Orangepione_stretch_current_5.4..> 05-Jan-2020 12:04           276293988
Armbian_20.02.1_Orangepione_bionic_current_5.4...> 17-Feb-2020 11:48           221652828
Armbian_20.02.1_Orangepione_buster_current_5.4...> 17-Feb-2020 11:50           298127307
Armbian_20.02.1_Orangepione_buster_current_5.4...> 17-Feb-2020 11:52           632810637
Armbian_20.02.1_Orangepione_stretch_current_5.4..> 17-Feb-2020 11:49           290908990
Armbian_20.05.1_Orangepione_bionic_current_5.4...> 30-May-2020 22:24           274355040
Armbian_20.05.1_Orangepione_bionic_current_5.4...> 30-May-2020 22:24                 833
Armbian_20.05.1_Orangepione_bionic_current_5.4...> 30-May-2020 22:24                 123
Armbian_20.05.1_Orangepione_bionic_current_5.4...> 30-May-2020 22:24               19556
Armbian_20.05.1_Orangepione_bullseye_current_5...> 30-May-2020 22:29           365490728
Armbian_20.05.1_Orangepione_bullseye_current_5...> 30-May-2020 22:29                 833
Armbian_20.05.1_Orangepione_bullseye_current_5...> 30-May-2020 22:29                 125
Armbian_20.05.1_Orangepione_bullseye_current_5...> 30-May-2020 22:29               19570
Armbian_20.05.1_Orangepione_buster_current_5.4...> 30-May-2020 22:28           361653460
Armbian_20.05.1_Orangepione_buster_current_5.4...> 30-May-2020 22:28                 833
Armbian_20.05.1_Orangepione_buster_current_5.4...> 30-May-2020 22:28                 123
Armbian_20.05.1_Orangepione_buster_current_5.4...> 30-May-2020 22:28               19556
Armbian_20.05.1_Orangepione_buster_current_5.4...> 30-May-2020 22:30           701711160
Armbian_20.05.1_Orangepione_buster_current_5.4...> 30-May-2020 22:30                 833
Armbian_20.05.1_Orangepione_buster_current_5.4...> 30-May-2020 22:30                 131
Armbian_20.05.1_Orangepione_buster_current_5.4...> 30-May-2020 22:30               19604
Armbian_20.05.1_Orangepione_focal_current_5.4.4..> 30-May-2020 22:30           293730188
Armbian_20.05.1_Orangepione_focal_current_5.4.4..> 30-May-2020 22:30                 833
Armbian_20.05.1_Orangepione_focal_current_5.4.4..> 30-May-2020 22:30                 122
Armbian_20.05.1_Orangepione_focal_current_5.4.4..> 30-May-2020 22:30               19549
Armbian_20.05.1_Orangepione_stretch_current_5.4..> 30-May-2020 22:25           334890024
Armbian_20.05.1_Orangepione_stretch_current_5.4..> 30-May-2020 22:25                 833
Armbian_20.05.1_Orangepione_stretch_current_5.4..> 30-May-2020 22:25                 124
Armbian_20.05.1_Orangepione_stretch_current_5.4..> 30-May-2020 22:25               19563
Armbian_20.05.2_Orangepione_bionic_current_5.4...> 08-Jun-2020 23:18           271145928
Armbian_20.05.2_Orangepione_bionic_current_5.4...> 08-Jun-2020 23:18                 833
Armbian_20.05.2_Orangepione_bionic_current_5.4...> 08-Jun-2020 23:18                 123
Armbian_20.05.2_Orangepione_bionic_current_5.4...> 27-Jul-2020 07:15               22163
Armbian_20.05.2_Orangepione_bionic_current_5.4...> 08-Jun-2020 23:18               19556
Armbian_20.05.2_Orangepione_bullseye_current_5...> 03-Jun-2020 13:45           379609208
Armbian_20.05.2_Orangepione_bullseye_current_5...> 03-Jun-2020 13:45                 833
Armbian_20.05.2_Orangepione_bullseye_current_5...> 03-Jun-2020 13:45                 125
Armbian_20.05.2_Orangepione_bullseye_current_5...> 27-Jul-2020 07:15               30453
Armbian_20.05.2_Orangepione_bullseye_current_5...> 03-Jun-2020 13:45               19570
Armbian_20.05.2_Orangepione_buster_current_5.4...> 08-Jun-2020 23:22           364457240
Armbian_20.05.2_Orangepione_buster_current_5.4...> 08-Jun-2020 23:22                 833
Armbian_20.05.2_Orangepione_buster_current_5.4...> 08-Jun-2020 23:22                 123
Armbian_20.05.2_Orangepione_buster_current_5.4...> 27-Jul-2020 07:15               29283
Armbian_20.05.2_Orangepione_buster_current_5.4...> 08-Jun-2020 23:22               19556
Armbian_20.05.2_Orangepione_buster_current_5.4...> 08-Jun-2020 23:24           712229672
Armbian_20.05.2_Orangepione_buster_current_5.4...> 08-Jun-2020 23:24                 833
Armbian_20.05.2_Orangepione_buster_current_5.4...> 08-Jun-2020 23:24                 131
Armbian_20.05.2_Orangepione_buster_current_5.4...> 27-Jul-2020 07:15               55843
Armbian_20.05.2_Orangepione_buster_current_5.4...> 08-Jun-2020 23:24               19604
Armbian_20.05.2_Orangepione_focal_current_5.4.4..> 03-Jun-2020 13:44           307989456
Armbian_20.05.2_Orangepione_focal_current_5.4.4..> 03-Jun-2020 13:44                 833
Armbian_20.05.2_Orangepione_focal_current_5.4.4..> 03-Jun-2020 13:44                 122
Armbian_20.05.2_Orangepione_focal_current_5.4.4..> 03-Jun-2020 13:44               19549
Armbian_20.05.2_Orangepione_stretch_current_5.4..> 08-Jun-2020 23:18           334661488
Armbian_20.05.2_Orangepione_stretch_current_5.4..> 08-Jun-2020 23:18                 833
Armbian_20.05.2_Orangepione_stretch_current_5.4..> 08-Jun-2020 23:18                 124
Armbian_20.05.2_Orangepione_stretch_current_5.4..> 27-Jul-2020 07:16               27008
Armbian_20.05.2_Orangepione_stretch_current_5.4..> 08-Jun-2020 23:18               19563
Armbian_20.05.4_Orangepione_focal_current_5.4.4..> 15-Jun-2020 08:23           306875972
Armbian_20.05.4_Orangepione_focal_current_5.4.4..> 15-Jun-2020 08:23                 833
Armbian_20.05.4_Orangepione_focal_current_5.4.4..> 15-Jun-2020 08:23                 122
Armbian_20.05.4_Orangepione_focal_current_5.4.4..> 27-Jul-2020 07:46               24878
Armbian_20.05.4_Orangepione_focal_current_5.4.4..> 15-Jun-2020 08:23               19549
Armbian_20.08.1_Orangepione_bionic_current_5.8...> 03-Sep-2020 05:18           285561908
Armbian_20.08.1_Orangepione_bionic_current_5.8...> 03-Sep-2020 05:18                 833
Armbian_20.08.1_Orangepione_bionic_current_5.8...> 03-Sep-2020 05:18                 122
Armbian_20.08.1_Orangepione_bionic_current_5.8...> 22-Nov-2020 23:22               23826
Armbian_20.08.1_Orangepione_bionic_current_5.8...> 22-Nov-2020 23:22                  33
Armbian_20.08.1_Orangepione_bionic_current_5.8...> 03-Sep-2020 05:18               19549
Armbian_20.08.1_Orangepione_bullseye_current_5...> 03-Sep-2020 05:19           374450824
Armbian_20.08.1_Orangepione_bullseye_current_5...> 03-Sep-2020 05:19                 833
Armbian_20.08.1_Orangepione_bullseye_current_5...> 03-Sep-2020 05:19                 124
Armbian_20.08.1_Orangepione_bullseye_current_5...> 22-Nov-2020 23:22               30625
Armbian_20.08.1_Orangepione_bullseye_current_5...> 22-Nov-2020 23:22                  33
Armbian_20.08.1_Orangepione_bullseye_current_5...> 03-Sep-2020 05:19               19563
Armbian_20.08.1_Orangepione_buster_current_5.8...> 03-Sep-2020 05:19           372876544
Armbian_20.08.1_Orangepione_buster_current_5.8...> 03-Sep-2020 05:19                 833
Armbian_20.08.1_Orangepione_buster_current_5.8...> 03-Sep-2020 05:19                 122
Armbian_20.08.1_Orangepione_buster_current_5.8...> 22-Nov-2020 23:22               30486
Armbian_20.08.1_Orangepione_buster_current_5.8...> 22-Nov-2020 23:22                  33
Armbian_20.08.1_Orangepione_buster_current_5.8...> 03-Sep-2020 05:19               19549
Armbian_20.08.1_Orangepione_buster_current_5.8...> 03-Sep-2020 05:20           719136408
Armbian_20.08.1_Orangepione_buster_current_5.8...> 03-Sep-2020 05:20                 833
Armbian_20.08.1_Orangepione_buster_current_5.8...> 03-Sep-2020 05:20                 130
Armbian_20.08.1_Orangepione_buster_current_5.8...> 22-Nov-2020 23:23               56979
Armbian_20.08.1_Orangepione_buster_current_5.8...> 22-Nov-2020 23:23                  33
Armbian_20.08.1_Orangepione_buster_current_5.8...> 03-Sep-2020 05:20               19597
Armbian_20.08.1_Orangepione_focal_current_5.8.5..> 03-Sep-2020 05:19           292314884

I note that it jumps from 5.4.y to 5.8.y and skips 5.6.y. So I’d likely look for a Devuan donor build with a 5.8 or 5.10.

Subscribe to feed


About E.M.Smith

A technical managerial sort interested in things from Stonehenge to computer science. My present "hot buttons' are the mythology of Climate Change and ancient metrology; but things change...
This entry was posted in Tech Bits. Bookmark the permalink.

14 Responses to Of FrankenSystems Builds & dist-upgrade Devuan Arm

  1. E.M.Smith says:

    The “hang” where I did a powerfail to recover was likely a combination of things due to launching the browser. I had something similar happen after the final reboot.

    It looks like since I was not pointing DNS at the PiHole and had not done a couple of other things, a heavy page weight of some advertising with dancing java craplettes of some sort of animated logo were downloading with the web page.

    This caused a lot of “cache writes” that interacted with all the other stuff reading / writing the uSD card and caused it to want to swap, which also went to the uSD card… thus what looked like a hang but was really a fairly aggressive I/O contention on the uSD card / swap.

    I’ve now:

    1) Yet Again killed off ipV6
    2) Yet Again pointed DNS to my caching server / pihole
    3) Yet Again had the PiHole quash ads for a box.
    4) Send web pages through my Proxy Server

    and generally gotten a responsive browser again.

    Were I using this R.Pi longer term as a desktop, I’d put /var and swap and my home directory on a Real USB Disk ™ as that seems to really help I/O issues on these systems. But as this one is just for play, and seems fine now with the above changes, I’ll likely not bother with most of that. I will likely put a disk with real swap partition on the USB hub I use for KB / Mouse as it’s just sitting right there ;-)

    Anyway, it’s now 2 AM and I’m NOW going to hit the sack… so don’t expect to hear from me too soon ;-)

    It’s really amazing to me how much just quashing rude ads, and having caching for web page objects (squid proxy) as well as local DNS with cache can speed up these little systems. Also quashing ipV6 so it stops trying to use it on a network where it is all shut off.

    With that, I’m done for the night…

  2. Taz says:

    Take a look at this: https://arstechnica.com/information-technology/2019/04/serious-flaws-leave-wpa3-vulnerable-to-hacks-that-steal-wi-fi-passwords/

    This is the fourth compromised IEEE standard. It’s time to take their standards authority away. The IEEE is too dangerous. Think about that WPA2 flaw found by a 21 yr old within his first five minutes of perusing the BORROWED $5000 standards documents. IEEE should be shunned.

    We’ve always kept wifi on an outside network, but continued to use it for non critical functions (both wired and wireless clients). After reading this – finally banned wifi entirely to it’s own network. Stacked routers…didn’t trust a VLAN.

    It’s goddamn pathetic none of us can trust Wifi even a little.

    No Wifi connection is ever attempted here unless it’s through a VPN. 99% of that traffic is for phones. Wifi is used less and less for anything else.

    I am disgusted beyond words.

  3. E.M.Smith says:


    I use WiFi for the TV Sets and any devices incapable of wired connection. I have stacked routers (telco spits out 2 WiFi, one ‘guest’ isolated from everything but internet) and then the Lab Router that’s only used for “my stuff”.

    One SIMPLE help? Turn the broadcast power down to the bare minimum to reach the end of the house. Anyone at the edge of property will need a specialized antenna…

    Won’t stop spooks, but will stop the 12 year old 2 houses away…

    BTW, ever since the PRISM Program was pushed out, it looks to me like there has been a hidden agenda to compromise key tech to make it “Crackable by TLAs”. I firmly believe many of these “Flaws” and “Bugs” are “By Design and at Government Request”.

    “The effect you see IS the goal”, not Occam’s Razor…


    I’ve done an update with the first step of doing a FrankenSystem. Deciding on donor kernel / dtb / modules / firmware system and Devuan Userland.

    I’ve also decided to put the rest in a new posting as by the time I’ve added all that detail this one would be painfully long. I’ll add a link here when it goes up.

    Next steps being to select my donor systems, copy off and save the parts, then do the stitch up and test it.

  4. E.M.Smith says:

    Just a footnote to myself:

    I was using the Odroid N2 to shuffle a lot of archived system images off to an 8 TB Seagate drive (because it has 4 USB 3.0 ports on it and is fast…) and once again was shown that zram swap failed to configure on boot. Being tired of that, I decided to try once again to “fix it” even though being an Armbian OS using SystemD, this one is in queue for a FrankenSystem build with Devuan…

    Turns out the “fix” is needed because they try to put both “memory logging” and zram swapping on zram0, and logging wins the race:

    /dev/zram0        516040   505556         0 100% /var/log

    So I got to go wandering through the bowels of SystemD / zram configuration (that is scattered all over hell and gone… in a typical Pottering style of confusion) …

    Basically all I did was change zram based swap from pointing at zram0 to zram1 (and ask that it be created).

    I’m going to try to remember all the places I touched but this may not be fully accurate as a lot of wandering in the desert was involved…

    Most of “the usual” was already configured, like

    root@OdroidN2:/etc/default# cat armbian-zram-config 
    # configuration values for the armbian-zram-config service
    # enable the armbian-zram-config service?
    # percentage of zram used as swap compared to physically available DRAM.
    # Huge overcommitment (300) is possible and sometimes desirable. See
    # https://forum.armbian.com/topic/5565-zram-vs-swap/?do=findComment&comment=61082
    # and don't forget to adjust $MEM_LIMIT_PERCENTAGE below too.
    # percentage of DRAM available to zram. If this amount is exceeded the zram
    # devices used for swap simply behave as if the device is full. You need to
    # adjust/increase this value only if you want to work with massive memory
    # overcommitment (ZRAM_PERCENTAGE exceeding 150 for example)
    # create how many zram devices max for swap
    # Which algorithm for zram based swapping. Seems lzo is best choice on ARM:
    # https://forum.armbian.com/topic/8161-swap-on-sbc/?do=findComment&comment=61668
    # Which algorithm to choose for zram based ramlog partition
    # Which algorithm to choose for zram based /tmp
    # If defined a separate partition will be used as zram backing device. Be CAREFUL
    # which partition you assign and read starting from CONFIG_ZRAM_WRITEBACK in
    # https://www.kernel.org/doc/Documentation/blockdev/zram.txt
    # ZRAM_BACKING_DEV=/dev/nvme0n2

    and places like https://docs.armbian.com/User-Guide_Fine-Tuning/ were unhelpful with their mininmal information:

    Swap for experts
    By default Armbian implements ZRAM (writing nothing to ‘disk’ but compressing memory pages in RAM) but in case you often run into out of memory errors and your device has some capable storage (e.g. a securely attached NVMe or SATA SSD) you might want to use ZSWAP instead.
    Check whether your kernel has zswap enabled (dmesg | grep zswap should output something) and if so create a swapfile or swap partition the traditional way, edit/uncomment /etc/default/armbian-zram-config so that it reads SWAP=false, reboot and you’re done.
    Zswap performs a lot better than the combination of ZRAM and ‘swap on disk’ in parallel.

    Gentoo guides had more of what was needed, but cover non-SystemD too:


    So first off, you get to molest the systemd “service” file. Here I changed the device name from /dev/zram0 to /dev/zram1

    root@OdroidN2:/etc/systemd/system# cat zram.service 
    Description=Swap with zram
    ExecStartPre=/sbin/mkswap /dev/zram1
    ExecStart=/sbin/swapon /dev/zram1
    ExecStop=/sbin/swapoff /dev/zram1

    Then, because zram is loaded as a module at boot time, I had to tell the kernel to make more:

    root@OdroidN2:/etc/modprobe.d# cat zram.conf 
    options zram num_devices=2

    So make 2 instead of just one.

    There’s another place where the kernel is told to load zram, but it is already configured:

    root@OdroidN2:/etc/modules-load.d# cat zram.conf 

    Then there was this odd place to add an entry for zram1:

    root@OdroidN2:/etc/udev/rules.d# cat 99-zram.rules 
    KERNEL=="zram0", ATTR{disksize}="512M",TAG+="systemd"
    KERNEL=="zram1", ATTR{disksize}="512M",TAG+="systemd"

    I just copied the entry for zram0 and changed it to zram1

    This page was helpful:


    I then rebooted. During the boot process I was told that zram swap failed in a mkswap step, yet I still ended up with swap going to zram1 so there is still some minor bit of fiddle that needs doing (or maybe on a reboot it will be fine as some step completed…) But at least I have swap hitting zram first.

    FWIW it looks like the basic error is fixed in some future release:


    ZRAM Enhancements – decouple swap config from tmp

    Documenting enhancement by Uglymotha

    Added 2 configuration parameters to armbian-zram-config.
    First paramter (SWAP=) can explicitely disable zram swap (while leaving log and tmp untouched).
    Second parameter (TMP_SIZE) can be used to explicitely set tmp ramdisk size.
    The behaviour of existing configurations is not changed.

    New function activate_zram() to initialize zram devices and parameters outside of swap functionality.
    Changed script to use zramctl to more flexibly establish zram devices to use for log and tmp.
    This also fixes issues which result from both armbian-zram-config and armbian-ramlog being hardcoded to use zram0
    Permission on /tmp also set correctly to 1777 instead of 777.

    The combination of ramlog and zram swap now functions as expected:
    /dev/zram2 lzo-rle 500M 432K 6.6K 96K 4 /tmp
    /dev/zram1 zstd 100M 8.4M 2.2M 2.6M 4 /var/log
    /dev/zram0 lzo-rle 375.3M 4K 73B 12K 4 [SWAP]

    Sidebar on kinds of swapping:

    As with most things most humans are fiddling with, instead of a constant focus on the KISS principle (Keep It SIMPLE Stupid), they multiply complexities and pile poo on poo until the whole stinking pile of it is impossible to untangle. (That is why we have a zillion “Romance” languages when Latin was better than most of them…)

    Swap is no different. At first, swap went to a dedicated bit of disk formatted to be most efficient for the computer. Simple, easy, clean. Looks like /dev/foo in listings.

    Somebody didn’t like doing that process, and liked the idea of being able to add swap on the fly using whatever disk free space was around, so created the idea of a “Swap FILE” on a regular file system. Looks like /var/SWAP in listings.

    Then along came Android on tiny devices without disks. Swapping to uSD cards and similar tends to wear them a lot and is terribly slow as it writes a 16 K block for any write (and often does a read / change bits / write if your chunk is only part of that 16 K block). What to do… So they added a compressed memory area for doing swap. That’s ZRAM and it looks like /dev/zram0 on listings.

    Like this:

    root@OdroidN2:/etc/udev/rules.d# swapon -s
    Filename				Type		Size	Used	Priority
    /var/SWAPFILE                          	file    	1023996	0	0
    /dev/sdb13                             	partition	2097148	0	2
    /dev/sdd2                              	partition	2096124	0	1
    /dev/zram1                             	partition	524284	0	5

    Here you can see all 3 kinds in use. A /var/SWAPFILE, 2 hard disks on USB, and a zram virtual disk in memory.

    But there’s a 4th kind. I don’t really understand why you would do one vs the other, but it is what it is. There’s zramswap. (There’s also a zcache but I’ve not ever run into it so ignore it ;-)


    As I understand it, zramswap has hot blocks in compressed memory and moves low usage blocks automagically to a real swap device. The Armbian devs have a pretty long discussion of using one vs the other and look to have not implemented zramswap but just swap using zram (yes, the naming is horrible… ) and spend some time talking about how zram is better than zramswap without making clear the distinction…

    They do, however, spend a lot of time saying that swap to a uSD card is “game over” (which has not been my experience most of the time). Swap to SD is SLOW, but is better than crashing from out of memory. So I tend to put it LAST on the list of priories (that, IMHO, are numbered backwards… You would think ‘priority 1’ would be first, but no. Bigger numbers are more priority, so 1 is behind / after / last compared to 2, 25, or 4096 and more…) In my listing, the uSD file /var/SWAPFILE is priority 0 so only used after the zram fills up, and then the 2 USB disks fill up. Basically for emergency use if those are missing at boot.

    Note that they are un-tidy in their use of language. Talking about zram vs swap when it ought to be “zram swap” vs “SD swap” vs “USB disk swap”.


    THE big advantage of zram based swap is that you don’t end up hitting extraordinarily slow SD cards (and wearing them to death) nor do you end up on a slow USB disk that needs a second to power up and start spinning. In my experience, USB disks are OK and especially useful in desktop situations where the browser is hanging on to a few dozen GB of crap for no good reason so just shuffling it off to swap is fine.

    So now I’m going to reboot and see if the problem at boot is still there (but can be ignored) or if it’s all gone after one boot…

    UPDATE after reboot:

    Well, it still fails in the boot process –

    root@OdroidN2:/# systemctl status zram.service
    * zram.service - Swap with zram
       Loaded: loaded (/etc/systemd/system/zram.service; enabled; vendor preset: ena
       Active: failed (Result: exit-code) since Mon 2021-03-22 18:40:38 UTC; 3min 37
      Process: 3613 ExecStartPre=/sbin/mkswap /dev/zram1 (code=exited, status=1/FAIL
    lines 1-4/4 (END)

    But still gives me working zram swap. I’m going to declare it good enough for now. I suspect that adding a mkswap option to

    root@OdroidN2:/etc/udev/rules.d# cat 99-zram.rules 
    KERNEL=="zram0", ATTR{disksize}="512M",TAG+="systemd"
    KERNEL=="zram1", ATTR{disksize}="512M",TAG+="systemd"

    Like this line from the gentoo link:

    KERNEL=="zram1", SUBSYSTEM=="block", DRIVER=="", ACTION=="add", ATTR{disksize}=="0", ATTR{disksize}="512M", RUN+="/sbin/mkswap $env{DEVNAME}"

    might fix it, so will try that “someday”…

    For now it works well enough for me to get back to what I really wanted to do today…

  5. E.M.Smith says:

    Well, got it working without errors (but probably via a bad hack…)

    root@OdroidN2:/# systemctl status zram.service
    * zram.service - Swap with zram
       Loaded: loaded (/etc/systemd/system/zram.service; enabled; vendor preset: ena
       Active: active (exited) since Mon 2021-03-22 22:39:55 UTC; 1min 54s ago

    How? Shut off two actions.

    root@OdroidN2:/etc/systemd/system# cat zram.service 
    Description=Swap with zram
    #ExecStartPre=/sbin/mkswap /dev/zram1
    #ExecStart=/sbin/swapon /dev/zram1
    ExecStop=/sbin/swapoff /dev/zram1

    This essentially (commenting out the mkswap and swapon lines) makes the SystemD zram.service hobbled so it can’t make a swap file and can’t start swap.

    At first I just removed the mkswap and that just moved the error to the START line. Commenting them both out “fixed” it in that you get no error messages at boot. Yet I still get a zram swap running. So my belief is that “somewhere” in the boot process is a longhand start of swap on the target zram1, and then some other SystemD thing tries to start it too, via zram.service, and finds out it is already running so craps out.

    What really ought to be done to fix this is “pick one” and use it, but leave the zram.service file set up to start / stop it. Except I have no idea in the boot process where that double dip happens or what file the instructions are in. (And, unlike the old school rc.d or sysv.init I can’t just “cd” to the directory and “grep for zram” to discover it as things are scattered all over now under SystemD.

    Oh Well.

    I don’t care enough to take this any further. It’s a hack and a kludge, but it does what I want and I’m sick of dealing with systemD crap for the day.

    In a few weeks it will become a Devuan system anyway… and for now I’ve got swap on zram where I want it as I’m shoveling lots of files around between disks (and don’t want disk head contention between what’s being moved and swap on the various disks…)

    Hopefully I’ll never need to deal with this again, but it’s documented enough here to get clue. If anyone does find where Armbian is trying to do a double dip on starting zram swap in Buster, please post that in a comment.

  6. Pinroot says:

    Well, that’s a lot to digest, especially for us sort of newbies (no matter how long I work with these systems, I’m still going to consider myself a n00b; always something new to learn).

    I’m still working with my RPi Zero “project”. I have an IRC server running and I’m able to connect to it from my laptop (using the following: ssh -NL 6667:localhost:6667, which basically exports my session from my RPi to my laptop). So the irc server is working, but I don’t know the b32 address to give to anyone so they can see if they can connect to it. The console gives me an address, but any time that I restart the router, the b32 address changes, so that confuses me because I don’t know what b32 address to hand out.

    I’ve kept the system up for over a week, and it’s done pretty well. I’m getting more transit tunnels than I expected, but not as many as I had hoped. I haven’t used any swap at all, and only about half of the 512M that the Zero comes with, and that’s with both i2pd and ngircd both running. I would like to see how multiple users stresses the irc server, as soon as i know how to share the address.

  7. E.M.Smith says:


    I think the i2pd instance ought not to have memory issues as it is written in a real computer language. The i2p version is in Java on a JVM so spaws a slew of JVM instances and seems to have a lousy idea of how to handle real memory…

    As soon as I have any spare time I’m going to try running i2pd somewhere.. but for now I’m on the whole “dump Armbian” and make FrankenSystems thing… which sent me off to gather in one spot all my various downloaded and configured system images of about 15 years duration scattered over a half dozen disks… Yeah, sorting a few dozen TB of archives takes a little time…

    But while not fully complete yet, is far enough along for me to choose the 2 OS copies to merge in my Orange Pi Frankensys without potentially downloading my 4th or 5th copy of the same one ;-)

    (So far, out of a few hundred system images, only about a half dozen have been exact duplicates. OTOH, dumping 20 GB of duplicates is likely a good thing ;-) Once I get into pruning dd copies of whole SD cards it will likely reach a TB range, maybe. Doesn’t take a lot of old backups of 32 GB and even a 64 GB SD cards to add up…)

    Recursive decent in projects… it’s a thing….

    FWIW I put all that systemD zram crap here because, having finally waded through it all, I know that 6 weeks from now I won’t remember it. I tend not to remember things I despise… so it’s here in case I need to do this again on some system… or if anyone else has the problem to provide some pointers so they can know where the landmines are. I’d suggest not digesting it unless you have an actual and immediate need.

    I’m hoping to get back to the i2p and Zeronet stuff in a day or two. Soon as the Orange Pi Frankensys is running. I want to get that done and a runbook written so then knocking out more Frankensys assemblies can go faster… and be done as “side work” while I’m doing other things on another system.

  8. E.M.Smith says:

    Just a brief status update.

    I decided to take on the Orange Pi One first as it has the least available OS choices and in some ways is the most orphan / least community support. Figured to the hardest first the rest will be a lot easier.

    Well, so far I’ve figure out a few dozen ways to NOT make a working system…

    So I’m going to hang it up for the Orange Pi One for a little while and try one of my more normal boards with more starting choices for base OS and such.

    I’ll likely take the ones that have an ASCII port of Devuan available and just do Beowulf upgrades on them to make a normal Devuan. Just to get past being frustrated for a while… Then move up to some non-Orange without an Ascii Devuan and try again.

    Looks like easy targets are the Raspberry Pi family, the Rock group, and then some of the Odroids. We’ll see. But I’m into this about a week on the Orange Pi One and have little to show for it. ( I did get a partial boot via mounting Devuan SunXi file systems onto an Armbian boot & root, but trying to replace /usr gave grief… Then U-Boot has been a pita on trying to boot into Devuan directly. (But I may try that again at some point…)

    For now I’m at the “Just step away from it for a while and come back fresh later” stage.

    There are “issues” in making a Franken System having to do with making sure all the parts play well together. Sometimes it all goes well immediately. Sometimes there’s some little bit that’s one release off and that part fails, blocking the boot. And sometimes you just forget to get it all stitched up and only notice when you come back after a week away and try to figure out what all you got done (and discover what didn’t…).

  9. E.M.Smith says:

    Just noticed that the Devuan / XU4 did not have a zram swap set up. Searching on “Devuan” zram swap turned up a LOT of DEBIAN but for actual Devuan only this page was at top of the list. So looks like “I’m it”… OK…

    I decided to just start whacking at it. First, no /etc/default/zram.conf file exists. SO does the package exist in the repositories? Yes, it does:

    root@XU4uDevuan3:/# apt-get install zram-tools
    Reading package lists... Done
    Building dependency tree       
    Reading state information... Done
    The following packages were automatically installed and are no longer required:
      clearlooks-phenix-darkpurpy-theme darkpurpy-icon-theme dh-python g++-6
      gcj-6-jre-lib gnome-icon-theme-extras gnome-mime-data gnome-user-docs
      gnome-user-guide libappindicator1 libart-2.0-2 libass5 libavdevice57
      libavfilter6 libavformat57 libavresample3 libbind9-140 libblas-common
    The following additional packages will be installed:
    The following NEW packages will be installed:
      bc zram-tools
    0 upgraded, 2 newly installed, 0 to remove and 1 not upgraded.
    Need to get 110 kB of archives.
    After this operation, 242 kB of additional disk space will be used.
    Do you want to continue? [Y/n] y
    Get:1 http://pkgmaster.devuan.org/merged beowulf/main armhf bc armhf 1.07.1-2+b1 [104 kB]
    Get:2 http://pkgmaster.devuan.org/merged beowulf/main armhf zram-tools all [5,528 B]
    Fetched 110 kB in 12s (9,154 B/s)
    Selecting previously unselected package bc.
    (Reading database ... 193570 files and directories currently installed.)
    Preparing to unpack .../bc_1.07.1-2+b1_armhf.deb ...
    Unpacking bc (1.07.1-2+b1) ...
    Selecting previously unselected package zram-tools.
    Preparing to unpack .../zram-tools_0.3.2.1-1_all.deb ...
    Unpacking zram-tools ( ...
    Setting up bc (1.07.1-2+b1) ...
    Processing triggers for menu (2.1.47+b1) ...
    Processing triggers for man-db (2.8.5-2) ...
    Setting up zram-tools ( ...

    I’m going to try the same configure steps used for Armbian (modulo working out how to bypass any SystemD-isms…) and see if I can “make it go”.

    To find out will require a reboot to test that it really all works from boot, and so any result will come in some future comment…

    I’m following the udev model from here:

    and have put this in /etc/modprobe.d/zram.conf:

    root@XU4uDevuan3:/etc/modprobe.d# cat zram.conf
    options zram num_devices=1

    and added a 10-zram.rules file to /etc/udev/rules.d:

    root@XU4uDevuan3:/etc/udev/rules.d# cat 10-zram.rules 
    KERNEL=="zram0", SUBSYSTEM=="block", DRIVER=="", ACTION=="add", ATTR{disksize}=="0", ATTR{disksize}="512M", RUN+="/sbin/mkswap $env{DEVNAME}"

    So now I get to try that reboot and see what else is missing. (i.e. see if /dev/zram0 exists post boot and if so can I get it mounted as swap using /etc/fstab or what?)

  10. E.M.Smith says:

    OK, that didn’t fully work, but after a manual modprobe to load the module I’ve got one:

    root@XU4uDevuan3:/# modprobe zram
    root@XU4uDevuan3:/# ls /dev/z*
    /dev/zero  /dev/zram0
    root@XU4uDevuan3:/# file -s /dev/zram0 
    /dev/zram0: Linux/i386 swap file (new style), version 1 (4K pages), size 131071 pages, no label, UUID=a075366c-b4bf-45fc-91d1-194dcb3b3b77

    So at least I can do it “long hand” for now. Just need to figure out how to make this happen in the boot process (or do yet another reboot to see if it is now persistent already…)

    Added an entry to /etc/fstab and it is now working:

    root@XU4uDevuan3:/# swapon -s
    Filename				Type		Size	Used	Priority
    /dev/mmcblk1p7                         	partition	2097148	0	64
    /dev/sda5                              	partition	1049596	0	1024
    root@XU4uDevuan3:/# vi /etc/fstab
    root@XU4uDevuan3:/# swapon -a
    root@XU4uDevuan3:/# swapon -s
    Filename				Type		Size	Used	Priority
    /dev/mmcblk1p7                         	partition	2097148	0	64
    /dev/sda5                              	partition	1049596	0	1024
    /dev/zram0                             	partition	524284	0	4096

    So I guess now the thing to do is yet another reboot and see if it survives or if I have more to do…

  11. E.M.Smith says:

    Well, it doesn’t persist over a reboot as the module does not load at boot. One Last Thing to work out. Getting the module to load at boot and then I’m done.

    I did a reboot and then:

    root@XU4uDevuan3:/# swapon -s
    Filename				Type		Size	Used	Priority
    /dev/mmcblk1p7                         	partition	2097148	0	64
    /dev/sda5                              	partition	1049596	0	1024
    root@XU4uDevuan3:/# swapon -a
    swapon: cannot open /dev/zram0: No such file or directory
    root@XU4uDevuan3:/# modprobe zram
    root@XU4uDevuan3:/# swapon -a
    root@XU4uDevuan3:/# swapon -s
    Filename				Type		Size	Used	Priority
    /dev/mmcblk1p7                         	partition	2097148	0	64
    /dev/sda5                              	partition	1049596	0	1024
    /dev/zram0                             	partition	524284	0	4096

    I’ll work on that last bit later… for now I can live with this. For now I’ve just added a little command named zram that does “modprobe zram; swapon -a” and I can run that just after I’ve booted up and launched a terminal window as root (which I almost always do…)

    It may be that Void Linux (also being free of SystemD) has decent advice on how to do this:
    https://wiki.voidlinux.org/Zram_- though it is runit based. I might just put it in rc.local…

  12. E.M.Smith says:

    Since it would be very quick to try, I tried stuffing this in rc.local.

    root@XU4uDevuan3:/# cat /etc/rc.local
    #!/bin/sh -e
    # rc.local
    # This script is executed at the end of each multiuser runlevel.
    # Make sure that the script will "exit 0" on success or any other
    # value on error.
    # In order to enable or disable this script just change the execution
    # bits.
    ## regen ssh keys on first boot
    [ -f /etc/ssh/ssh_host_rsa_key.pub ] || ssh-keygen -A
    modprobe zram
    swapon /dev/zram0
    exit 0

    It fails to start the zram swap, but it does succeed in getting the module loaded. So after the boot, it just takes a “swapon -a” and all is good.

    No idea why the swapon in rc.local is failing. I tried it as both “swapon -a” and as above.

    I doubt using a full path would matter as both modprobe and swapon are in the same directory…

    Whatever. Time budget for this is done for a while, AND I have a simple and easy way to make zram swap “go” any time I like. This system doesn’t swap much anyway and what it does is after I’m logged in, doing stuff, and typically have a root terminal session running. i.e. when I want zram swap (as opposed to just “any swap will do I don’t care as long as it doesn’t crash from 0 mem”) I can get it trivially.

    So “this time for sure”, I’m done fooling with this for a while.

  13. E.M.Smith says:

    Much of today was spent doing repeated “apt-get dist-upgrades” on my Compaq Evo (single core Pentium 4 at 2.4 GHz, 2 GB memory) and 2 x Raspberry Pi Model 2 boards. All of them had some Devuan installed,one was Ascii (2.0) but 2 were Jessie (1.0), so need a few steps. Update / upgrade. Change /etc/apt/sources.list to Ascii. update / upgrade, dist-upgrade to ascii. Reboot (so everything is actually running on the new upgrade) Update / Upgrade to catch anything that wouldn’t update until other stuff was running. Change /etc/apt/sources.list to Beowulf. update/ upgrade and dist-upgrade again to Beowulf (3.0)… reboot… update / upgrade…. So it took a while…

    But now they are all current newest Devuan.

    Oddly, I’m on the Evo right now, and it is slower than my faster SBCs. Single core so not a lot of parallel processing going on. Just Chromium running (12 tabs but most of them idle) and it’s go 776 K of swap in use. Though only 1 GB of active memory at the moment. In theory the swap is “left over” pointers at files from some process or other and the system doesn’t think it is worth the effort to flush it. ( I need to check the swappiness setting and likely set up zram swap on it…) Oh, and just one old disk so head seeks for swap or when going from /bin to /usr to /var…

    I get a little type ahead just like on the Raspberry Pi ;-)

    Strange experience, that. Nice box, giant compared to the SBCs. Intel Pentium. And slow.

    Maybe I’ll benchmark some bits and compare the SBCs to it. Find out just which Raspberry Pi it is these days… in terms of performance ;-)

    Tomorrow I’m going to do the Pi M3 boards. Not much to do there, really. Just a QA check on what I did before and archive anything not Beowulf. Clear some chip images. IF I have the opportunity I’ll also start the FrankenSystem build on the Odroid C1 and C2. Then do a “do over” of the Beowulf on the RockPro64. (It was a download of some other person’s build and some of their choices are not my favorite, so either find out how to change those things, or just do the build over).

    I’m going to leave the Orange Pi One boards for last. Too many issues on my first pass at them. Just before them I’ll do the Rock64 and Pine 64A+. Someday I’ll need to do the R. Pi model 1 that I’ve got, but not sure when. It will be dog slow to do. Single core, 700 Mhz. Small memory.

    The XU4 is already done so happy with it. Which will leave the Odroid N2. I’ve got some saved files and work areas I need to back up and some process function to check on other boards before I dive into a build for it.

    I counted them all up and I’ve got 14 SBCs plus a half dozen old PCs (from White Box Pentiums to laptops to “desk top” slabs not booted in a few years. I think maybe the PCs have reached EOL.

  14. E.M.Smith says:

    Well, I’m on one of the Pi M2 boards. Running a music video.

    My impression is that it is less jerky and definitely has smoother audio (no dropouts) and does a MUCH better job of “doing something else” like typing here while it plays in a window there… Multi-core and all that. so 4 x 900 MHz ARM v7 beats 1 x Pentium-4 2.4 GHz. Especially on anything real time where interrupting one core causes a hit to other processes.

    Didn’t expect the Pi M2 to be the point of “better”, but it is for browser / videos.

    Though, in fairness, I’m running FireFox here so the browser itself might be part of the issue. I’ll need to install chromium and try again some time.

    I also note in passing that the Evo / Pentium-4 got a message banner from Google saying no more Chromium updates for it as it was not too far out of date / old / uninteresting to them… So there’s that.

    I do find it odd that the whole industry and user base are happy with just throwing away computers that still work just fine. Oh Well… I’ll keep it running a few years past Chromium EOL and likely a few past end of support in OS images too.

    Oh, and the Pi M2 has 498 MB memory used out of 1 GB, so looks more memory economical as well. 101 M on swap that’s likely leftovers from when I was doing all the updates…

    Also, the overall impression of the experience is that it is faster than it used to be. I think in Beowulf they may have started working on efficiency and better use of hardware. It seems faster and snappier than Raspian on the Pi M3. (Raspian is all built on v6 codes IIRC so the same OS can run on all their boards, so doesn’t use the added hardware in v7 or v8 cores)

    This M2 is a very old one, so v7 only. I’ll need to compare the 64 bit v8 aarch64 performance on an M3 and if the added word length is making it doggy despite the added clock speed, maybe make a hybrid 64 bit kernel 32 bit armhf userland. I did that on my Daily Driver under Jessy IIRC and it was a little faster (but mostly just worked better as 64 bit programs were new then in ARM and they had not finished bug hunting…)

    Overall, I’m finding this M2 browser experience quite acceptable. As long as you run videos at lower res and not full screen ;-)

Comments are closed.