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:

https://wiki.pine64.org/index.php/ROCK64_Software_Release#Slackware

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 pine64.org
Direct download from pine64.uk
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
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# 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: http://slackpkg.org/
# Roberto F. Batista (aka PiterPunk) piterpunk@slackware.com
# Evaldo Gardenali (aka UdontKnow) evaldogardenali@fasternet.com.br
#
# END OF LEGAL NOTICE
#
#
# 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
#----------------------------------------------------------------
#cdrom://media/cdrom/
#
#----------------------------------------------------------------
# Local Directory
#----------------------------------------------------------------
#file://path/to/some/directory/
#
#----------------------------------------------------------------
# Local CD/DVD drive
#----------------------------------------------------------------
#cdrom://media/cdrom/
#
#----------------------------------------------------------------
# Local Directory
#----------------------------------------------------------------
#file://path/to/some/directory/
#
#----------------------------------------------------------------
# slarm64 AArch64 x.x
#----------------------------------------------------------------
#

#----------------------------------------------------------------
# slarm64 AArch64 current
#----------------------------------------------------------------
#http://mirrors.slackware.bg/slarm64/slarm64-current/
#
#http://dl.fail.pp.ua/slackware/slarm64-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?

https://en.wikipedia.org/wiki/List_of_Internet_top-level_domains#Country_code_top-level_domains

.bg 	 Bulgaria
[...]
.ua 	 Ukraine

OK…

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