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.
https://www.addictivetips.com/ubuntu-linux-tips/upgrade-debian-linux-new-release/
Let’s walk through that release upgrade cycle with a Raspberry Pi running Devuan ASCII. First you get the image and install it.
https://files.devuan.org/devuan_ascii/embedded/
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: root:toor 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) INSTALLATION ------------ other useful documentation can be found here: * https://www.raspberrypi.org/documentation/installation/installing-images/mac.md 1. -- Download the image you want: ; curl -O https://files.devuan.org/devuan_ascii/embedded/devuan_ascii_2.0.0_armhf_sunxi.img.xz 2. -- 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 3. -- Verify: ; gpg --verify SHA256SUMS.asc && sha256sum -c SHA256SUMS 4. -- 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 5. -- 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:/# 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 (2.7.6.1-2) ... 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... done. done. 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 root@devuan:/#
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... done. done. Processing triggers for libvlc-bin:arm64 (3.0.12-0+deb10u1) ... Error: Timeout was reached real 99m1.164s user 8m53.184s sys 7m43.733s root@devuan:/#
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:
https://chiefio.wordpress.com/2018/06/17/my-magnificent-bastard-system/
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:
https://www.armbian.com/orange-pi-one/#kernels-archive-all
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};
fi;
fi
At the Orange Pi site, there choice is:
http://www.orangepi.org/downloadresources/
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.
https://armbian.systemonachip.net/archive/orangepione/archive/
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.
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…
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.
@Taz:
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…
Sidebar:
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.
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:
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
and places like https://docs.armbian.com/User-Guide_Fine-Tuning/ were unhelpful with their mininmal information:
Gentoo guides had more of what was needed, but cover non-SystemD too:
https://wiki.gentoo.org/wiki/Zram
So first off, you get to molest the systemd “service” file. Here I changed the device name from /dev/zram0 to /dev/zram1
Then, because zram is loaded as a module at boot time, I had to tell the kernel to make more:
So make 2 instead of just one.
There’s another place where the kernel is told to load zram, but it is already configured:
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:
https://www.techrepublic.com/article/how-to-enable-the-zram-module-for-faster-swapping-on-linux/
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:
https://armbian.atlassian.net/browse/AR-590
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:
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 ;-)
https://www.maketecheasier.com/zram-zcache-zswap/
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”.
https://forum.armbian.com/topic/5565-zram-vs-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 –
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…
Well, got it working without errors (but probably via a bad hack…)
How? Shut off two actions.
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.
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 192.168.1.25, 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.
@PinRoot:
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.
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…).
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:
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:
https://wiki.gentoo.org/wiki/Zram
and have put this in /etc/modprobe.d/zram.conf:
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?)
OK, that didn’t fully work, but after a manual modprobe to load the module I’ve got one:
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:
So I guess now the thing to do is yet another reboot and see if it survives or if I have more to do…
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:
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…
Since it would be very quick to try, I tried stuffing this in rc.local.
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.
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.
8-0
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 ;-)