As you may remember, I’ve been running Devuan on my Odroid XU4 SBC for a while now. I’m running their first, Jessie, release to make this posting. Their second release, Ascii, I could not get to boot. (Several postings on that while I tried). Eventually I decided to just back level to Jessie and wait for them to fix it in a new release. There is a minor issue with the cursor not displaying in LXDE on first boot (until you launch some app… so I’ve gotten good at finding the menu in the lower right corner, clicking when it highlights, and launching htop.. then the cursor shows up.)
Well, the new release, Beowulf, is out. An unfortunate choice of a name as a Beowulf is the technical term for a computer cluster using a particular build style (and one I’ve made before) so now you must disambiguate “Are you talking about the CLUSTER software or the RELEASE level that’s not a cluster?”. Sigh. Think ahead folks, please… don’t overload technical terms with multiple orthogonal meanings.
Looking forward to this release and the fixes it might contain, I’ve waited patiently for over a year. Now it’s here. And they have just dropped the Odroid XU4 from the list of supported boards. As this board is one of THE best I’ve found for performance per $Buck, that’s sucks.
Now, first off, when you go to the Devuan Download site, you don’t see any ARM boards at all. Just AMD / Intel arch.
http://files.devuan.org/devuan_beowulf/
Devuan Release Archive ../ desktop-live/ 31-May-2020 23:57 - installer-iso/ 01-Jun-2020 02:18 - minimal-live/ 31-May-2020 23:59 - README.txt 13-Mar-2020 11:20 1308 Release_notes.txt 13-Jun-2020 14:06 13K
You get to hunt around to find where they’ve hidden the ARM board images.
ARM Support
Bootable ARM images are provided by the Devuan ARM community.
You will find these resources useful for ARM-related discussion and development:
ARM Builds discussion on the Dev1galaxy forum
ARM image repository
#devuan-arm (Freenode)
Nothing like making all your ARM board user community feel second class quite like hiding their download area off somewhere else…
When you do get there, you find the README
MEDIA DEVICE IMAGES
-------------------
Media supported images:
* RaspberryPi{1,2,3,zero,zerow,cm1,cm3}
* OrangePi One Plus
* Olinuxino Lime 2
* Radaxa RockPi4{A,B}
* Pine64 RockPro64
* Kobol Helios4(Not yet availlable)
* Others
Current Media supported Allwinner boards:
* [armhf] Olimex OLinuXino Lime2 (A20)
* [arm64] OrangePi One Plus (H6)
Current Media supported Broadcom boards:
* [armel] RaspberryPi{1,2,3,zero,zerow,cm1,cm3} (BCM2835,BCM2836,BCM2837)
Current Media supported RockChip boards:
* [arm64] Radaxa RockPi4{A,B} (RK3399)
* [arm64] Pine64 RockPro64 (RK3399)
Of all the SBCs I have, only 2 made the cut this time. RockPro64 and Raspberry Pi. Sigh. Orange Pi One Plus makes it (H6 chip) but Orange Pi One does not (H3 chip). No Rock64 or Pine64 original Pine64 board. No Odroid N2. No Odroid XU4 etc.
OK, guess I’m either going to be stuck with “Roll my own” from sources (a royal pita) or just abandon Devuan on most of my hardware.
Oh Well.
Musings from the Chiefio 
Finally checked back in about the Android TV boxes to see if my “super-duper” one is supported and… yay! it is.
Meccol KM9.
S905x2
Cortex A-53 (so full 64 bit)
Quad core @1.8GHZ
3GB Ram
1 x USB2 + 1 x USB3
Running Armbian Ubuntu 18.04 on 64G SD card.
So, OK, it’s “infected” with systemd, but the repos all seem to work fine etc. All build tools available etc. Good enough for now, maybe try a custom SysV init system at some point. Seems stable so far though – using it to post this :-)
sbc-bench results here: http://ix.io/2uRZ
Even all 4 cores >80%, cpu temp didn’t go above 50C. (has 2mm aluminium sheet about 3″x3″ inside the case, no forced air cooling)
Quite snappy desktop, very usable. Boots to desktop in A$100, this box is A$75 (inc freight), with case, power supply, IR remote & HDMI cable.
Running this was easy install – download image, burn to SD, edit one file to suit this hardware and go. Pull the SD card, it’s back to factory Android TV box. Can flash the internal eMMC as well, but I haven’t done that yet – gotta get a backup of existing flash first, just in case.
Oops! Used a < raw.
“Boots to desktop in A$100, this box is A$75”
Should be:
Boots to desktop in < 90 seconds. Where I am, this is MUCH cheaper than a Pi – the Pi is >A$100, this box
What an interesting little box. Complete with case and everything….
https://www.priceboon.com/product/mecool-km9/
Well, interesting…
It won’t boot off a USB stick plugged into the USB3 port, but will with same stick in USB 2 port.
Ran the “upgrade” script in the distro from Android, which re-flashes the bootloader, and now it will boot on the USB3 port – I just don’t have a spare USB3 HDD or stick to try (USB2 stick ran fine, but slower than SD card)
Oh well, I could do with another 1TB of “mobile” storage anyway, and only A$70 for a USB3 Toshiba 1TB at the local OfficeWorks, which is only $5 more than a 100MBps 64G USB stick anyway, so no point buying 64G flash when 1T of rotating is so cheap. Or for half that, same from China, but big wait (7weeks +). Probably made there anyway, but screw it – as Homer J said “But I want it now…” :-)
Is Armbian an option?
https://www.armbian.com/download/
@EMSmith; yes, getting orphaned sucks, specially if you find something that works well for you. Avoiding being in the herd does have it’s drawbacks. The Raspi formfactor has the largest community and is least likely to be abandoned by developers, but will most likely be always a bit behind in performance. I still think Devuan might be worth the effort if R&D is the object. Running this blog can be done with almost any “box” system…pg
@Anon Moose:
Armbian works, and I use it when Devuan does not work.
Unfortunately, they have gone with SystemD. An abomination I am trying to avoid (bringing the design philosophy of Micro$oft, and all the complexity, unmaintainability, buggyness, insecurity and mysterious failure modes such fat intrusive octopus design entails).
The good news is that, so far, Armbian has kept the intrusive abuse of SystemD to a minimum by fixing the worst bad behaviours. Unfortunately, as SystemD sticks its snout into ever more of what ought to be independent program modules, that task will become ever harder and eventually will fail. I hope Devuan is more widely supported by then.
In fact, the Jessie release I’m running on my XU4 is via the very first “uplift” process that converted a SystemD afflicted Debian based Jessie to Devuan System free. I used Armbian Jessie for that base.
In later releases this conversion process does not work as SystemD has infested more of the operating system so full on releases with modified code is required.
At present, I run Armbian (unmodified) on 2 Orange Pi One boards, an Odroid N2 and, as an uplift to Devuan Jessie on the Odroid XU4. IMHO, it is the best of the lot of SystemD hobbled Linux releases for systems where Devuan is not available. (It fixed some bugs that bit me on Ubuntu, like having file system mount changes via /etc/fstab sporadically fail; some causing boot failures that looked like hardware and were difficult to recover.).
They also seem to have cured most boot time order indeterminancy failures (boot steps are inherently order dependant with dependencies on prior booted services. SystemD fires off everything at once and hopes. Yes, you CAN fix it by specifying ordering rule overrides, but providing a kludge path to a broken approach just ensures repeated new bugs as things change).
Devuan on my Intel based box and Raspberry Pi boards works great and I’m quite pleased. My only complaint is their lack of support for the boards I like best. Especially the Odroids. And that having issued an XU4 release that didn’t boot, they didn’t fix it. Oh Well.
SystemD has fractured the Linux ecology and it will take a few more years to heal. IMHO, that was part of the design goal. Drive more support work to Red Hat and hobble smaller releases, shrink the competition. It looks to me like Red Hat has moved to evil monopolist practices.
I don’t like being back leveled, but I can live with that on some systems. I don’t like running systemD, but can live with it on minor service boxes that don’t change much (like my NFS Server Orange Pi One), especially if Armbian.
So it goes…
If I ever get motivated enough, I’ll just use real Unix. They have now got releases with a decent GUI install out of the box.
I’ve stuck with Linux Mint due to the fact the wife is used to it. Since version 19 it has been very prone to freezing. Just upgraded to 20, but have still had a couple of freezes. It won’t run nVidia driver. They did admit they had fixed a slew of memory leaks that 19 had. Still … PITA.
I need to find an image of Trump at a PC with a grin on his face. Add a caption — FIXED IT! SYSTEM-D NOW WORKS BIGLY! Publish to Twitter.
Which would inspire the entire media complex to find out what System-D actually is and does and fails..
@Jim2:
Linux Mint is based on Debian, so I’ll bet your “issues” started when systemD was inserted…
@Pouncer:
No! Have Trump come out praising SystemD! It will be gone in the next release!!
8-)
jim2 replied 24 August 2020 at 5:29 pm GMT:
I’ve stuck with Linux Mint […]. Since version 19 it has been very prone to freezing. Just upgraded to ⟨version⟩ 20, but have still had a couple of freezes. It won’t run nVidia driver. They did admit they had fixed a slew of memory leaks that 19 had. Still …
Could be worse: It could also be suffering from buffer overruns. Or is it?
Sooo, maybe I should scuttle my casual plans to replace Win.-7 (or dual boot) a 4-GB RAM PC with the convenient tipped-in DVD that I was so pleased to get for installing Mint version 19.2?
There are oodles of Linux distros. I might be looking at them later …
CG – the problem may be solely related to the nVidia chip set. That seems to be the most problematic part.
@Jim2:
Lots of distros, but mostly from just a few root distributions, most of which have gone with systemD. Redhat started it, and as they are “upstream” for much maintenancd work, the lazy / easy thing to do was just go along. Debian, as the next gorilla, did just that. Between them, they drug along most of the active distros & spins.
Embiggen greatly:
More on Meccol KM9:
I flashed the internal eMMC using the standard script that comes in root’s home directory.
Worked flawlessly (I was ready for it to fail, but it worked!)
Cut about 25% off bootup time and similar amount for load/run program, so worthwhile.
As a daily driver, I reckon this is easily acceptable – refining previous, I estimate I have a desktop about 30-45 seconds after power up from cold.
One plus of this box, is that the IR remote will turn it on, so no fiddly power-cycles or other junk – just grab the remote and hit the power button and up she comes. Although, I’ll probably want to modify it (maybe hardware, not sure) to keep the front LED off when it’s “off” – ATM, it’s blue when turned on and red when turned off.
Got it to run MythTV (I had to compile from sources to get the version I need) but alas, it’ll only run at 720×576 without dropping frames. I can live with that. I think it is doing a lot of stuff in software that the box actually has hardware for, but at this point, I couldn’t be bothered diving into the code to “fix” it – to me, standard def is fine on a 32″ TV, and it will run full frame rate even down-sampling from 1920×1080 so I’m good.
Next job: set up lirc to suit.
Sounds nice!
Just a note that I’ve found the archived Devuan stuff, made a local disk copy of the archive, and adjusted my /etc/apt/sources.list file to point to it. Now I can add more packages, should I desire.
Details posted in a comment here:
https://chiefio.wordpress.com/2020/09/16/gentoo-on-odroid-xu4/#comment-133186