A Tolchock Too Far For The Chook

Sometimes I wonder why I do it.

At other times I know, it is because I must.

Or, as I’ve been known to say: “Sometimes I wonder about myself, the rest of the time I’m sure…”

So most of the last few days has been spent banging my head against 3 boards x 4 operating systems. The 4 operating systems are: Armbian, Devuan, Odrobian, and Ubuntu (honorable mention of Debian as substrate to all that.) The 3 boards being the Odroid Family. The 64 bit C2, the marvelously complicated 8 core of two types XU4, and the C1 that arrived in the post today. (Yes. I failed miserably at not “going there” when I told myself several times I would just buy more R.Pi M3 boards…)

I have a perfectly workable solution in hand. Devuan on the R. Pi M3 boards. I could have bought about 4 or 5 of them for the money I put into the Odroid boards. I’d have had a homogeneous solution with one operating system, one instruction set built on one Arch type of armhf and working OK. A simple “proceed to building cluster and starting applications work” in hand.

But Noooo….

I was CURIOUS… I wanted to Optimize

OK, It’s done. I did it. I admit it. I like playing with new shiny things…

First off, the conclusions:

1) You can’t get there from here. You’ve got to go ’round the other way!

You can have nice fast running desktops out of these things, as long as you accept the OS choices others have made. IFF you INSIST on having it your own way, you will need to bake your own cake. BTW, the store is low on flour and salt.

So Armbian seems to work GREAT on all of them. It even let me put up a GUI of my choice quickly and in keeping with the simple directions. It’s fast, efficient, and works well. Yet in it’s heart beats the SystemD vampire waiting to such the ambition from the experienced Systems Admin as it changes how everthing is done and erases the utility of 30 years of experience…

Odrobian promisses much, but so far has been a Royal PITA to get running. Sometimes booting, to a black screen. (What? It’s the appliance image, of course you will attach jumpers to your terminal device…) or sometimes just not really clear why.

Armbian easily up-converts to Devuan. But on the XU4 seems to “have issues” with not bothering to use the A15 cores much, or maybe at all… Uses them great prior to the conversion…

Ubuntu generally runs fine in the “as built” images. Well, as fine as Ubuntu ever does. Using 2 or 4 times as much resources as anyone else, forcing you into Their Way Straight Jacket. Fat, obnoxious, but functional… kind of like a Jabba The Hut.. do what HE wants, and you live. Fight? Well….

So I’ve not yet tried all possible combinations. There’s more space to explore. (Including a ‘hybrid’ arm64 kernel with armhf user-land applications Debian upshifted to Devuan… like adding MORE complexity will solve the problem of too much complexity and mixed bits… /sarc; )

In the end, the stable comfortable place where I go to lick my wounds and do my posting and work on things in peace is the good old reliable R.Pi M3 with Devuan on it. Sigh. Like the guy who goes to the Vegas Hooker and finds out he’s nervous as hell and doesn’t like her perfume and What The Hell Is THAT?!? she’s doing… so goes back home for comfort.

Glitz is fine and all, but it isn’t very comfortable, and often doesn’t “Get ‘er done!” and costs too much for the return. Yet: “OOOooohhhh! The Shiny Thing!!!”

OK, Enough With The Bitching

So, fish, cut bait, or beer run?

The Good News is that I’m sure I can “re-purpose” any given board into something productive. There’s always a way to use old (or new and cranky) hardware. I’m OK with running straight Armbian with systemd on it for a variety of “never change much servers and not my desktop box”. I’m also pretty sure that over time these things will get ever more operating system choices on them. Odroid is just too good a hardware design not to go mainstream. They are fast, sturdy, and cheap. That they come with appropriately (BIG!) sized heat sinks says a lot about their engineering.

So really it just comes down to 2 things:

1) How long will the wait be for someone else to do it?

2) Will I “be somebody” and take on the bug stomping in Devuan on Armbian on Odroid?

For now at least, I’m drowning in other priorities, so I’m in the #1 column.
Maybe in a year I’ll be #2.

Which puts me in “adapting land”.

Which value do I compromise?

Accept SystemD, even though the design is Very Wrong Not The Unix Way?
(And a PITA for The Experience Admin)?

Accept that running the Only ArmDevuan (Armbian uplifted to Devuan) will “have issues” and just get on the bug reporting list and send ’em in (then after a 1/2 year or so realize I’m the only one who cares so sign up to fix them…)?

Just put “something that runs” on the Odroids and stick them off in very unchallenging roles as file servers or distcc nodes or “whatever”?

The basic point is that “funny architectures” take a long time to get robust and low bug count support. At this time, the arm64 64 bit architectures are still in that mode. The XU4 with mixed Big-Little 2 different CPU types in the same chip A7 and A15 is way cool, and way weird from a kernel writer perspective. So no real surprise they are not going great guns with 12 different fully debugged operating system choices.

But the Odroid C1 is a straight quad core A7 CPU machine that’s been out a while. I expected more from it… Then again, I’ve had it all of about 4 hours, so lots more exploring to do… But I put a straight Odrobian image into it, booted, and had nothing but Black Screen… (Likely whatever image I used expects me to run headless or be in a wired to the GPIO serial connectors… Just daft.) So maybe I’m crying in what’s left of my beer too soon. Time will tell.

For now, I’ve done the quick tests and have some quick results. Armbian works well, is very efficient, and has an easy install of a windowing system. I’m likely going to just bring it up on the various Odroid boards (much like the Orange Pi board) and find a use for them. When running the XU4 on it as a browser desktop it was quite nice, so might do that for my “Dirty Driver” box that gets reset from time to time (and where SystemD weirdness is irrelevant, really) Or maybe I’ll use the arm64 C2 for that as the v7 instruction set of the XU4 means it’s a compatible distcc platform…

Further exploration of the edges for Another Day… We’ve scattered choices to the wind and tried a lot of strange mixes; it’s time to throttle back and make some bits production. Set aside the more bizarre explorations. Pick Something Good Enough and put it to work.

What will that be? Likely I’ll just drop back to that LXDE Armbian that worked very well and make it the Dirty Driver browse anywhere choice. Fast enough that fat web pages don’t matter, and none of my stuff on it. Make a dedicated Financial Chip for use in the Pi M3 with financial sites. Set up one of the GigE Odroids as the File Server where the I/O speed matters. Pick one to hold aside as “Exploring how to get ALL that I want” playground…

So goes a day in the life of a Systems Programmer / Sys Admin type.

The best bit of the day was going outside during the eclipse and seeing hundreds of little crescent sun images cast by the pinhole cameras of tree leaves under trees all up and down the street ;-)

The ambient temperature dropped rather fast, especially considering we were only in a partial eclipse area. One wonders where the “warming back radiation” was ;-)

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 and tagged , , , , , , . Bookmark the permalink.

8 Responses to A Tolchock Too Far For The Chook

  1. p.g.sharrow says:

    Arm DeVon ;-) sounds catchy! One OS fits all needs, K.I.S.S.
    But 64 bit may be a bridge too far. Too much wasted resources. Too many bells and whistles getting in the way of doing real work.

    To get rid of SystemD will be worth the effort but it may require DIY to get it done right…pg

  2. E.M.Smith says:


    I’ve mellowed a bit since the posting (Bushmills, neat…) so less emotional about it all.

    OK, the Pi.M3 does the job. Just build with it and be done. But What?

    a) a distcc build cluster. Already have it done enough with 2 x Pi M2 and 1 x Pi M3. Add more if anything becomes a problem. Only issue now is the Headend Pi 3 is also my Daily Driver. Solution: use one Odroid, even with SystemD, as my Daily Driver workatation. Best candidates: Either C2 or XU4 running Armbian native, honorable mention the C1 as stable and higher usercount. Integrate the Build Builder into the work flow.

    b) A climate model station. This comes in three forms. The first isn’t really a model, but a temperature fabrication sppliance. GIStemp. Then the other two models. Anything will do for GIStemp (it ran on a Pentium class whitebox PC). The others can have their initial porting and run done anywhere too, so use whatever left over Odroids. “Someday” it may need a cluster of Pis or whatever, but that’s a year away… so buy whatever then, use what you have now.

    Path Forward:

    Stop screwing around and make a “Dirty Driver” chip for the Odroid C1 or C2. Most likely Armbian with LXDE or MATE desktop. (Sometime tomorrow…)

    Make a “Financial secure” transaction and browser chip for the PiM3 or Odroid C1.

    Clean up the “Headend” chip and prepare for distcc compiles of both GIStemp and OS Builds. (Today I already moved Linux SW images all to one disk. Tomorrow I sort the last temperature data sets to another. Build builder already done.) Separate Daily Driver use from Headend distcc chip.

    Whatever didn’t become the Dirty Driver or Headend, becomes the internal workstation Daily Driver C1 or C2 or XU4. Most likely Armbian LXDE, it is also the experimental OS Platform

    Anything not already in use becomes an infrastructure server doing whatever is needed. At present, the list us a NAS, IDS, and Debian source bulid mirror.

    So that’s what I’m doing tomorrow :’)

    The really good news is that the Odroids work really really well on the vendor Ubuntu or on Armbian. I can live with that for now. So my total board count is now 8. That’s enough to do a lot of what I want to get done.

    Anything else can catch up later.

    I may need to temporarily accept being a Devuan & Armbian mixed shop. It isn’t all that bad, really.

  3. p.g.sharrow says:

    Maybe I should pose a different question. Is the smith a creator of tools to be used by others or is the job the most important thing and it requires tool creation?

    I find inventing and tool creation more satisfying then actual completion of the job. The job is merely the justification for the creation and planning. The fun is over and the hard work begins with actually getting the paid job done. ;-(

    I work with my hands to create and build, for me, this computer is just another tool that I sort of understand well enough to follow your work, …………..barely…..
    The last 30 years, on my own, I’ve had to learn about the guts of the pc well enough to make it useful to me. So I can sympathize with hacking in the dark to make this “modern miracle?” actually do useful work. At least you know where to feel for the handles in the dark. 8-)

    As a visionary I proposed a future needed computer tool system and realized you had the ability and inclination to create it. Your investigations and write ups in your blog have been most valuable to me and I suspect many others as well. Your blog style and execution may well be as great a contribution, a tool, as this future computer system may be.

    It appears to me that the development of hardware available is way ahead of the usability of current software. You seem to have settled on a flavor that may be the needed foundation to work on. So cleaning up the knots in the required software might be the next needed point of attention. The interest in producing general purpose small board computers seems to be quite large. The software that runs on them seems to be wanting for the ease of general purpose use. Your idea of a “compact software tool kit” would seem to be the real need. The board is just a tool that can be replaced…pg.

  4. E.M.Smith says:

    I tend to build tools for a while, then build tings with the tools for a while. Swapping between them as one gets frustration ridden ;-) Sometimes the Manager in me just says “Stop playing with the tools and go get THIS done!”.

    So the Blog is an operational thing. No tool building.
    I’ve got a nice LVM based NAS file server, with operational site scapes for data archival.
    I’ve got a working distcc Stack. 12 cores, uniform OS, libraries, v7 chips, armhf instruction set. (All things that matter in OS compiles…)

    I’ve also got projects (barely) started to port and run various computer models. For now, they need configuration not computes, but eventually I’ll need a distributed compute farm. Hetergenious will likely work (i.e. different OS and chips). Basics are in place for that.

    I’ve found an OS I like most (Devuan) for most things. I’ve also found one that’s “Good Enough” for things I don’t interact with often (Armbian) and one that’s ideal for Router like things (Alpine). All that is done deciding. There’s some open ends on matching just what can be Devuan and what has to be left at Armbian due to bugs or other issues.

    Where there’s still some open tool building question is really on only 2 fronts.

    1) The Compute Stack. When the day comes that I need a LOT of computes, it would be nice to have a basic compute engine that had 2x to 10x the computes of a R.PiM3 for the same money. Like the XU4 or the C2. It is not clear at present if that’s going to work out… but as that Stack need never be externally connected, security issues are less of a concern and since once running it won’t change much, SystemD wierdness is less of a concern. So it might be a stack of PiM3 / Devuan, or it might be Odroid Armbian… This is a ways off, like a year+, before buying more “stuff” to make a big compute engine would matter.

    2) Daily Driver. There are 2 minor issues here. First off, the Pi M3 is ‘just fast enough’ but I’d love to have faster. IF it works out easily to get there with one of the Odroids, OK. (So far not looking all that great though). This one will change offten and will need to have all the security I can get in it. So not SystemD friendly… The second issue is I’m dividing it into 4 separate functions for security reasons. List below:

    a) Headend. At present I’m using the same image for my Daily Driver that is the Headend to the Climate Models and distcc Stack. I’d like that to not be external exposed, so need to move off that chip and restore it to more pristine.

    b) Newer (preferably faster, maybe) INTERNAL Daily Driver. Used for all things inside my office that only go outside for known secure places (like my blog or downloading system updates).

    c) Financial Only Chip – just a generic chip used once a month or so and only for financial transactions. Allways reset to starting point after each use. Just so I’ll never have any finaincial history visible on other images, nor any non-financial sites on this image.

    d) Dirty Driver. Basically a place where I can visit random web sites and if the thing gets infested it doesn’t matter. Run on an isolated netword from the rest, and reset to starting state every so often.

    Now c & d are about 2 hours of chip configuration and then an archive of them. But I need to decide “for what board” before I can do that. I’d hoped it would be the C1 for one of them, but it’s only for headless use… (see posting: https://chiefio.wordpress.com/2017/08/22/disappointing-odroid-c1/ ). So I need to settle on b before I can do them. Right now it’s a 3 way between the Pi M3, the C2, and the XU4. I’ll know in a day or two. (Outside chance the Orange Pi Armbian can be upshifted to Devuan and becomes a cheap desktop – but llikely only the Dirty Driver… it only has 512 MB memory …)

    Basically, I’ve screwed around trying to make a better desktop for enough already… What, a couple of weeks? Time to “pick one and move on”. (Default is just remix a new chip for the PiM3 and reset Headend back to pristine).

    At present, I’m quite comfortable with the Pi M3 / Devuan as a nice, secure, working and fast enough general purpose computer. That’s a done deal. The only question is “Can I get faster for the same money with the same comfort?”. The last week has so far said No.

    Oh Well.

    But now I need to get back to doing things instead of talking about them ;-) The sun is up, the day is nice, and I have some “outdoors jobs” to get done ;-)

  5. E.M.Smith says:


    I’ve got the arm64/armhf hybrid image of Odrobian running on the 64 bit C2.

    It took a LOOOooong time to install Xorg and LXDE, but went fairly flawlessly. Only issues were that the boot comes up with a very tiny font screen in the middle 2/3 of the screen… Had to change the boot.in file (/media/odroid/boot/boot.ini) video modes. It was “1080p 60Hz” default, that is likely fine for Real HDMI TV, dvi adapter not so much, so I changed it to have the DVI mode set down near the bottom and chose a 1400 x 900 direct setting

     setenv m "1440x900p60hz"
     setenv vout "dvi"

    and shut off the default:

    #setenv m "1080p60hz" # Progressive 60Hz

    and all was well.

    Launching FireFox was interesting. It doesn’t have the dictionary installed, so all 4 cores were running at 70% to 85% or so all the time. That ‘spin on no dictionary’ bug is still with us… So I went to:
    and installed a dictionary… Now I’m about 14% of one core with 5 windows open (two of them with lots of videos …)

    Memory is at 577 MB out of 1.7 GB (the rest of the 2 GB being video I presume).

    This is the armhf (32 bit) version of FireFox and it does NOT seem to be sucking up memory like mad the way the arm64 one did on the other C2 64 bit only build. This one is quite acceptable.

    For now, this will be my “Dirty Driver” box as I shake it out. With the ability to run both 64 bit and 32 bit programs, it has potential to be both 64 bit fast and 32 bit reliable as individual programs get ported to 64 bit, or not…

    Maybe in a week or three I’ll try a Devuan “uplift” on it and see what breaks… I don’t know if Devuan has a hybrid build, or which programs / libraries it would choose to overlay… so might be flawless, might brick. For now, I’m willing to run straight Debian / Hybrid on this one and see what happes.

  6. E.M.Smith says:

    Just a minor update:

    I’ve figured out that the fsck issues are related to using a 3.x kernel with disks that have been touched by a 4.x file write as the journal handling changed (and they didn’t change the name of the now incompatible file system to ext5 …) So to keep all my systems able to read each others disks, I’d need to either convert all my multiple TB of disk to ext3; OR, I can make sure I’m using a 4.x kernel everywhere.

    Odroid only has builds from 2016 or so and what I’ve found is 3.x kernels.

    Devuan 1.0 is out, but only has images for the Raspberry Pi (that work). I tried their xu image and it’s a no-go on the XU4, so I think they have an U3 board and just figured it would work on the 4, but no way to test so…

    Armbian has “default” 3.x kernel builds and “next” 4.x kernel builds. “next” usually implies a bit more instability, but OK, I’m “going there”. It usually isn’t too much of an issue unless you are doing things on the edges of where most people are interested.

    The Ordroid XU4 has ‘window drag jitter’ on both Armbian and Odroibian, so neither of them is doing video composting right (or maybe just not using the video cores). It is acceptable, so I’m just going to live with it until someone fixes it. Just like the USB 3.0 that only occasionally fails…

    So, what I’m going to do over time:

    The Pi M3 is running a Raspian uplifted to Devuan. I’m going to do a new install of a straight downloaded Devuan 1.0 and upon acceptance, move all my “stuff” onto it. Slowly over time other “chips” with other use cases (different builds on the chip) will get the same replacement cycle. Then I’ll put the same brand new Devuan 1.0 on the Pi M2 boards. (The B+ stays an Alpine as that’s router oriented security paranoid build…)

    The Odroids will get Armbian installs of the “next” image so that the fsck incompatibility between systems I have will go away and I can return to “any disk any where” plug and play. Those Armbian images will be “uplifted” to Devuan (as that has been shown to work already).

    At that point, everything ought to be Devuan and a 4.x kernel, and armhf instruction sets. (The C2 may be made a hybrid arm64 / armhf IFF it is shown to work ok).

    There is one complication in that the Armbian builds will likely have different library release levels than the Devuan Pi images, so can’t be a direct simple distcc cluster together. That isn’t important right now (the Pi cluster is ‘enough’ at the moment) and when I need more I can either buy more Pi boards, or install the multiarch build systems bits, or maybe by then they will sync up on release levels for libraries (hah!).

    But at least I’ll be down to ONE running system (Devuan) and one era of kernel (4.x) and mostly one arch armhf.

    Sometime after that I’m going “pruning” in the chip farm to toss out all those images I will NEVER EVER run again ;-)

  7. catweazle666 says:

    “Sometime after that I’m going “pruning” in the chip farm to toss out all those images I will NEVER EVER run again 😉”

    NEVER EVER, eh?

    Sod’s Law will get you!

    Depend on it!

  8. E.M.Smith says:


    Well, there are a bunch. In particular, we had a critical fault in an earlier set of releases that makes them hackable ( IIRC it was a kernel fault…) so those are not secure and I’m just not going to run them, having newer releases with that patched. There’s also a few Ubuntu releases. I like LXDE much more, so “not going there” with old Ubuntu and don’t have any archived stuff that uses it as a dependency. Similarly, the Debian, Fedora & Ubuntu releases that run SystemD. As I’ve got Devuan, they no longer interest me.

    I might keep one each of the last non-systemd Pi Fedora and Pi Raspbian, but I’m not seeing the use case ATM. I’ll likely also keep some “Puppy” images just because I like it ;-)

    But really, I have about 35 chip images and many of them are ‘multiboot’ with 3 to 6 OS images on each chip (like the Berryboot images with all available OS types installed). Not seeing the reason to keep a 64MB SD card image of something I’m not using and not going to use… Many of these were during the early ‘teething’ phase of figuring out what I want / like. I know the answer now ;-)

    So mounting selected ones, sucking out an archive copy of the file systems (i.e. not a bit copy of the whole 64 GB chip to just have 3 GB system image saved…) and then letting the chips go free is quite reasonable. For others, just seeing they are something I’ll never want or need is enough. Like the desktop OS on the Pi B+ chip. I quit using it years ago. I’ll never use that system as my desktop again as it’s dedicated to DNS (or will go to the junk pile if it fails…). I’ve got a half dozen better desktop choices now. Or the Arch images. I’ve decided I have no interest in Arch now that they have gone to SystemD.

    I have packratted a lot of junk over the years…

    Between the older non-systemd being on a hackable kernel and the newer ones going systemd, there’s A Lot of stuff I’m just not going to run since I now have a better newer secure kernel and non systemd choices.

    (Do note: These are system images. My data lives on different disks / chips. We are not talking data backups here.)

Comments are closed.