The First Few Days Of Slack (ware)

I’ve installed Slackware on the Rock64 and been running it for the last few days. This is my “first impressions” and initial evaluation.

First off, it does “just work”. That’s a good thing. It is free of the pestilence of SystemD. It had been a bug in the way SystemD on Ubuntu interacts with /etc/fstab that had me believe the Rock64 had ‘suddenly died’ when it had not. A disk mount entry ending in “noauto 0 0” ought to cause a missing disk to be ignored, it ought not to cause your boot to fail with a black screen and no hint of why… So I just did the install and booted up Slackware and everything just worked.

I got the image here:

Now the first thing to notice is that this is NOT an “official image”. That’s the first “ding” on Slackware. They are entirely Intel / PC focused. All the ARM chip stuff is strictly “community effort”. Among other things, this means that every different board I have is a new “Go Fish!” to find where that Slackware image is located, or if it exists at all. Not all that hard if you have decent Search Foo, but still a minor PITA. This also shows up in that pretty much all the official documentation is not helpful for anything related to ARM booting. Since boot loaders vary by board maker, that’s a bit of an issue. (Odroid, for example, has some magic sauce in the first few blocks and you must have a “signed by them” object to boot – so folks have developed ways to work around that, but it isn’t pretty…)

At that link is a fairly long list of software choices for the Rock64, most of them with SystemD crapping up the experience. I’ve tried to live with it. I have SystemD based systems running on about 1/3 to 1/2 of my stuff (mostly systems I don’t interact with much). It has been nothing but a PITA and buggy. But I DID try. Now I’m “moving on”. The “final straw” being a simultaneous discovery that 3 “dead boards” were in fact Fine Hardware and all had “died” in that the boot failed with black screen (even from backups) due to that bug in reading fstab; when at the same time I ran into their stupid ass-backward “fix” of the problem their async boot process caused with device names. So all my network setup failed for “eth0” as they renamed it to some incomprehensible string of digits based on MAC address or some such. It is clear they are NOT done screwing things up, so I’m done trying to tolerate the stupidity.

Looking down that list, it is largely a choice of Slackware or NetBSD. Not on the list is Gentoo. Gentoo runs on most of the ARM boards, but is rarely listed on a download list. Why? Because it is typically seen as a “roll your own” kit of parts. The way Gentoo works is that you put on it a “stage 3 tarball” that works OK to get started, configure all the build environment and such, and then download and recompile ALL the system from source code.

You are, in effect, a Developer Of One. Documentation is very good but the process has a Byzantine level of complexity and cryptic incantations that drive away most people. (I’ve installed it before, so not quite enough to drive me away ;-) It’s mostly just standard systems programmer stuff, but way removed from “just folks”. Also not on the list is LFS Linux From Scratch. That IS just a kit of parts. You download and build a DIY Linux from the original package sources. It was intended as a learning tool and the material of a DIY Book on Linux, but it can run (I installed it on a R.Pi Model 2 a while back). So there are really 4 choices. Of them, only Slackware is not “User Hostile” on the install side. (While I love the BSDs for their purity, they have an effete snob attitude about noobies and hand holding and generally take a “you deal with it” approach to “customer support”).

There may also be a “Puppy Linux” for the board. It is also non-SystemD (last I looked) but I did not go looking for it. It’s a nice Distribution, but the “everything named for dogs” theme wears on me. I’m not that in-to kitsch… I’ll “go there” if necessary, and it generally does work, but I’m not a ‘hand holdy memu for maintenance” kind of guy either. But for folks who do want more cutesy and less admin work, it can be a very usable option; if it exists for the board. They have their own semi-automated port making codes, so it can be easy to make a new “puppy”; I’m just not that interested in it…

So, in essence, it’s a choice of hostilities to overcome.

In a way this is predictable. Those Linux Distributions that focus on lots of hand holding and lots of hidden automation and lots of “let somebody else fix it for me” are just the ones where the impact of SystemD has been more hidden (until it bites you…) and where “someone else” has had to integrate it into the overall structure, debug things, and package it all up hidden from the user as best they could. Those Distributions where folks had it in their face and in their teeth are the ones that said “No Thanks, er Hell No!”. A kind of Darwin’s Choice that leaves the non-SystemD Distributions more heavily weighted to the Tech Savvy but Noob hostile sort.

Devuan is the exception, but the developers have a large workload in dealing with rooting out SystemD from Debian as the cancer is spreading into every corner. As a consequence, their supported platforms are few at present. I hope that someday they will have the staff to cover all my systems, but until then, they are “PC & Raspberry Pi” only with “some assembly required” to port to other boards. Then, being a “hand holdy” release, most of the users of Debian / Devuan are NOT the systems programmer types that are likely to “port it themselves”. So “folks like me” end up looking at the systems that are more of a “port it yourself” by culture and structure, who have avoided SystemD. That’s the BSDs, Gentoo, and Slackware.

Slackware is also a bit of a unique cultural thing in that it is the OLDEST distribution still supported and it has the least interest in rushing to embrace “new stuff”. It’s your Grandpa’s Linux in some ways. For example, they still use the BSD / Version 7 style of init ( rc.d files) and never embraced that new fangled System V Init (sysv init) from the 1990s… The login panel has a ‘ncurses’ look to it (those blocky squarish things in crayola solid colors with text boxes from the first years of graphics admin). If it ain’t broke, why fix it? I’m OK with that. It is in large part why I’m looking at it, in that they are not seeing any benefit in SystemD either. To some extent, I was never all that fond of sysv init anyway ;-)

So you have this Old School slightly crufty surly curmudgeon release that is made by “the Community”. It comes in a “miniroot” version for folks bringing up small servers, and a desktop version. I chose the desktop. While I prefer LXDE (now becoming LXQT as they change to QT backend) I’ve come to accept that most of the light weight distributions are going with the XFCE desktop. It’s close enough to be livable, especially as a first install / trial.

Pine is nice enough to give us two download locations, one in the USA and one in the UK. While I’ve included them in the quoted text below, they are release specific URLs so eventually will be out of date or just not work. The present links are dated 20190623, so might only work for a few months before an updated version replaces them. Kudos to Pine for actively expanding the operating system choices on their hardware. Some hardware vendors make one port of “something” and leave the rest for “the community” that’s too small to do much…

Note the key thing in the first line: “Community Build Image”. That means it is up to you and a few of your newest friends to make the OS and fix the bugs. The good thing is that the Slackware community tends to be good at that. The bad thing is that there isn’t exactly one place to go look for downloads and help. You get to run into a lot of Slackware On PC support while trying to find where somebody, anybody, is doing the SlackArm stuff. For a while, SlackArm was even officially discontinued. Then ARM chips started to take over the world and it was revived a few years back. Maybe someday it will become an officially supported thing…

Slackware Aarch64 XFCE Community Build Image [microSD Boot] [20190623]

System with a graphical shell
DD image to microSD card and boot. Highly recommend using Etcher
Direct download from
Direct download from
MD5 (XZ file): 3e5fdacd534a3c3a8c824239f897202f
File Size: 679MB

Login with
Username : root
Password : password

To run the OS on eMMC
Flash the image to micro SD, power up the board with micro SD and login
Copy the image file to micro SD by using SFTP. The image file must be in .img. note : root user are not allow transfer file to micro SD.
After finish copy the file, power off the board and add eMMC module to the board
Bootup the board, run below command for flashing to eMMC module
>>dd if=[image file] of=/dev/mmcblk1 bs=10M
example : dd if=slack-current-aarch64-xfce_08May18-4.4.126-rock64-build-20180508.img of=/dev/mmcblk1 bs=10M
then edit 2 files in eMMC module:
>> mount /dev/mmcblk1p1 /media
>> echo “rootdev=/dev/mmcblk1p1” >> /media/boot/uEnv.txt
>> sed -i ‘s:mmcblk0p1:mmcblk1p1:’ /media/etc/fstab
After done, power off board and remove micro SD. Then bootup with only eMMC module.

I didn’t use “etcher”. Being a bit old school and used to running as root, I just did a “dd” to the card. Risks and all.

Stuck it into the Rock64 and booted. It just worked.

Once Running

I was pleased to note that it splashes, briefly, a text login prompt on the screen before going to the graphical panel. This is so that if the graphical login fails, you are not left stranded at a black screen thinking your board is dead… On both Ubuntu and Armbian I’ve need to spend a modest amount of time finding out how to shut off the damn bypass of the boot display of status so I could see what was working and what failed. The “magic sauce” keeps changing as SystemD keeps molesting different things. I think I’ve now had to use somewhere around 4 different command sets to get it to boot properly with information displayed. This was a contributory factor to the “dead board” appearance problem. Slackware got it right out of the box.

The general impression of the speed is that it is quite good. It just seems a bit “snappier” than the other OS types I’ve run on this board. Ubuntu is known to be a bit of a fat pig, while Armbian is cleaner and faster since they are “embedded systems” guys and tend o care about wasted features and getting the most out of any board. When in doubt, use Armbian over Ubuntu on ARM based computers.

I went to use “adduser” to add a non-root user then found it wanted “useradd”. It looks like both exist and I’m not sure what the specifics are. Just realize, there are two of them and it might matter.

I did run into one odd case, that may generalize. I was doing a big “dd” copy of a system image to a uSD card. Those tend to run about 10 minutes for the sizes I do most. I launched it. Then could not get the system to let me swap to another window. Clicking on the browser window just left me with no context swap. I could see the (1/2 the window) htop display was updating status and it showed “something” with a lot of red D “disk wait” status that I presume was the “dd” copy. Clicking on the title bar of the htop window would not bring it to the front. Eventually the dd in the other terminal window completed and I was able to resume doing other stuff. This was a bit reminiscent of how the first Linux schedulers ran about 1980 and the problems they had with pre-emptive multitasking… so Slackware change sloth may have extended to the scheduler as well.

The “easy fix” is just to put an & at the end of the command line for things like a big “dd” and put a “nice” at the front. Basically “nice FOO &” will put it in the background at low priority. That’s what we did in the “Old School” days to “help” the scheduler… Or you can just be patient and wait a bit ;-)

At some point I’ll test this again and see if it is a general case or not. For normal use cases over the last few days, I’ve not had any other issues like that.

The spell checking in FireFox seems a bit sporadic some times when editing articles in WordPress. I don’t know if this is a scheduler issue or what. I’ve found that a toggle of the “preferences / check spelling as I type” kicks it off again. As this is a long body of text, it just may be that it is slow getting it checked end to end after a “save”.

At boot-up, the clock is insane. So either you need ot use “date” to set it to something in this decade or add a time sync command to the boot process. So far I’ve just been setting the data long hand (had the same problem on Armbian or Devuan and added a forced time set in the booting scripts; while Ubuntu has that already but in a kind of “phone home” I didn’t like as I want my time set from MY time server not leaking information about me to others…) This is all a very common problem from Linux expecting a Real Time Hardware Clock and most SBCs (Single Board Computers) not having one. A culture conflict of a sort.

Slackware comes with a LOT Of stuff already installed, but not all the stuff I want. There’s no Gimp, LibreOffice, or Chromium. That will crimp my style on some things until I get them installed. Editing photos of my garden or for postings, for example. It does have FireFox installed (using it to write this) so that covers about 90% of blog maintenance duties.

I wanted to do a screen shot and found that “scrot” was missing. Then discovered that under the menu system it has some “screenshot” option installed. So the function is there just in an odd way. But I still wanted to install some choices…

Which leads to the issue of adding software. This is where I’m more or less stuck at the moment. Learning the Slackware package management / software build system. It isn’t a critical need at the moment. The browser gets me most of what I need most of the day and I can change to another system for the rest. But eventually it will be a necessity. Now the normal way Slackware works, this isn’t a big issue. Just issue an “installpkg FOO”. However, ARM, being community supported, may not have the configuration on the package system set up. On this port it didn’t seem to work and looks incomplete. So “some assembly required”.

I’ll give one example. In /etc/slackpkg there is a file where you list the package mirrors you want to use. Here’s the default. Notice that NOTHING is selected:

ash-5.0# cd slackpkg
bash-5.0# ls
blacklist  mirrors  slackpkg.conf  templates
bash-5.0# cat mirrors
# mirrors - List of slarm64 Linux mirrors.
# SlackPkg - An Automated packaging tool for Slackware Linux
# Copyright (C) 2003-2011 Roberto F. Batista, Evaldo Gardenali
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# GNU General Public License for more details.
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
# Project Page:
# Roberto F. Batista (aka PiterPunk)
# Evaldo Gardenali (aka UdontKnow)
# You only need to select one mirror and uncomment it.
# ONLY ONE mirror can be uncommented.
# You can use a mirror not included in this file.  Many people have mirrors
# in their local networks.
# Slackpkg only needs to point to the directory that contains
# "ChangeLog.txt", and don't forget the trailing slash.
# Local CD/DVD drive
# Local Directory
# Local CD/DVD drive
# Local Directory
# slarm64 AArch64 x.x

# slarm64 AArch64 current

Now notice that most of the Mirror choices are actually local media. At the very bottom are two internet locations. Look at the high level qualifier on the names. Where are .bg and .ua anyway?

.bg 	 Bulgaria
.ua 	 Ukraine


Look, I’ve got nothing against Ukraine or Bulgaria, but really? I’m supposed to pick up my bits from 1/2 way around the world in a country with a couple of revolutions in the last few decades? Nothing closer to home?

I did a fair amount of searching, found a large list of Slackware Mirrors… ALL of them for the Intel PC build. Eventually, maybe, ran into an address that claimed (I think..) to be ARM Rock64 and in the UK, but it’s somewhere in a hundred tabs on my tablet, not on this box.

So that’s the kind of thing where this will bind a little. You get to search the world to find out who in “The Community” has cared enough to set up a package mirror. Then ask yourself if you trust them. Then find out if it actually works. Then… eventually you can add some software to your Arm system.

And that’s where I’m at this morning. A few days into it.

It is, generally, a nicely done and livable “old school” Linux that suits me just fine. It has a couple of trivial bits of sand in the teeth (like that scheduler issue) and one big fat slap across the face in “Community Support” and coming Non-Configured for even the basic adding of a package. So right out the gate you are unable to use the “here’s how to add a package” guides and must get in to the “how to set up and configure package adding?”

So for now it’s a nice Browser Box and nothing more. I’m not going to whack on it hard, but rather on an “As time permits” basis; so it’s likely to be a week (or maybe two) before I have mirrors and slackpkg.conf set up in a usable way and can add the other software I want / need. IF someone in The Community has done the port and IF it is on the particular mirror I end up using…

In Conclusion

So there’s your “about a week” report on whacking on SlackArm on the Rock64. I’m going to leave the Rock64 running Slackware as a longer duration “how does it wear on me” test and as motivation to get the package stuff worked out. I’ll be reverting to other SBCs and other OS types as needed for other things (like GIMP and LibreOffice and such).

I’m also going to run the same trial run thing on Gentoo. It is FAR more fully documented and with official support for the ARM platform. It is also a Hackers Delight PITA with “portage” and a full source build to “make it go”. So on a Raspberry Pi, for example, it can take most of the day to finish a compile / build cycle and THEN you find out if it failed. (I did this once or twice – not exactly fun or user friendly…). That is likely to be done first on a Raspberry Pi or the Pine64 (as I don’t need to mess with my other, working, systems then) and I might even give a try at the distcc / cross compile builds. That can only happen once the first two are up, though. You must have the same libraries and such for a distcc build to work, so to make a Gentoo you need a Gentoo… So the first bring up is done as a cross compile of a sort often in a chroot on a hosting OS, then you can repeat, then you can configure for distcc. THEN you can have that “whole day build” cut in half, or quarters, or however many build SBCs you have. All fairly nicely documented. Just a small matter of work…

I didn’t really want to end up putting my time into this Systems Programmer stuff. I wanted to just install Devuan where I could and use Armbian where I had too… but the SystemD breakage has become too much to bear, so I have to deal with the move off of SystemD based systems. As you can see, that’s not easy at present. Over time I expect it will be easier. Devuan is clearly going to succeed and that means eventually showing up on more boards. Pottering is NOT able to reduce his “Dick With Factor” so is continuing to screw up things that always “just worked” and that continues to provide more motivation for folks to move off of SystemD. Those trends are going to persist.

Eventually someone will start from a clean “upstream” that is NOT Red Hat or Debian (so not infested with SystemD) such as Slackware or Gentoo and use them to make a clean and user friendly distribution for The Masses. Heck, it might even be me ;-) Puppy made a Slackware based distro at one point, maybe still does. Then there are Gentoo based distros already too. Unfortunately for me, most of those are on the Intel PC platform (or maybe all?). There is also Void Linux that’s an interesting possible and cutting a new path using MUSL and CLANG and other upgraded tech. (I might try it on something, again, and see how far along they have come).

But for now it is more of a “Roll Your Own” world on the strange new SBCs using that “other chip” in the ARM world. That is substantially the way it has always been. The “biggest community” has the most eyes spotting bugs and the most hands fixing them and the most folks writing How To docs and the easiest time for Noobs. So the Raspberry Pi is NOT the best hardware, but it works the best for most folks as the Community is better so the software is better and easier. Devuan runs great on the Pi.

Despite the poor heat management and the not-quite-right power input and the easy to break mini-hdmi, I could still end up buying a Pi Model 4 someday for just that reason. Because the PineRock64 and the Odroid N2 are largely limited to Ubuntu and Armbian “out the gate” and it takes a few years for other OS types to be ported by the small Community. Oh Well.

It is what it is, and I own the SBCs I own, so I’ll do what I do ;-)

For now, that’s Devuan anywhere I can get it to go, and getting comfortable with Slackware and / or Gentoo on as much of the rest as I can, and then “exploring” whatever else there are in the way of options (Void, etc.). I’m also going to continue playing with NetBSD some. I had a FreeBSD desktop running about a decade back, and it is a very viable option. Just abandon Linux in whole and move back to real Unix. Some of the SBCs can just end up in a junk box if needed. I’m only typically using 3 or 4 at any one time so somebody is always in a box. Not exactly a hardship.

I can also state with certainty that, from now forward, when drooling over the New Hot Board I’ll not be bothering to buy one if the only operating system choices on it are using SystemD. I’m done with that.

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.

47 Responses to The First Few Days Of Slack (ware)

  1. E.M.Smith says:

    Perhaps a tiny bit of clue. That “mirrors” file says:

    # You can use a mirror not included in this file.  Many people have mirrors
    # in their local networks.
    # Slackpkg only needs to point to the directory that contains
    # "ChangeLog.txt", and don't forget the trailing slash.

    And poking around searching for mirrors and ideas here:


    Download sites
    The primary site is 

    Searching the “usual place” for packages found a slarm64 directory:

    That looks like it might fit the bill:

    Name 	Size 	Last Modified
    	272 KB 	10/20/19 	9:52:00 PM UTC
    	1 KB 	10/20/19 	9:52:00 PM UTC
    	232 KB 	10/20/19 	9:07:00 PM UTC
    	399 KB 	10/20/19 	9:49:00 PM UTC
    	2 KB 	10/6/18 	12:00:00 AM UTC
    	750 KB 	10/20/19 	9:46:00 PM UTC
    	1 KB 	6/21/19 	5:04:00 PM UTC
    		10/20/19 	9:49:00 PM UTC

    So I’m going to configure this system with that target as mirror and see if it works or blows up ;-)

    I have no idea how much the aarch64 codes care about what system they are on. It ought to be the case that as source builds, all the library issues tend to be mooted (other than at release level changes). So I suppose the first thing is for me to just figure out what release level I’m on and do I need to do some equivalent of update / upgrade… and how…

    Isn’t starting all over again fun? Isn’t it just great getting to learn all over again things you have done a dozen times before for decades on divergent systems? Isn’t it just wonderful how everyone invents their own, incompatible, methods of Systems Admin?

    /sarc; for anyone who missed it. Oh for just a little kiss ethos and a lot less dick with factor in the systems admin world across the various linuxes…

  2. corev says:

    EM, I agree with the load difference and the other differences as being too off putting for me to use. I currently have the Armbian version loaded on my rockro64.

    BTW, I ended up having a similar problem with my XU4s.

  3. E.M.Smith says:

    Well, only one quirk. That ftp site only had -current so when slackpkg was run it asked did I really want that testing branch. I said yes (what was my alternative? More “go fish”?) and it seems to have run:

    bash-5.0# slackpkg update
    You have selected a mirror for Slackware -current in /etc/slackpkg/mirrors,
    but Slackware version 14.2+ appears to be installed.
    Slackware -current is the development (i.e. unstable) tree.
    Is this really what you want?
    To confirm your choice, press Y, else press N. Then, press Enter: Y
    Slackpkg will not show this warning again unless you remove the
    /var/lib/slackpkg/current file. 
    --2019-10-21 18:29:02--
               => ‘/tmp/slackpkg.Ys3XbB/gpgkey’
    Resolving (
    Connecting to (||:21... connected.
    Logging in as anonymous ... Logged in!
    ==> SYST ... done.    ==> PWD ... done.
    ==> TYPE I ... done.  ==> CWD (1) /slarm64/slarm64-current ... done.
    ==> SIZE GPG-KEY ... 1971
    ==> PASV ... done.    ==> RETR GPG-KEY ... done.
    Length: 1971 (1.9K) (unauthoritative)
    GPG-KEY                       100%[===============================================>]   1.92K  --.-KB/s    in 0.01s   
    2019-10-21 18:29:05 (177 KB/s) - ‘/tmp/slackpkg.Ys3XbB/gpgkey’ saved [1971]
    			Slackware Linux Project's GPG key added
    Updating the package lists...

    And several more. A few minutes worth, all told. What now?

    I’m following:

    It says:

    Installing updates using slackpkg
    The slackpkg update command will connect to a Slackware mirror and update the local package information database on your computer. This command does not actually install any package!
    The usual routine for upgrading your Slackware to the latest patches is as follows:
    # slackpkg update
    # slackpkg install-new
    # slackpkg upgrade-all
    # slackpkg clean-system

    is nest by has some warnings about the clean-system and it is only needed for after s major release upgrade, so I’m not doing that step. Looks like intall-new and upgrade-all are it

    Also, it had a ‘slackpkg gpg’ it said to run, but that gave a bad option response, so I think it may be deprecated..

    In any case, I’m off to the install / upgrade step… but maybe after I take a backup of this chip ;-)

  4. E.M.Smith says:


    Armbian is still usable (having fixed most of the issues that drove me away from Ubuntu) for now, but I’m thinking I’ve got maybe a year before they cave on things like the interface names mutating and start to miss some pernicious bugs like the Ubuntu fstab mangle of results. So figured It’s time to “Bite The Bullet’ now and get started.

    I’m pretty sure I can get Devuan to work on the XU4, but my first trial of the Devuan 2.0 install failed to boot. I’m thinking I can just take the 2.0 userland and tar it onto the Armbian kernel / boot stuff that all works. Either that or I need to work out where their boot process is broken. (I did have an uSD card fail on me, so I’ll need to test the direct 2.0 again first just to make sure it wasn’t my gear. But I’ve tried to get a Devuan to boot directly on the XU4 and always failed.)

    But that’s for another day. Right now it’s just running straight Armbian and doing OK. Armbian has fixed the horrible bits and mostly I don’t need to do anything with SystemD on it as it is mostly just a browser and editing station.

    Ditto the Odroid N2. It is running as a media station driving the bedroom TV and as a blog management terminal so browser is about it. Armbian doing fine there, too. For now…

    That’s why I’m starting my plunge into Slackware and Gentoo on “variety hardware”. The candidates are the lesser used but around long enough to have ports bits: Pine A64, Rock64, Orange Pi One, Odroid C1 & C2. Starting with the Pine and Orange products so as to avoid the Odroid boot “security” oddities… and the Orange Pi One is only 512 MB memory so any source builds will be way slow and probably swap limited. Them I’m thinking will need a build cluster… or cross build.

    I’m also thinking I’ll do a port of each to the Raspberry Pi Stack just since it is very easy (widely done and documented) and I can just spin those images off to disk for later. Then, when I need a Gentoo or Slackware aarch64 distcc compile cluster to do a big build on some aarch64 SBC, I can (in theory…) use the whole Pi Stack as a build monster. That would be about 20 cores including 4 on the target box. But that’s a ways in the future when I’m ready to take on the “stuff” of a distcc cluster building systems. (keeping libraries in sync, perhaps needing to set cross compile options on some ‘mixes’ and definitely if I try doing a v7 / 32 bit version, etc.)

    We’ll see. This is an organic exploration so I’ll just be bouncing off walls and taking the path of least resistance / maximum reward. If that ends up being “launch the build on a single small SBC and go watch Red Dwarf on DVD”, well, so be it ;-)

  5. E.M.Smith says:

    Well this is a bit of a pisser…

    Just shut down, did the “dd of=backup” and then, it doesn’t boot again. OK…

    Checked the backup against the uSD card:

    root@odroidxu4:Rock64/BUPS# cmp SlackArm_Rock64_Conf_BBr_ems_21Oct2019 /dev/sdc

    When compare (cmp) finds no difference, you just get the prompt again.

    So I guess now I get to explore “why?”… I’ll start with making sure the fstab has no mounts going on that might hang things… But really…

    I can just drop back to the original install. It isn’t like I’ve saved a lot of history on this image, and anything that is there I can likely get off of it since I can see the file system:

    root@odroidxu4:/Rock64/BUPS# mount /dev/sdc1 /SD/ext
    root@odroidxu4:/Rock64/BUPS# ls /SD/ext
    SG5 SWAPFILE bin boot dev etc home lib lib64 lost+found media mnt opt pkgs proc root run sbin srv swap sys tmp usr var

    Life Of A Systems Admin…

  6. Kneel says:

    Been having some decent experience with the Android TV boxes using Atmel SoC chips (S905W I am using). These are cheap (< $US50, often <$US30), come with a case and power supply, have HDMI video and audio out, and a couple of USB ports. 2G of RAM and 16G of flash, which seems plenty…
    Need to be careful about EXACTLY which one to get – I didn't have much luck getting the armhf (32 bit) ones to work, nor the RockChip SoC ones. So it's Atmel SoC and ATM S905W is working with both Armbian and Ubuntu 18.04 (yeah – systemd, but whatcha gonna do?). I also tried an S905X2, which has USB3.0 (nice for a disk based system), but at the time no bootable support for that – although there is now, I haven't gone past getting it to boot into X. One day, grasshopper – that's for a "daily driver" desktop, the embedded system is priority over that ATM.
    As you say, Armbian is a bit "snappier" because it expects a cut-down ARM board, not an x86_64 desktop box.
    I'm doing this as an embedded device, so the armbian "freeze" feature might be useful too. Currently researching how to make a bootable image that runs an RO root fs and no flash writes (application only rarely needs to write to flash, and then only with "manual" intervention) – getting overlayroot to work is the current stumbling block, seems the aufs and/or overlayfs filesystems are not part of the standard S9xxx build. Sigh. On the plus side, everything else I want/need seems to work – although my custom script is pegging a single CPU at 100%, it seems to be "on the edge" as it often drops into the high 90s and doesn't seem to "miss" anything important it needs to do…
    I've tried this as "desktop" too, and find it's normally OK, but annoyingly slow to load apps because of the flash access speed (I think they use a 4bit flash interface!), but if you can live with that, it's fine. Boot only takes about 20 secs from power on, but that's to a CLI not a GUI.
    So, I too may need to go down the "build from sources" route, but I'm trying like hell to avoid it…

  7. E.M.Smith says:


    I thought of trying to jail break TV boxes and sticks, but never had the time to get up to speed on them. Figured the SBC route would be easier and about as cheap. OTOH, 2nd hand stuff as folks upgrade is nearly free…

    Thought they might make an interesting compute cluster…

    I suppose after I Linux up the Chromebox I’ll be less timid about it ;-)

  8. Pingback: Mount dd Image As Disk – A Useful Little Hack | Musings from the Chiefio

  9. E.M.Smith says:

    Well, I’m now back to where I was just prior to trying the update process. I restored the base image, did the changepw on root, did the useradd for my account (and changed that pw) and then did an untar of the /home directory from the prior version.

    In the process found that all I had on the user account was FireFox config info and cache / history. I guess that was worth preserving…

    At this point, I’m going to just live on the system for a little while then take a new backup just BEFORE doing even the smallest of update processes…. Yes, this only cost me about an hour of actual time to recover, but still… I’d rather not be in Groundhog Day….

  10. E.M.Smith says:

    Added this to /etc/rc.d/rc.local at the bottom so hopefully I’ll not have to keep fixing the clock at each boot up…

    if [ -x /usr/sbin/ntpdate ]; then

    The ntpdate command is installed by default, and that’s what I used to sync the clock, so this ought to just make the clock right at each boot up. Avoiding all that browser “can’t connect to web site cert problem” misleading statement that ought to be “your clock is wrong”…


    And added

    server 192.168.x.y

    to /etc/ntp.conf so it uses my local time server (where x and y are the actual ip numbers)

    So now I can also change that rc.local entry to point at it as well if I want to be completely private about time…

  11. E.M.Smith says:

    BTW, did another “dd” and again had zero response to clicking on windows while it ran.

    So far this seems to involve only the “dd” command… so maybe it’s something “special” done to assure that the “dd” copies are pristine and no interrupt causes “issues”… (i.e. a patch around a bug or paranoia).

    Launched as a background task (so: dd STUFF &) the system is a bit slow, but you can swap windows and do things, so it is something about dd as a foreground task that sucks the priority out of other things… (This being typed and posted as a 2 GB dd is running background).

  12. E.M.Smith says:

    Verrrrryyyy Iiieeenterrrresting……

    Doing a backup of my pristine version, then attempting to boot it, also fails. Checking the uSD card, I see that it is “EXT4” file system type. Remembering that I was abandoning ext4 wherever possible due to it having 2 incompatible versions and the developers AUTOMATICALLY and AGAINST MY WILL converting old type to new type an making them not work on old type kernels and systems….

    I’m now pretty sure that the “new” system where I’m doing the “dd” to dump an image of the uSD card is “improving” the ext4 file system on the Slackware install and thus making it incomprehensible to the OS that tries to boot from it…


    I’ve mounted the uSD as a file system, used “cp -r” to copy all the contents to a TEMP area on Real Disk, formatted the partition to ext3 with gparted, changed the boot.cmd line to say ext3 and now I just need to copy back the bits and try to boot it. Maybe…

    Well, if nothing else, it’s a very good illustration of the dangers of using ext4 in a multiple system environment with disks that move around….

    Back in a bit with news of how this worked out.

  13. E.M.Smith says:

    Well, it didn’t boot. I think the diagnosis is correct, just the cure was inadequate. Most likely more than /boot/boot.cmd expect an ext4 file system.

    So, ok, what I’m going to do is, AGAIN, drop back to the original image and build it up again, then put some very old system in the backup system so no ext4 change of type happens. IF that works, it proves the thesis AND says the uSD needs to be kept away from newer ext4 type systems.

    Maybe after a Bongino Break :-)

  14. p.g.sharrow says:

    @EMSmith; Glad to see it is you that is hacking your way in the jungle of Operating Systems and not me! Seems after one or more of these forays you always remark about how stable and dependable The Raspi and Devuan2 are for everything,………………….just a bit slow!
    That ext3 verse ext4 auto update seems to be a real landmine as damaging as the systemD improvements.
    So far Devuan2 seems to be the OS that is the most likely to work for everything needed in a system large or small. From router up to massive parallel. …pg

  15. E.M.Smith says:

    Yeah, it’s what I do…

    Rarely seen outside I.T. shops is all the time spent EVALUATING systems to determine suitability, stability, functionality, flexibility, bug levels, brittleness, etc. etc… It’s a huge part of the job.

    Sadly, many shops are lazy and just use “the usual”… (How Micro$oft got the desktops). But in the HPC world (High Performance Computing) you must do it or you fail.

    So a few decades of that, it becomes a habit. 8-}

    So to addresses “What is best?” Requires a “For what?”…

    IFF you want a stable and dependable OK Desktop that has good security, there are a few choices. IFF you want a cheap cluster of a few dozen cores, it is a different answer.

    I want both, so get to search even further…

    Then, I want to use ARM cores so the available choices strongly limit (for now…)

    First issue: Enough MIPS for a desktop. Anything more than a Pi M2 is barely enough. The Pi M3 is the lower edge of comfortable, and at Rock64 or better it is fine. I find the Odroid XU4 quit nice.

    Now, want a media station running youtube at 1080p? Then the lower bound starts about the XU4 and the N2 is great. (How well the OS supports the GPU is critical here too. Dedicated releases like Kodi work on smaller SBCs and Ubuntu does well on the larger ones).

    The memory is just too small at 500 MB (Orange Pi One) though that is great for a headless infrastructure server (where I’m using the Pi Model 1 also). At 1 GB it is the lower bound of OK for browsing. I reqularly roll a coupke of hundred MB to swap. 2 GB is just way nice. The only need for 4 GB is lots of RAM disks or big system compile / link loads ( kernel or browser building).

    That memory size of 2GB, a 1.5 Ghz clock (instead of 1.2 on the Pi M3) and a better I/O channel is what makes my Rock64 just better enough to be nicer as a desktop.

    The Pi M4 would be at the top end of this performance list but for a couple of dings. I have no need for two monitors and would need to buy new mini-HDMI cables to use it, and the mini connectors are fragile. Given my constant plugging thing, I’ll break one in weeks… The cores used are hot ones. It has no heatsink. You need to put about $10 or more into cooling. By that point you are in XU4 or N2 land with great cooling included and I already own them… Then, the USB-C power connector is not quite spec, so some cables work and some don’t (and I’d need to buy yet another power supply…) So I’m not enthused right now…

    Summary: Pi Model 3 is enough, Odroid XU4 or N2 are great, Rock64 in between (and RockPro64 is like the N2 but without an O/S I like yet and you buy the heat sink additional…)

    Which brings us to the Operating System choices… Here, the community size is the major factor. It is largely dependant on eye balls spotting bugs and fingers typing code, and more is better.

    Raspberry Pi crushes here, and it is a Noob heavy community so lots of hand holding available.
    Right behind them is Armbian. A big more technical community who likes quality.

    That’s where I was, happy, when SystemD crapped up the place. (Honorable mention to Debian as the Armbuan upstream, and Ubuntu as a fatter more glitzy port also based on Debian, but not my style). Unfortunately, Debian looked to Red Hat as their upstream, so swallowed without tasting…

    Enter Devuan as My Savior…. Basically just keeping the Debian from before alive and well. But limited in hardware supported. Best on PC s and the Raspberry Pi (of the hardware I have). And it uses the whole 64 bit word, unlike Raspian… So done deal, there.

    On the other, less widely sold, hardware, the smaller community reduces support. Pine company (Pine A64, Rock64, RockPro64) has more OS choices than most at their site. Almost all SystemD… but they do have Slackware and BSD. (And, of course, Gentoo works everywhere, you just need to port it /sarc;)

    For now, Armbian is still a decent build. They fix most of the bogus decisions before you trip over them. (Like that renaming eth0 to mumble-string-junk…). So it is still my “Go To System” for anything not Devuan. Running it on the XU4, N2 and RockPro64. BUT they can only do so much and Pottering is contining his corruption, so a timer is running… I probably have 6 mo. to a year before it becomes a problem. 2 if I set up my own repository (as Armbusn obsoletes releases fast then you can’t add new programs easily once archived).

    Thus my investigation of Slackware and Gentoo. To find a longer term more stable build to use outside Devuan supported hardware. Both have great reputations and a reputation for technical challenge….

    Summary: For now Devuan on supported hardware is best, Armbian on others. A year or two from now Slackware, Gentoo or some newcomer (Void?) is more likely.

    Per ext4:

    It is a HORRIBLE thing to do TO someone something that it a one way incompatible conversion even if you call it an upgrade. You ought to ALWAYS ask “would you like me to do this FOR you, or not?” The ext4 package developers made a very bad decision and it has repeatedly bit me. So I really wonder how many less technical folks think their stuff died when it was the ext4 “feature” bug biting them. How much blind grief has it caused? Yes, much like the SystemD fstab crap on Ubuntu.


  16. Kneel says:

    EM: “Thought they might make an interesting compute cluster…”

    The ones I’ve tried all come with a 5VDC plug pack switchmode supply, rated at 2 or 2.5A.
    You COULD get a “standard” PC power supply to run a shed-load of these – those supplies are typically at least 20A @ 5V, and I’ve seen them rated at 100A…
    Nice to have a case that suits – even if most of it is empty space :-) (need the room for the I/O connectors etc, not anything else)
    Oh, and an IR remote control – media centric, but if you need/want it…
    These SoCs also have some pretty impressive GPU grunt too – can decode 4K UHD @ 60fps and display it on HDMI – just hardware, only minor CPU supervision (keep the stream coming etc). So IF you need GPU grunt, a 5 core GPU is nice…
    Also, they already come with heat sinks – in fact, the S905X2 has a roughy 3″ x 3″ sheet of 0.75mm aluminum sheet as a heat sink, with cooling vents right there too – you can strap a cooling fan to them and not hit temp based speed limiting, even pegging all four cores + the GPU. Although to be fair, I haven’t actually proved that yet (others claim it though, and have video as proof. In fairness, I don’t think they can actually peg 4 cores @ 100% – just not enough memory bandwidth for that!).
    With arm64 and Atmel SoC now a part of the standard kernel, if you NEED something up to date (I don’t, but hey…) they’re hard to go past.
    The prices are REALLY good – IIRC, I paid $AUS35 (inc freight from China), or around $US20 on AliExpress. WITH case, heat sinks and power supply (and IR remote and an Android instruction booklet – woo hoo! :-) )
    There is support for re-flashing the eMMC with an image of your choice and bootloader changes too, if you like (haven’t tried any of that yet, other than a bootloader update to allow boot from uSD and/or USB mass storage).
    After this particular embedded project, I hope to try getting on to boot straight into some sort of media centre to use as a front-end for my PVR system…so many projects, so little time :-)

  17. E.M.Smith says:


    Yeah, I know the time issue… Here I am doing WT? system image updates to try to escape the SystemD folks “doing things TO me” instead of for me, when I’d really rather being doing database design changes for the temperature database and working out cross compile on a cluster for a distributed model run. Oh Well. One does what one must.

    @Slackware Saga:

    Well, I’ve once again got it running on the Rock64, and now I’m doing a backup, again, BUT: This time I’m doing the backup on a SlackPi image that was last used about 3 years ago, so ought not be any ext4 issues there ;-)

    We’ll know in about 1/2 hour.

    This image is running the (fat, normally slow) KDE Desktop. It’s very pretty but not as “snappy’ to get things done as LXDE or XFCE. Things like, to get to a terminal window takes two levels of pop up menu instead of one. OTOH, it isn’t a bad window system and I’m presently running about 393 MB used with the browser open and with the “dd” running in the background.

    It is surprisingly comfortable on the Raspberry Pi. The folks who did this port clearly have tuned it up a bit and polished the edges. It even set the time correctly at first bootup.

    As I have excess R.Pi boards, I’m going to just leave this one as Slackware for the duration of the Slackware exploration. I’ll be using it as the “alternate desktop” when doing things like backing up the Rock64 or otherwise having it out of service.

    While I really like Devuan, I could easily see using Slackware on the Pi M3 as it is memory efficient and fairly comfortable.

    One other note, this is being posted from Konqueror web browser (as that’s what KDE has…) and it’s a bit of a new beast for me. I will likely try the whole update / upgrade / install software process here before doing it on the Rock64 again. I suspect a lot of the configuration for updating has already been done on the Pi Slackware image.

    Don’t know how I’ll “get along” with Konqueror, but we’ll see ;-)

    It would also make sense for me to explore the newer Slackware for the R.Pi set. But that will be for some other day a ways in the future…

  18. E.M.Smith says:

    Well, one thing, I can’t edit comments in Konqueror… Likely some feature set change in the newer wordpress that isn’t compatible with an old unusual browser… Oh Well…

    So not going to be my blog operations system…. at least not unitl either FFox or Chromium install, or some Konqueror update, lets editing work.

  19. E.M.Smith says:


    I’m back on the Rock64 AFTER doing a dd backup of the uSD card!

    OK, this tends strongly to confirm that the “new” Armbian I was running on the XU4 was in fact “uplifting” the older style ext4 on the uSD to an incompatible “newer” version when I tried to do a backup of the chip.

    Lesson Learned:

    Have an older system image from before the “update” to ext4 for doing backups of Slackware.

    I’d really rather have the system image built with an ext3 file system, but that’s a lot more work as I’d need to “roll my own” image. Maybe in some future day if I settle on Slackware as a reasonable alternative…

    FWIW, with that little “issue” dealt with, I’m now much happier with Slackware. The fact I can run a KDE desktop on the Pi M3 with reasonable performance and low memory use says it’s an efficient build.

    Overall, the user experience is quite nice. (Modulo the Systems Admin experience of interacting with “new” and “improved” incompatible and cranky infrastructure in my shop …. )

    At this point I’m going to continue the exploration of Slackware Admin, with emphasis on how to do an update / upgrade cycle and install software (like other browsers). Since I can, now, do proper backups / recover of systems images any “ooopsy” will be much easier to fix.

    I do have to emphasize that the desktop user experience was quite fast enough and very acceptable on both the Pi M3 and the Rock64. Neither one of them a high end box. The Rock64 does a nice job of YouTube at 480p (jerky at 720p) and the sound works! I’ve not tested the Pi but it ought to be similar, though I’d not be surprised if it needed to drop another step of resolution. On the Rock64 I was running the video in the YouTube page, not full screen, so that might have an effect too. Still, quite enough to watch a typical video.

    So in fact the Rock64 with Slackware is usable as the lowest end of media station I’d want. Having audio that works beats the SystemD installs I’ve had where PulseAudio was just broken and fighting me all the time. No good having 1080p without sound… Basically, WORKING software is far more important that FEATURES!!! that are broken or so cranky as to be unusable.

    Well, with that, I’m going to dig into that whole update thing again…

  20. E.M.Smith says:

    Slackware is just efficient.

    I have 20 tabs open and memory use is at just 22k over 1 GB. Out of 2 GB on this SBC. No swap needed for a long ways more. And things are just ‘snappy’. CPU use is running about 50% most of the time while using the browser. It has power left over in normal desktop use.

    I’m liking the performance on a lower end SBC. I’ll have to do some benchmarks / test uses on this one and on the R. Pi M3.

    What is very clear is that where booting up Ubuntu is an experiment in patience, sloth, and adding swap space, Slackware is fast and efficient.

    Some of that will be the desktop choice (XFCE is a lightweight one), but then again KDE is known for pudge and sloth (at the gain of ‘eye candy’) too and it was OK on the Pi.

    This bodes very well for Slackware as a “Daily Driver” on small hardware.

  21. E.M.Smith says:

    Well that was easy….

    I was following the directions here:

    to do the upgrade. It went flawlessly. I chose to use the Bulgarian mirror listed in the mirrors file in the expectation it would be the 14.2+ version I was on and not give me the “this is -current” and you are not wanna still use it? message… but in fact it gave me the same message as the UK ftp site I’d used before. Note To Self: Swap mirror back to UK site.

    Not only is the UK closer so let net traffic, I’m sure now I can be accused of being a “Bulgarian Asset” by Hillary… after all, I’ve “had computer connections to Bulgaria” /sarc; (I hope…)

    So the commands used were:

    # slackpkg update
    # slackpkg install-new
    # slackpkg upgrade-all

    The update took about a minute. (it loads the names of things to update).

    The install-new took about 5 minutes
    (i just accepted the list of all that it gave – it has a ncurses panel where you can pick if desired).

    Then, the upgrade-all took just about 48 minutes. CPU ran 8%-12% for most of it, with the odd bit at 4%. Clearly it is I/O limited fetching from Bulgaria and writing to a uSD card.

    I’ve not done the “clean-system” yet as I want to look things over and the guide says it isn’t that important most of the time anyway:

    # slackpkg clean-system

    So that’s now a “done deal”. Looks like their package manager works fine, even if someone (else) had to manually work out dependencies. I’m OK with this.

    Next up (after Yet Another Backup) will be adding a package. As this is about a 6 GB system, it has most stuff already installed, but I’m sure I can find something to add. I hope that LibreOffice and GIMP are ported…

    THE biggest headache was the ext4 bigguery that really was not the fault of Slackware, but of the ext4 package manager and Debian (for accepting it). 2nd was my reluctance to just un-comment one of the mirror lines and run with it. Over that hump now…

    So as of this point, all that’s left is adding a package, and then spending some time “settling in”. Things like adding all my disks to the /etc/fstab list and such.

    I’m comfortable at this point saying I’ve got a very viable non-SystemD desktop and server option on the Rock64. So in a couple of days I’ll be doing the same with Slackware on the RockPro64 and the Orange Pi One (assuming I can find an image).

    That ought to make a very tidy Slackware cluster too. Then I can work on things like distcc on it for fast source builds.

    At that point will come a decision: What to do with the Odroids? N2, C1, C2, XU4.

    Odroid has a PITA boot loader process with magic sauce hidden in the first (18?) blocks of the uSD card / disk. It requires a “signed” image. There are work arounds, but… So I’m hoping to find “signed installs” are already made and available. But since Armbian is working fine on them, I’m willing to leave that for last.

    Somewhere on the side, during this Slackware eval process, I’m going to revisit a Gentoo build / install. At this point, though, I’m not really feeling the pressure any more. Slackware is working fine, has a familiar “old school” rc.d style init (BSD style) and seems to be a quality build that works well. The only real negative surprise was not their fault and will not show up if you don’t put their ext4 file system uSD card into a newer Debian / Devuan / Ubuntu / Armbian system and have it munged automagically and against your will…

    There you have it. I’m off to boot up the Pi Slackware, backup this system image, and then maybe upgrade the Pi image as well. Now that I know what I’m doing ;-)

  22. E.M.Smith says:

    Interesting… Decided to snag a backup of the Pi Chip while the Rock64 was still “up” preparatory to an update on it, too. Launched the “dd” in a terminal window before thinking to put it in the background…

    Seems that now, after the update / upgrade, the launch of a dd no longer causes sloth / blocking of other activities. Whatever that was, has been fixed.

    It will likely be about an hour for the backup of the Pi Chip, booting the Pi, backup of the Rock64 Chip now that it’s updated, and then maybe another hour for the Pi to update / upgrade, maybe.

    FWIW, the “upgrade” to Fire Fox 60-something has made it significantly more slothful. I may look into how to back level it to the 50-something…

    At that point things ought to be up to date and pretty clean for both. But the odds of my commenting much during that time are slim… so expect a bit of a break here.

  23. E.M.Smith says:

    Well those time estimates were wildly off,,,,

    Everything was about right up to the step where the Pi OS got upgraded…

    It took about 50 seconds for the update, then about an hour for the new packages to install. Then…

    I think it is about a 14.0 or maybe a 14.1 release. The Mirrors list had 14.0 and 14.1 choices, but nothing selected. Based on the naming system, I created a 14.2 entry and launched the upgrade-all. It worked, but now, after “Only” 14.5 hours, it is still upgrading packages….

    As it is tying up the monitor, I’m on the tablet or TV…

    It looks like it is working correctly, which is a bit suprising. Usually jumping 2 major releases as an upgrade in place “has issues” on other distributions. This one is tossing some warnings, but presses on. The warnings are limited to individual packages and often about a change of “type” for some library, so likely some major change in them.

    Hopefully it finishes soon…

    For now I’m happy to sip morning coffee, but another 6 hours from now I’ll be impatient…

    It looks to be I/O limited. CPU is lightly loaded: single digit percents to pegging one core on de-xz decompressing a package in a burst a small part of the time. At some point it rolled 244 MB to swap but now is only using 235 MB of the 1 GB memory, so some package was a memory hog but most are not.

    As it does a lot of writing to the uSD card, I suspect the sloth is evenly split between that and the package server speed. My internet connection is not being stressed at all. (We can run 3 TVs at 1080p at once with about 50% left over for downloads on the computers…) The pauses seem to come at download, write to “disk” and remove old package files, with only occasional short de-xz spikes on the CPU. It is likely the (sum of all three) X (Every Single Package) of a 6 GB install size… and maybe doing it in 2 steps to jump the major releases…

    (Sometimes you must install intermediate releases so the next upgrade can work … )

    Ill post the final time and outcome when it finishes…

  24. E.M.Smith says:

    Hey, it finally finished! It started 3 PM, finished a bit before 8 AM. I make that a little under 17 hous… reboouting now so I’ll soon now how well it worked.

  25. E.M.Smith says:

    Well, after the reboot everything looks to be working (at first glance, at least the browser and terminal are ;-)

    I’m now getting little “rainbow squares” in the upper right corner that I think mean low volts? on things like launching the browser. (Some use a lightning bolt so who knows…) I’ll need to check that. But it doesn’t stop it.

    Oddly, it has 16 k on swap already with only 395 MB used with the browser open, so something in the boot was a memory hog (unlike before). When KDE launches it is slow to load, so I suspect it’s the culprit.

    The video compositing “jitter” on dragging a window is gone, so that was fixed.

    I’d told it to use the config files in the release update and copy mine to the side as old.whatever, so my clock setting was gone. I’ll need to go back and revisit the config files (ntp, fstab, etc) but otherwise, looks good!

    The PSU I’m using is a standard Pi one and I’ve used it for years, so maybe the volts sensing is overly sensitive? (Or I’ve been happily ignorant of sub-par volts…)

    Anyway, I’m off ot errands for a little while. Happy with this being done and happy that it looks like an improvement on an already good system.

  26. E.M.Smith says:

    Ok, I've put in the clock fix at boot and all is good now. I did have to reenter my browser settings for home directory though why is unclear.

    I'm still getting a tiny bit of 'low volts' rainbox box indication at KDE launch, but otherwise it is pretty much not showing and doesn't seem to be causing an issue. I'm beginning to think that a small capacitor or battery in the 5 VDC line would be a good idea. Stabilize the current surges. Ought not be hard to just clip one across the +5V and Grnd header pins…

    I have a powered hub on this so it isn't any peripheral load. In fact, I'd expect the powered hub to add some 5 VDC to the USB power buss.

    For now I'm just going to ignore it as everything is working. Some time later I'll compare this PSU to others I've got.

    I'm fairly comfortable that the upgrade ran right, and things generally look good.

    The one BIG open question is just when (if ever) Slackware cuts over to the "New! Improved! Forced incompatible! ext4 and has this upgrade made the Slackware Pi no longer suited for making backups?

    Overall, I'm quie happy with Slackware, once past the first use teething.

    I'm going to proceed with putting it on any other Armbian Only boards I've got. When that is done, then I'll worry about a Gentoo test case for whatever is leftover.

  27. E.M.Smith says:

    Back on the Rock64:

    The “new” Fire Fox takes a long time to start up. I’m not thrilled with what the Fire Fox Developers are doing to it in terms of sloth.

    I’ve also had to re-do the ntp / time settings as my upgrade choice set aside my config files for the ones in the package.

    Video Compositing is not fixed on this board. Dragging a window still has some jitters. This is an issue of the kernel developers not having full support for the GPU yet, I think. Or Slackware has not incorporated that newer code yet.

    All in all it is still quite livable. I’d rather this set of minor cosmetic / comfort issues than the level of instability, annoyance and uncertainty SystemD brings.

    Sometime later I’ll try installing Chromium and see if it is snapper like the old FireFox was. Otherwise I’m going to back rev it if I can.

  28. p.g.sharrow says:

    I would suspect that using that mini-usb connector as the power input point is the inrush limiting point that triggers the low voltage warning. Raspberry Pi warns that that connector is the only safe power input point. I wouldn’t worry about intermittent flashing of that that just means the inrush protection circuit is doing It’s job. They also caution about using the USB connections for powering devices…pg

  29. E.M.Smith says:

    I’m not contemplating sending all power through “alternate means”, just some stabilizing buffer. But most likely I’ll just be too lazy to bother (or when I swap to another PSU I’ll find that the supposedly 2.5 A one I’m using now, isn’t…)

    Most likely sloth will prevail…

  30. E.M.Smith says:

    Well, sloth lost and fidgeting won ;-)

    While waiting for something else to complete, I was tracing a wire through the rats nest of my desktop and it went to a mostly “Off” Orange Pi One. A VERY small board with minimal power needs. It was a 3 amp supply with a micro-USB to round converter on the end… So I swapped it with the Raspberry Pi “LuvR Pi” nominally 2.5 A PSU.

    No more rainbows…

    Either the Pi is really taking a surge over 2.5 A or the LuvR Pi PSU is fibbiing…

    But I don’t care. I’ll just stick it on a lighter demand board where it will be more than enough.

  31. E.M.Smith says:

    At close of shop today, I have acceptable and current versions of Slackware running on:

    Raspberry Pi

    And I have a downloaded image for Orange Pi One.

    The problematic boards look to be the Odroid C1, C2, XU4, and N2. This is because Odroid do a complicated boot loader process in a bag-o-bits at the start of the uSD that is not a partition, plus they use a signing key. It looks like the way people make it go it to graft the userland onto someone else’s kernal and signing…

    I plan to just leave them Armbian for a while. Then, if I’m forced to work at that low a level, try a Gentoo port instesd.

    In the next couple of days, I’ll try Slackware on the Orange Pi One.

    Assuming it works, the only systemd stuff left will be the Odroids. Which is a bit of a bother ss they are my favorite hardware. I’m pretty sure I can get Devuan working on the XU4, so that’s promising. We’ll see though.

  32. E.M.Smith says:

    Preparatory to trying an install of Slackware on my 2nd Orange Pi One, I took it from the box on the shelf and tried to boot it up. Black Screen. That Dead To Me Look.

    Remembering that we’d seen this a half dozen times before, I thought, maybe, it was just fstab with disks that were not plugged in… So I put the uSD card in another system. Sure enough, that same old thing where if the disk is not physically present, it looks like your system died and simply will not boot with zero indication of why. (My “Monster” USB Stick died a year+ ago but still had a mount line in fstab… I’ve not used this one in a while ;-)

    Thanks again, SystemD (mented)! /sarc;

    A few # commented out lines later, it booted fine.

    I’m now typing this from the Chromium browser on the Orange Pi One.

    Interesting to note that memory used is only 277 MB out of 500 with the browser, one tab, this one, open; htop running, and one terminal window open. Way more efficient memory use than the other SBCs. (This is on Armbian xfce from a while ago. Ubuntu Xenial release.)

    It is actually a livable system, despite the memory size and the incredibly cheap price. I’d put one of the small heat sinks on it (of the kind commonly used with the R.Pi M2 & M3 about 2 cm square) and it is still hot to the touch with about 50% CPU usage. The O.Pi is a very fast H3 processor, but like many, hobbled by lousy / no heat removal.

    Were I doing this over I’d likely get a better heat sink.

    There you have it: ANOTHER system that looked to be a dead board entirely because the Ubuntu SystemD doesn’t play well with fstab that has an entry in it for a disk that is not plugged in. Even a disk that is not used in any way for booting or the home directory. Oh Well. (The reason I’m eliminating all Ubuntu from my shop, and as much Armbian-non-Ubuntu as I can also).

    With that, I can now properly name the new backup copy of this uSD (since I’m now reminded just what it is…) and can proceed to flash a Slackware onto it. The image I’ve got may be CLI only. The Gentoo image declares it is CLI only and this Slackware is about the same vintage / size. I don’t know if it an upgrade / add new will jump it up to a higher level of completion, it is a community image so unless someone built the bits…

    BTW, I did an upgrade / update-all on the RockPro64 Slackware (having un-commented the Bulgarian site) and now it doesn’t even try to boot… Not entirely unexpected as i was just doing a shot in the dark with a generic repository on a very new build for a very new board; but I also, now, need to restore that image from backups…

    The general impression I’ve gotten is that if a Slackware image has been around for a year or two, and especially if it is one of the official builds, it works great. If it is new and some guy’s “roll ‘ur own”, it works fine UNTIL you try the “usual upgrade” and then it breaks as the Official Repositories don’t have what it take to make that system “go”.

    So I’m going to “fall back” to the basic install of Slackware on the RockPro64 and just leave it at that level until it is a more officially supported board, or I need something it just can’t do and then I’ll deal with the upgrade stuff again.

    This Orange Pi test will be partly to see that status and partly to evaluate, IF it is CLI only, is it suitable for a headless server (i.e. replacing my Armbian nfs server). Even if it is CLI only, that would be one less SystemD board running…

    Back in a while… I hope ;-)

  33. E.M.Smith says:

    The install of the Community Image of Slackware on the Orange Pi went fine, and in fact gave a nice CLI install of 14.1 release level.

    I then went into /etc/slackpkg/mirrors and uncommented the ftp line in the 14.1 block and did a “slackpkg update” and “slackpkg install new” that both worked Just Fine.

    Based on that welling confidance, I then did a “slackpkg upgrade-all” which promptly screwed up the whole system. Gives kernel errors at boot time… couldn’t find either halt or shutdown commands after the upgrade so had to powerfail it to get it turned off. I doubt that was why it then would not boot.

    Lessons Learned:

    Much like the RockPro64 where it, too, ahd a fine Community Image that blew up on an update cycle: The Community Images are fragile things that do not play well with the gneral ARM or arm64 package repositories. Don’t do an upgrade wholesale. At most, do one package at a time as needed. Most likely one needs to avoid touching the kernel and only touch userland.

    So I’m going to restore the Armbian image (for now) and play with it as a Daily Driver Desktop for a little bit (dd happening now ;-). Then, some time next week, I’ll likely try the Gentoo image just to get my beak wet ;-)

    IMHO this is just a very clear indicator of you “community matters”. The Orange Pi One never collected much of a community due to the small memory size (even though proper compile flags can made that quite enough memory, as evidence the Armbian biuld from earlier). Folks just don’t want to toss $10 to $15 at it and figure it is not going to work. In fact, it works fine with properly ported OS images.

    But there just aren’t enougn of them to make a big enough community of interest for the big developers to make formal images for it much beyond the vendor image. There are some others, but all “with systemd”…

    Similarly the RockPro64 is just too new to have a lot of ports finished and debugged. Give it 6 months and that will change. So, for it, I’ll just either restore the Armbian or the Slackware 14.2 and just live with it for 6 months to a year, then try again.

    For the Orange Pi One, I’m still likely to re-install the CLI 14.1 Slackware and use it as a general purpose server / spool / whatever board. Hopefully, over time, more folks will use Slackware or Gentoo on it and things will get more mainsteam.

    I could easily see just leaving it “as is” for a year or so and then chekcing in again. This particlar Armbian is fairly nice and efficent on it, and I’m running a comfortable desktop. It doesn’t need a lot of stuff like databases and compilers and all. It would make a nice, dedicated, special purpose browser system where I want isolated traffic, exposure, and identity…

    Well,, the “dd” finisned so I’m off to re-boot the O.Pi One as Armbian again…

  34. p.g.sharrow says:

    I don’t know about this. Sounds to me like there will be a lot of orphans out there.
    Unless you want to adopt one? Avoiding systemD sounds like a good thing but it will break a lot of possible applications that look for the systemD hooks to call for services from the OS. App developers are really pushing this to make their lives easier when developing new applications…pg

  35. E.M.Smith says:

    Yes, SystemD IS also screwing with the developers as now they must support TWO paradigms… But many already support multiple paradigms in that they run on BSD as well.

    But in fact that is one of my complaints about SystemD: IT SCREWS AROUND IN TOO MANY PLACES. The app developer ought never need to know what init process started the system…

    So, will some app developers throw in the towel and ONLY do SystemD? Some will. Like Gnome desktop. Others, like my preferred LXDE / LXQT / XFCE won’t as they are widely used on systems like BSD.

    Essentially the developer will need to “blow off” the (now) 79+ distributions of Linux that are not doing SystemD AND all the BSD users, or find a way to not be utterly dependent on SystemD but use it at arms length if available.

    That is a very large community to blow off…

    And for any application that does that, there’s good odds that someone will make a non-SystemD fork of it and carry on. (which is another ding on SystemD in that the added workload from folks forking projects that otherwise would not need it is all their fault).

    The BSD folks are NOT just going to go away, so the demand for apps will remain, so the supply will exist. Plus, as ever more distributions pop up that are running screaming from SystemD, the demand grows. Every year more distributions look to Devuan as their upstream. It is growing, not shrinking.

    That the Slackware ports to the Orange Pi One and RockPro64 are relatively new and fragile is in the normal way of things. That is unrelated to SystemD, and only a function of the board being new with a new chipset (Pro64) or not that widely used in the circles that want Slackware (OPi).

    Do I KNOW that Devuan will “win”? Nope. But I do know that the guys who were willing to pack up and leave Debian to make it are not going to change their minds, nor am I. I also know that I’ve had a LOT of “sand in the teeth” from SystemD and that running Slackware and Devuan has been a very nice experience…

    Frankly, I’ll abandon Linux and go to BSD before I embrace SystemD. I may use a SystemD based distribution from time to time if it is what works, but I’ll never embrace it as a good thing nor prefer it. The core concepts of it are broken and the implementation sucks.

    So, as of now, I’m SystemD-Free on 8 computers (as is the spousal Mac) and can be SystemD free on 3 more fairly easily. That leaves just the Odroids that need some work to make it happen. Even there, it is possible to get BSD easily and other Linux with some work (match the userland to an already signed bootloader / kernel).

    Inside 6 months I ought to be down to none required. Though I may still run some as desired. Like right now I’m running Debian Stretch on the Orange Pi to type this. It is an interesting test of the minimum system that’s usable. It actually IS usable. A little bit slow at times, but no worse than a Raspberry Pi M2 or M3. It NEEDS swap space. I have 281 MB on swap with 6 tabs open… but as I already have hard disks with swap partitions, plugging one into the USB hub is SOP anyway.

    So while I’m happy to do things like run this test of a standard tuned Armbian / Debian on it, I’m also most likely going to run the CLI Slackware for the NFS server on it. Might as well since it runs headless anyway and as a “one job” server doesn’t need a GUI. Then I won’t have to worry that it might not boot if some disk was unmounted and removed….

    The places where it will be problematic will be edge case SBCs. Small and less popular boards where the intersection of the small Community using that SBC and the modest community of Traditional Init users is a very small overlap. Places like the Orange Pi One. Looks like one guy made the port, and I’m playing with it (and maybe a dozen or three others who are not talking about it). For mainline SBCs / Desktops (like Intel based, AMD based, Raspberry Pi, etc) they will get every OS ported anyway.

    For the smaller makers it will depend on the interest at the manufacturer in supporting the ports (Pine has a LOT more ports than Odroid for all types) and the size / interests of their customer community. There will also be a tendency for Traditional Init folks to focus buying on only those SBCs that have it. I’ll not be buying any new computer that is obligatory SystemD Distribution only. It’s now a check box for me…

    Is it guaranteed that SysV Init and OpenRC will survive? Nothing is guaranteed; but I’d bet hard money there’s a big enough community of us to make it happen.

    Slackware never saw the utility in System V Init in the ’80s, so I can’t see them deciding to jump on SystemD with all the crap it brings. As THE oldest distribution still running, with a large community, I’m not seeing them shrinking. They just gained a new user in me. I think there will be more over time, not less.

    Void is a new up-and-comer using MUSL libraries and other cool stuff. They are doing OpenRC. That’s a growing space, not shrinking.

    I’ll preferably use BSD for back room servers in any managed shop. I’m not alone… There’s a huge block of BSD users that will NOT change. You want security? Use BSD.

    The Mac is based on a BSD fork… So if you want your application to be in the Mac world, you must have a non-SystemD version.

    etc. etc.

    SystemD will dominate Red Hat (who forced it on all the downstream folks) and Debian (and their downstreams like Ubuntu). While that is a lot of the space, it isn’t all of it. Not even close. Then, as the Grief Factor hits folks, more of them will leave that space.

    The only reason I’m still running any of it is that Armbian has done a good job (so far) in blocking the Crap Bits and ports to all sorts of odd Arm boards. (Set the device name munging off by default, fixed the fstab bad interaction bug, etc) But they can’t keep patching around it forever. Eventually as the cancer grows they will either have to abandon it for Devuan as their upstream, or let it out of the cage.

    Basically all this Drama is what happens any time there’s some major shift in the Linux landscape and a load of FORKs happen as people chose sides. That’s why we have a few thousand distributions. Folks choose. That’s a good thing.

    Oh, one other to mention: Knoppix has said they are not doing SystemD. As that’s the standard portable system / emergency recovery disk, that’s a huge win for “our side”.

  36. E.M.Smith says:

    BTW, using the Orange Pi One as a desktop with a fat browser (using Chromium at the moment) provides interesting information about what matters to performance.

    1) At 512 MB (shows 461 MB with 235 MB as Zram swap) it is clearly short of memory in this use case. For a GUI desktop / Chromium you need at least 1 GB of memory. With lots of tabs open, 2 GB is better or you will need swap space.

    2) It occasionally bursts to all 4 cores and often is using them at near capacity. There is just a tiny bit of lag on some operations. The speed governor is set to 1.2 GHz, but “htop” only shows 1.01 GHz as the top speed. Don’t know if the display is in error of the actual speed limit is 1 GHz… In either case, it says about 1 GHz is “just barely enough” but livable. It also shows 4 cores at that speed is also necessary. The “floor” of usable is at about Raspberry Pi Model 2 level of performance. (With Debian. Ubuntu is slow and fat and would likely kill it…)

    3) Decent swap (a USB hard disk behind the Zram first tier) makes up for a LOT. I’m regularly overrunning the Zram and putting a few hundred MB on the hard disk. Yet it only shows up as minor lags when swapping tabs and a ‘reload from swap’ happens. Having a GB of Swap makes this system usable.

    4) For normal browser like stuff, the network speed is fine, and running all the USB gear through the one USB 2.0 spigot to a hub is just fine. IF you already have a hub, it’s a cheap $10-$15 computer that just works. If you DON’T have a hub, it’s a $40 package to buy so just buy a Raspberry Pi with 4 port hub built in for $35.

    5) For infrastructure tasks as a headless server, it is great. No GUI means lots of memory left over (as does no browser). I have an 8 TB disk on one of them and that disk has a 2 port hub built into it so can daisy chain other stuff off of it. As a powered disk it doesn’t draw USB power either. Works great. Monitoring the load on my time / DNS / Proxy server R. Pi shows it nearly nothing. I am sure all those functions could be placed on one of these little guys. I may do that just as an experiment in minimalism ;-)

    6) Being as physically small as it is, one of these could easily be made a portable “server”. So put a WiFi dongle in it and make it a portable hot spot interface. Essentially connect your laptop / tablet to it, then have it do the WiFi connection and connect to your VPN provider, and then your laptop treats it as a VPN spigot with all your traffic encrypted to the exit point and not even leaking things like time updates or DNS queries…

    It is just about the lowest performance / size I’d want to use; but it IS usable and I’m kind of fond of the little fella…

  37. E.M.Smith says:

    Hmmm…. Looks like ARM is now an officially supported architecture under Slackware, but only recently added, so it’s in -current (development) only:

    Slackware’s primary focus has always been the Intel distribution. However, ports to other architectures are now available in -current form. This means that they are undergoing the same heavy development that the Intel -current tree experiences. The goal of the Slackware ports is to imitate the user experience of the Intel distribution as closely as possible. This means that the ports will attempt to include all of the same software, configuration scripts, and so forth.

    Slackware has been ported to the following other architectures (with links to port-specific pages):


    So, OK, that makes for a much more promising future for it.

    Over time, the Community ports will become Official Supported. Nice.

    BTW, ATM I’m on the RockPro64 under Slackware (again) having restored the last image from just before my botched update attempt.

    Now I’m going to do what I probably ought to have done before:

    1) Learn how to upgrade individual packages instead of “upgrade-all”
    2) Figure out how to pick a proper mirror / repository instead of dart tossing at whatever is in the mirrors file be it right or wrong…

    FWIW, as it comes from the wrapper this Slackware image is fairly complete. Has Firefox already installed. It is missing OpenOffice & Gimp and I’d like to add those along with Chromium, but it is usable as-is for about 75% of “what I do”. Once I get the whole mirrors / repository thing figured out I’ll likely be able to add packages as desired. ( I can already do that on the Rock64 and R.Pi Slackware installs).

    So, for now, the RockPro64 is displacing the XU4 as my Big Iron Daily Driver.

    The XU4 had been my favored machine for a couple of years now. Fast. Silent. Running an Armbian Jessie uplifted to Devuan. BUT Armbian has obsoleted Jessie and when I tried the Devuan 2.0 install, it didn’t go. So I’d just moved to a plain Armbian as a “patch” around the issue (systemD and all..). Now I can get back on relatively Big Iron free of SystemD (mented) again ;-)

    This also means I don’t need to keep the XU4 in a workable state, so I’m more free to work on that Devuan port and see if I can make a go of it. First I’m going to try just a tarball of the userland over the existing Armbian kernel. That ought to work. Then I’ll back off one level to trying to figure out what it was a no-go in the first place.

    It is very possible that some of my “failure to launch” experiences have been due to the image having an “original format ext4” and my workstation writing the images having “new ext4” and so doing that automatic conversion on the file system (thus making it broken for booting on an old ext4 kernel…) Why it is a stupid idea to have change of file system incompatibly in place, reason number 200,323,487 …

    For a little while now I’m going to be slowing on the Slackware porting front. I’m just going to use it As Is for a while and get some stuff done. Swapping to the Rock64 if I need some software not on the RockPro64 already (as the Rock64 correctly updated / used the repository).

    I hope to get the XU4 running on Devuan 2.0 in the next few weeks, but other than that, the OS Maintenance front activities will slow down, since I’ve basically got a 90% solution in place. Doing a Gentoo port to either the Orange Pi One or the Pine A64 SBCs is a low priority “for fun” activity so not high on the priority queue. A “maybe next month” kind of thing…

    Overall, I’m quite happy with Slackware on the R. Pi and the Rock64. The RockPro64 only needs the repository / upgrade bit worked out. So Slackware + Devuan covers pretty much everything other than the Odroid C1 / C2 / N2 and for GUI the Orange Pi One (but its general use doesn’t use a gui anyway… so Slackware CLI is fine there…). That’s more than enough hardware to keep me busy ;-)

    IF I run into any new bits, I’ll add a comment here, but mostly it will be accidental discoveries not the result of a directed search…

    FWIW I’m thinking that since the Rock64 is also aarch64 I can likely use whatever repository is in the /etc/slackpkg/mirrors file on it, for the RockPro64; BUT I need to learn how to upgrade userland without touching the kernel / DTB / boot stuff… I may try that next week…

    For now I’m going back to “more using /. less sys prog work”…

  38. E.M.Smith says:

    They say their officially supported devices is a small list but that more work:

    Officially Supported Hardware
    Development branch (“current”) Hardware ARMv7-a
    Trimslice Pro, Banana Pi (Original & Pro), OrangePi v1.2/Plus/Plus 2E/PC

    Bold bits by me…

    Out of the box, Slackware ARM officially supports a small number of systems.

    Unlike the x86, usually each type of ARM device requires development and maintenance of installation documentation and in some cases custom kernels. Please see the ARM architecture reading materials for more information.

    Slackware ARM aims to fulfill the following requirement: Provide official support for some commonly available hardware, and allow the community to support “device du jour”. So even on an “unsupported” ARM device, the majority (if not all) Slackware ARM packages will run on the device, you will need a specific Linux kernel for your device.

    So there you go. “My Bad” for just tossing the RockPro64 at mirror and saying “change everything”…

    So after I figure out how to do the upgrade of userland and NOT the kernel, I’m likely golden…

    This also confirms the idea of just harvesting an Armbian kernel boot / build and laying the desired userland on top of it, for the Slackware port or for Devuan on Odroids…

    It also looks like searching for “overlay” will be useful. I saw one of these for the Orange Pi but didn’t know what it was at the time:

    Distinctions between Community Supported Devices and Officially supported devices

    A community supported device is essentially an “overlay” to the Slackware ARM tree, and typically conforms to the following rules:
    Instructions and packages:

    • Provides its own installation instructions
    • Provides its own Kernel package(s)
    • May (if applicable to the particular ARM device) provide its own Slackware Installer image, or provide a modified “miniroot”
    • May provide additional packages specifically required to present a full Slackware experience (examples include graphics drivers and supporting libraries for those, but not anything else that isn’t absolutely essential to the operation of the target hardware)
    • May provide replacements of a very small number of Slackware ARM base packages in the case where there are some build-time changes required that cannot be incorporated into the official packages.

    So most likely I just need to find if an “overlay” exists for my device, where to get it and how to install it. (Or make one myself…) I think. Maybe… ;-)

    But not, I think, today ;-)

    Today the sun is shining the dogs are barking and the garden is asking for my presence… enough in the dark keyboard time last week ;-)

  39. E.M.Smith says:

    Just parking a couple of URLs here so I can close the windows & not worry if I bookmarked them on some other chip…

    Discussion of variety OS types on the Orange Pi One:

    The repositories for images it points at (a bit hard to find on the page as it is only two words in color in a sea of other colored words that are bigger and NOT links…)!wh8l2BjK!OBep3nMldBletvNNwkH2Jg

    Only the Mega site has the Genoo image. Both have Slackware (CLI only).

    Also, it looks like Slackware might have their own definitive mirrors:

    These are for the 64 bit INTEL / AMD x86 type chips:

  40. E.M.Smith says:

    I added this line to the bottom of my /etc/slackpkg/mirrors file:

    On the RockPro64. I did the “slackpkg update” and “slackpkg install-new” without incident. Then, to test installing a package, looked at:
    to see what packages exist.

    Doing “slackpkg install gimp” seems to have worked, but the menu item is not launching the program. So I’m going to log out / back in to see if the name just isn’t in the path cache…

    I think that’s the right mirror and the right command… but…

  41. E.M.Smith says:

    Just a minor note on Gentoo:

    I found a prebuilt image for the Pine64 A64 board. It installs nicely and runs, no GUI, but it can’t update as python and portage are too out of date to update themselves.

    There may well be some convoluted way out of this EABI 6 vs 7 deadlock, but it isn’t obvious.

    The key point here is that Gentoo expects to stay fairly close to current or you can end in a deadlock. As I often let a system sit for a year or two, I need to be aware of that.

    So looking to install a prebuilt image more than a year or two old is a poor strategy. Which means not a reliable shortcut to the usual “build it all from source”… Drat.

  42. E.M.Smith says:

    Well that was fun…NOT!

    I did get Devuan 2.0 to boot on the XU4. However, it was CLI only and eth0 was not found…

    Process was dodgy too.

    I tried straight install again and again it was a nogo. So put Armbian on the chip, shrunk it to half, made a second partition, put Devuan userland on it from a tarball. Edited boot.ini in the first partition to point at the second, and it booted.

    Don’t know if the Armbian kernel has a compat. problem, if the DTB wasn’t picked up, if eth0 just screwed up in Devuan 2.0
    As it’s a bastard mix, who knows.

    Good news is it shows the userland works, so a roll my own uboot ought to fix it. The bad news is I’ve never built a uboot. If might be as simple as just dumping the tarball in mmcblk1p1 and not having Armbian bits involved.

    Whatever. It is late and I think I’ll pick this up again tomorrow…

  43. E.M.Smith says:

    So, on Devuan, I swapped it to the first partition in the hope the boot loader would pick up that kernel and device tree. Didn’t even get to the “blinky blue light” CPU running stage… So decided to just do EXACTLY what the Gentoo on XU4 page said to do:

    I’m beginning to get a bad feeling about Gentoo….

    Even validating along the way that I had THE newest tarball and the right portage bundle download.

    I did put it on a USB hard disk partition instead of a uSD card partition just to make things go faster and reduce SD wear (this is what I did on my prior R.Pi install about 2016 and it worked fine).

    Everything worked fine up through the chroot. I did put some of the commands in a little script so that I’d not have to type them more than once:

    root@odroidxu4:/SG2/ext/SysImages/OdroidXU4/Pristine# bcat chrit
    mount -t proc none /SG5/Groot/proc
    mount --rbind /sys /SG5/Groot/sys
    mount --rbind /dev /SG5/Groot/dev
    cp -L /etc/resolv.conf /SG5/Groot

    You will note this differs from the wiki page by /mnt being /SG5/Groot as that’s where the disk is mounted.

    Al good, right?

    So I download and un-tar the portage bundle and proceed through the steps to:

    odroidxu4 /usr # emerge --sync
    >>> Syncing repository 'gentoo' into '/usr/portage'...
     * Using keys from /usr/share/openpgp-keys/gentoo-release.asc
     * Refreshing keys from keyserver ...OpenPGP keyring refresh failed:
    gpg: refreshing 4 keys from hkps://
    gpg: keyserver refresh failed: No data
    OpenPGP keyring refresh failed:
    gpg: refreshing 4 keys from hkps://
    gpg: keyserver refresh failed: No data
    OpenPGP keyring refresh failed:
    gpg: refreshing 4 keys from hkps://
    gpg: keyserver refresh failed: No data

    Sync of the package repository is THE critical first step to updating / installing anything. It’s broke.
    says it’s a bug.
    Their suggested “work arounds” didn’t.

    So once again I’m at that “1/2 installed and their update process is broken” stage, but in a different breakage this time.

    Now I’m asking myself:

    Do I really want to be using a distribution that has THE core maintenance function, seemingly, so fragile that it is mostly broken? (That’s 2 for 2 broken so far, in different ways and for different reasons…). Just how reliable is this thing going to be? Or is it just a Hackers Paradise and not for any actual real use?

    So, with that, I’m dropping back to “Other Distributions” for a while. I mean, this is the most generic armv7 we’re talking about. Not even the aarch64 / armv8 oddities to deal with. Most recent Stage 3 Tarball (supposedly).. and even THAT doesn’t work? Really?


    So with that I’m done fooling around with Gentoo for a while. Effort will go back into Slackware on other boards. I’ve had good success so far with it coming up relatively easily on a couple of systems. I’d rather work on building the Slackware GUI environment on the Orange Pi One than fuss with a broken Gentoo portage.

    I don’t know what the issue is with Devuan 2.0 not wanting to boot, but that’s for “later” as well. IFF the Devuan folks ever publish an image that works, I’ll use it. For now it’s “a piece of work needing something” and set aside. I may, later, if interested, maybe, try putting the tarball of 2.0 on a booting 1.0 image (and see if the boot loader working works with it…). I’m also thinking I might try the Funtoo image on the XU4. The guy who started Gentoo “moved on” to make Funtoo (very similar but with changes like using git) and I suppose it is possible that his stuff works and the Gentoo folks are not doing as well without him.

    But for now, It’s time to go do something else.

    My time budget for “screwing around with broken Gentoo installs” is all used up…

    Status Summary:

    SBC           Working non-SystemD O/S
    R.Pi M2 & M3  Devuan, Slackware, 2016 Gentoo
    Rock64        Slackware
    RockPro64     Slackware
    PC            Devuan, Slackware too I'm sure, along with others.
    Orange Pi One Slackware CLI only
    Pine 64 A64   Not working yet, only tried Gentoo, it failed
    Odroids  C1, C2, XU4, N2  
                  Nothing yet...  Has a painful to work with uboot / signing issues

    I’d like to get the XU4 converted to something. I do have the old Devuan 1.0 uplift to Armbian working, but the package repository is now obsoleted, so SOL / EOL.

    I’m pretty much “good to go” on just making Slackware the main Daily Driver on the Pine products (Rock64 / RockPro64) and letting the other boards be fallow for a while. With the Raspberry Pi batch ( 5 SBCs) and the PC + Rock products, that’s a total of 8 computers and more than enough compute power for what I generally need.

    While I really like the Odroid hardware best, if it just isn’t possible to run it without SystemD or a very painful software installation process (or an unreliable and unstable one as Gentoo looks to be at this point), well, they can be for Special Things Only… i.e. sit in the parts box and be used when only they + Armbian do something I need done. While they wait for a working Devuan port, or Gentoo to get there Portage Act Together.

    With that, I’m likely done on this particular dive into porting land. Only possibles are a Funtoo install on the XU4 or maybe another quick look for Slackware on the C1, C2 and Pine64 A64. The N2 is going to stay an Armbian Media Station for at least a year (Armbian has better GPU support at present) so is “done for a while”.

    IF I get Funtoo working, or a new install of Slackware on the other boards, that will be a new posting. For now, it’s time to get back to the ROW (Rest Of World) and check in on current affairs / temperature data status / database build on RockPro64 Slackware and other infrastructure stuff.

  44. E.M.Smith says:

    Just a short FYI about likely to come:

    While waiting for dinner to cook, I tried a Funtoo install on the XU4. It followed the guide and seems to be working, so far. Unfortunately, no network at the moment so that needs fixing before I csn test the emerge / portage stuff.

    More importantly, it walks you through swapping an Ubuntu to be a Funtoo. I think I can folliw the same procedure to boot the Devuan tarball image. But that will be later or tomorrow…

  45. E.M.Smith says:

    Some mornings the coffee just doesn’t soak in fast enough…

    I booted up the Rock64, and proceeded to spend about an hour trying to shut off ipv6 and get it to use ipv4. My whole lab network is retro IP v 4 and not a v6 router to be found in it. This SBC that had worked fine, now was stubbornly not getting an ipv4 address and was getting a default ipv6 from somewhere…

    Well, I’ve found a half dozen ways to “shut off ipv6” (none of which work anymore) and I’ve found that there is an RFC demanding that everyone use IPv6 Or Else… so turning it off will get harder over time. Then I found the peculiar spot where Slackware sets your interface address at boot time (/etc/rc.d/rc.inet1.conf) and set it to a hard coded ipv4 address…. and it got that address and it STILL wasn’t talking to the router…

    And that was when I noticed the little yellow link light was not lit up on the Rock64…

    I’d stuffed the cable in, but not “clicked it home”. Shove, Click, Light, network working…..

    I think maybe I need to finish my coffee before I start typing… Now about that 2nd cup…

    (I’ve never been a “morning person” and this illustrates why. What’s the point of an hour earlier start if it sucks down 2 hours of WT? puzzlement as the brain slowly boots up…)

  46. Larry Ledwick says:

    Just out of curiosity since you like to keep old hardware alive if it is use able, and are playing with slackware, have you tinkered with puppy (which is now built on slackware) for your smaller systems?

    It is intended to be light weight and run well on smaller systems

  47. E.M.Smith says:

    I have Puppy and I’ve used it from time to time. Mostly just for the familiarity. IIRC you can base it off of several distributions if you desire. (Woof builds? Something like that).

    I’m not real keen on their very hand holdy menu driven systems admin method. It works and is nice for novices, but reading a page of stuff and checking boxes when I could just type “apt-get install chromium” is not as fast as I like…

    I have thought of using their “make a system / appliance for FOO” feature, though. Want a NAS? Just click the NAS button…

    FWIW, I’m slowly deprecating my Mac and Wintel / Intel boxes in favor of SBCs. The Mac has a recoverable but lethal failure (power brick connector broken) and I’m just not motivated to replace that when it was already running off of a uSD (as the SSD had died). Then the Chrombox got cranky and sporadic, so is in the “Put Linux on me” pile (for AFTER I pick the best current direction). My 2 Desktop PCs (recent as in Pentium 4 and some AMD 64 bit single core) are now slower than my 3 rd fastest SBC… and the old White Box PCs are basically not good for much but booting… x486 to Pentium 2 range and about 64 to 128 MB of memory) I’ve not used any but the Evo in the last several years, and even the EVO was only booted about 2 hours tops this year.

    Oh, and I like more of a crisp fine lines pastel kind of look, where Puppy like a stronger color, curvy crayola look… Not a big thing, but a comfort thing. Then the constant “cutesy” dog references are annoying. I have enough synesthesia already without adding phantom dog barking and phantom foot licks when I’m trying to thing about computing… “Cutesy” and “Inside Joke” never did it for me on tech stuff. I’m already bothered enough by trying to remember if “Ascii” is newer or older than “Buster” and is “Bastard Beagle” or whatever the Ubuntu “two names same start letter cute” of “Curious Cat” the Ubuntu that was just released. Give me a 14.1 moving to 14.2 or 15.3 any day… (Like Devuan 2.0 or Debian 8).

    So Puppy has never gotten me all excited about it. Though I have used it and if it were the only SystemD Free choice, I’d use it.

Anything to say?

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.