More SystemD Bites On the A…?

Well, I’m not sure if these really are SystemD releated, or not. I can only note that nothing remotely like them happened on non-SystemD versions of the same Linux.

For a couple of obscure reasons, I’m presently running on a Debian Jessie image on the PiM3. Mostly that it has the less risky kernel and that I munged my Daily Driver in attempting to convert it to a non-SystemD (and need to recover it). So I did a ‘fall back’ to the old Daily Driver.

First off, I had a window running with “top” in it (as I always do) so I could keep tabs on system state and running programs. Every few seconds a ‘glance to the right’ shows system load, swap state, running program, etc. Everything from performance issues to someone trying to run something evil show up there. Yes, 99.999% of the time there’s nothing to see, but at least you get that warm fuzzy feeling ;-) OTOH, sometimes you get clue about system issues and on very rare occasions you can get “WTF is he doing on my box?” (mostly on the ‘honeypot’ machine used to attract / distract attackers from the real prize…)

So I was doing some very ordinary maintenance things, and issued a “du -ks *” in a directory. Just wanting to see how many GB were sucked down by which directories. Now du just counts up disk usage as blocks, or as kb or mb depending on the options. Partway into it, I realized I really didn’t want to traverse that whole TB scale disk and could get what I wanted from a subset search. (This is a common thing for me. Launch the ‘will work but sucks resources’ command then ponder a better way while it runs. IFF you come up with nothing, you have still made good time with the first command. IFF you come up with a better way, no real loss as the idle cycles would have been wasted anyway.)

I decided to kill off the blanket ‘du’ and issue a more focused one. “Kill -HUP pid” where the Process ID was picked up from that ‘top’ panel. Nothing happens. “Kill -9 pid”… Nothing happens. (In theory, at least, the -9 flag is the ‘unstoppable unblockable kill signal’… the irresistible force of death… but it met an immovable object of a runaway process.)

I try again. Nothing. I notice that the “du -ks” in ‘top’ is sucking down one whole core. Now a disk limited thing ought never go to 100% CPU unless you have astoundingly fast disks…

Long story short, every attempt to kill the process, even as root, and every attempt to ‘background’ it from that window (i.e. CTL-z) got nothing. Some new windows opened would hang on various attempts. Clearly we had that slow creeping hang-of-death seen before with systemD (where sending a null-message caused it to bollix up other things until the system ground to a halting crawl of pending processes…)

OK, having runaway processes is NOT new in Unix nor Linux land. But usually, at worst, you “kill -9” them and get a dead zombie process. (It still shows up as a pid entry, but not sucking resources). This was different. This was in a full spin lock 100% of CPU sucking vortex of suckage. NOTHING could kill it, and it was causing attempts to do so to hang some other windows.

I had to resort to the Microsoft Windows Way and reboot my machine… which couldn’t kill all processes and an eventual powerfail was applied.

Round Two

Today I booted Debian Jessie (nearly generic, plus my build script, plus some changes to fstab and my own account / home directory). The one I’ve used for months. Didn’t launch ‘top’, but just did a quick browser launch ( IceWeasel) 5 windows open on my blog (comments pending, edit an article, posts listing, SPAM queue, top page) and one to my WiFi router (showing who is logged into it as devices…) All bog standard what I always do. I proceeded to open another tab onto the YaCy P2P browser web site (as I’ve done before and done on other devices and have open right now on the tablet…) and it seems to be doing fine, I click on one of the other tabs while it loads, then click back and…


Mouse won’t move. Can’t open a new terminal window. NOTHING works. Looking at ‘blinky lights’ showed nothing coming from the internet (despite the browser saying it was downloading info from {somewhere} of an ordinary sort). CTL-C nothing CTL-D nothing CLT-Z nothing ESCAPE nothing, etc. etc.

Now I can’t say that was SystemD as I just don’t have any information. Just a hang. What I can say is that while I’ve had a browser hang before, I’ve not had it extend to the whole system. Then I can also add that we’ve got a couple of examples now where SystemD gets a bellyache and everything slowly freezes up. That argues for a potential ‘fast freeze’ scenario as possible.

I’m posting this from the same system, after a powerfail crash / reboot, so it is clearly a sporadic fail and not a specific repeatable thing; but it is also very clear to me that Debian Jessie (8.x with SystemD) is just not reliable and dependable, where Wheezy (7.x) was. What changed between them? A huge influx of SystemD changes.

I had been planning a quick test of the YaCy P2P search engine (Debian has packages for it, per the web site) but it looks like I’m back at “First get a non-SystemD reliable system install done.” as otherwise the test will be contaminated by whatever this crap is.


OK, for those interested in the earlier parts of this series, some links:

As a footnote / aside:

I had a Debian Wheezy RPi image run for about 2 years? straight with zero issues as my DNS server / misc services system. (Now updated to Alpine and left up for a few months straight as DNS, file server, Squid Proxy, Time server etc. etc. server with zero issues).

I have used a R.Pi since about 6 months after first ship on non-SystemD Debian, Fedora, Ubuntu, Puppy, and a few others with zero such “hang of death” problems. I think that is ample base case for the non-SystemD versions of Linux not suffering from whatever this is.

My Void and Alpine images (non-SystemD) have shown no such problems.

Circumstantial? Sure. But I’ve caught a whole lot of problems and perps based on circumstantial stuff, and you get a feel for what such evidence means…

To to me it looks like SystemD runs great, is fast, and does neat things; right up until it has a crummy little problem; then it can hang your entire system and you get to do things the Microsoft Way with a crash and burn then rebuild / recover…

Sorry, but that’s just NOT the Unix Way. Not going there.

I think I’ll go back to making Devuan work on the Pi… I’m already settled on Alpine as the services card OS, and VOID as a place to play / develop. But there’s a LOT of stuff in the Debian libraries / ports and it would be very nice to have them available on the Daily Driver.

AFTER I have something I can trust as the Daily Driver, then I’ll get back to playing with things like YaCy and such.

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.

16 Responses to More SystemD Bites On the A…?

  1. Larry Ledwick says:

    I hate it when that sort of thing happens out of the blue due to some inocuous action like accidently double stroking a key or trying to resize a window or something similar.

    I just had a thought in htop I know you can renice processes, not sure about top, but was thinking what would happen if you reniced the runaway process to lowest possible priority in the system? If it is hanging the system by chasing its tail would that give interrupts a chance?

    Also I assume you sent kill -9 to the runaway process did you try killing its parent process to see what would happen? Might still have a hung and orphaned process but there have been times I tried all sorts of things to get the system to pay attention to me, like disconnecting the mouse and then reconnecting it.

    No solutions just thoughts (since it came on a mouse click on a tab could also be a mouse driver or browser bug I would think)

  2. E.M.Smith says:


    Well, there are two different hangs, so first off, for the “du” one:

    As the parent process was my terminal window, I was reluctant to do that. Yes, I likely could have ‘reniced’ it, but that just slows down the rate of the rot. A nice “work around” while you get users off the system and grab emergency backups, but not much benefit when “it is just me” and I’m current…

    Yes, I did a “Kill -9” (as root…) and lots of other things. I really didn’t care that the thing had one core pegged at 100% (I wasn’t keeping the other three fully loaded with my browser and terminal windows), it was the way “trying things” would tend to lock up whatever was in THAT window… It just smelled of that same kind of decay seen when a blank message had been sent to the queue on systemD. That “something is scrogged and now every time some other process needs that service, it, too, will hang”.

    Best to get as clean a shutdown as you can before it hangs something critical in a bad state.

    The second was the browser:

    I had a complete lockout. Not a single thing I typed would do anything, nor would moving the mouse. There was a sporadic flicker of one of the lights (the green one?) on the PiM3, so it was doing something every few seconds, but otherwise, zero indications of life. Not much you can work with there.

    Had it been a critical system, I’d have booted up some other box and tried an SSH in to it and kill / restart from that. That was basically the only hope. That the base system was still alive enough for a remote login, and only my keyboard / mouse & display were totally locked. I chose not to do that as this is NOT in any way a critical system (on BerryBoot and I can ‘roll it back’ at boot time anytime I like to the last save point; just a Daily Driver and all “my stuff” lives on external media anyway). Quickest path to recovery was crash and restart (perhaps on a different chip or on a ‘reversion’ in BerryBoot).

    The key bit in all of this is just that the system HANGS. That happens and is expected in Microsoft land and the Blue Screen Of Death is a well known metaphor. In *Nix land, that is very very evil and very very rare. Usually you can recover just about anything in the way of a hung system if you have a terminal login and root ‘kill -9’ available. No longer… THAT’s the thing under my saddle… As ROOT I ought to have immediate kill power on a process. Only excuses are a kernel bug, really. (and lack of a login window in which to become root and issue the kill…) Now systemD is a shim between me as Admin and The System. IT is deciding which of my orders are valid and which to ignore. That, as they say, has consequences…

    So I’m off to try a simple clean Devuan install / upgrade. It kills the BerryBoot chips as the attempt to install the new kernel overwrites some of the special sauce in BerryBoot. (Yeah, I know, I could have read up on what it does and known that before blowing a chip or two… but it was faster this way with a simple dd restore available). This looks like decent guidance:

    Good discussion of the choices and motivations here:

    Nicely readable too.

    So that’s what I’m “up to” tonight. I’ve sorted out 5 chips from my archives that look like they are NOT BerryBoot, have a dd backup copy, and have a Wheezy on them. In Theory… I can just start from one of them and do the ‘upgrade to Devuan’. If not, I’ll blank one of them and do a complete fresh install.

    The one I’d like to do most is a 64 GB chip with all OS’s that were available at the time on it (17 real partitions!) from July 2015. It is unfortunately only bootable in the PiM2 not the M3, but maybe that’s OK… I’ll just swap out the M3 as my “desktop” for a little while and evaluate… but most likely I’ll just overwrite a mini-SD chip (class 10!) that has x86 Knoppix on it. I’m running Knoppix on the laptop from a USB stick now, so I’m not seeing the need for this one… and it has a dd copy on real disk…

    I’ve also got my old Daily Driver that was turned into the PXE boot server. It’s a direct boot chip too. But only a class 4 speed. Then there is the Alpine PiM2 chip without X running… Not really seeing the need as I’ve got a production version running on my Pi-Model-B+ and I’m not going to use it as a desktop anyway… but it’s a PNY Class 4, and as we saw before, the PNY folks do some kind of fast buffer in front of slow backing store, so it looks fast for a while, then slows way down on long transfers. Not that Class 4 is very fast even when going full speed…

    So that’s where I’m at. Just “moving on”… and I’ll likely be running on Devuan on some chip or other by the time I’m done with dinner… I’ve just “had it” with systemD mysteries, questions, and issues. Time to “get ‘er done” and be done. Once that’s clean, I can go back and “recover” a bunch of these chips as I’m NOT going to be running those OSs again (and have backup copies in the dd store anyway). I liked Devuan on the Evo, only thing wrong with it was a pernicious video driver issue with that Intel chipset that caused sporadic video hangs (and had not been fixed in all sorts of releases and was unlikely to ever be fixed for a decade old video chipset …) So I already know I like Devuan.

    With that, I’m back to “slaving over a hot computer” for the next hour or two until I’m slaving over a nice pizza making process ;-)

    (That naan bread, sauce, toppings, 400 F 8-10 minutes one… Yum! ;-)

  3. Larry Ledwick says:

    Hmmm the reason I was asking about the “try anything” non-standard things is I have seen similar hangs on our systems at work, a couple times a year, not common but it does happen from time to time that a system will just go stupid. This is on Centos and connecting via putty but same kind of thing, a process would even ignore Kill -9 even after waiting several minutes to see if it would eventually take.

    Just curious if a system you were directly connected to and hung like that would notice if the mouse was unplugged. Sometimes they would respond to very primitive commands like ping and ls but nothing else would work.

    In a couple cases the system got so wedged that if you tried to ssh to it from another terminal session, the connection would complete giving you a command prompt but it would turn that session into a zombie window too where nothing worked as soon as you tried to issue a command.

    It almost looked like it ran out of swap, but typically not a gradual onset, one moment the window is behaving normally and then it just goes catatonic and the only way to get the server back is the power button.

  4. E.M.Smith says:

    Well, it took a while (mostly as it was asking “keep this config file?” a bunch of times and I was not at the keyboard…) but in theory I’m now running Devuan on this particular chip.

    I tried the method from the first link, but while it did a nice update of Wheezy, it did not access any of the Devuan sites. (I suppose I ought to recheck whatever I put in that config file…) Then just following the directions here:

    did use the Devuan site / programs.

    No problems with the conversion and no issues so far (other than needing to be at the keyboard a bit more than I like to robotically answer “N” to not change the config file for some things I didn’t know I’d configed… or maybe I ought to have updated some of them and don’t know it…)

    At any rate, I’ll be using this “direct boot Wheezy updated to Devuan Jessie” as my Daily Driver for a while to see what I think of it.

    ATM the typing in the browser comment window has a tiny bit of character lag (typeahead) yet the CPU usage in the ‘top’ window isn’t at 100% (of one CPU) but down around 50% to 80% most of the time. Most likely just an IceApe issue.

    Noticed it wasn’t spell checking, and re-selected ‘English Dictionary’ (right click, select) and now that bit of typing lag is gone. I suspect it was trying to start spell check on each word, failing, and doing something… now it works without the lag.

    OK, so now I’ve got nothing ‘odd’ to note, yet. ;-)

    Since there are directions for putting a new OS onto a BerryBoot chip, I’m going to just copy the kernel and environment from this one (or maybe a future better one?) onto my BB chips. That ought to avoid the “upgrade and die” problem on BerryBoot…

    So I guess this is “one down and 20 to go” on my Debian to Devuan upgrades ;-)

  5. E.M.Smith says:

    Gee… I just installed FireFox, so I’ve got both Firefox and IceApe available (IceWeasel install actually installs FireFox…)

    Oh, and it looks like there are prebuilt Pi images for your choice of Pi1, PiM2 or PiM3 here:

    The Readme:

    devuan arm builds, beta2
    These are the images offered. I kindly ask of you to test them out and
    report all weirdness as an issue on
    Beaglebone Black owners, please email be if you wish to offer help with
    testing because I do not own the board myself.
    SHA256SUMS are signed with my GPG key:
    Login credentials are root:toor
    to see if there is anything you should know about a specific image.
    	Download the image you want.
    	Download the shasums.
    	Compare the shasums:
    	; sha256sum -c SHA256SUMS
    	; xz -dv name-of-image.xz
    	dd the raw image to a medium of your choice
    	; dd if=devuan_image.img of=/dev/sdX && sync

    Maybe I’ll drop $9 for a new chip and do that for the PiM3 ;-)

    The listing of available targets:

    README.txt                                         29-Nov-2016 15:32     841
    SHA256SUMS                                         29-Nov-2016 15:27    1366
    SHA256SUMS.asc                                     29-Nov-2016 15:27    2649
    devuan_jessie_1.0.0-beta2_arm64_raspi3.img.xz      12-Oct-2016 22:42    294M
    devuan_jessie_1.0.0-beta2_armel_raspi1.img.xz      13-Nov-2016 18:47    159M
    devuan_jessie_1.0.0-beta2_armhf_bananapi.img.xz    12-Oct-2016 20:08    268M
    devuan_jessie_1.0.0-beta2_armhf_bananapro.img.xz   12-Oct-2016 20:24    268M
    devuan_jessie_1.0.0-beta2_armhf_chromeacer.img.xz  12-Oct-2016 20:42    341M> 12-Oct-2016 20:58    342M
    devuan_jessie_1.0.0-beta2_armhf_cubieboard2.img.xz 12-Oct-2016 21:14    330M
    devuan_jessie_1.0.0-beta2_armhf_cubietruck.img.xz  12-Oct-2016 21:28    317M
    devuan_jessie_1.0.0-beta2_armhf_n900.img.xz        16-Oct-2016 20:20    122M
    devuan_jessie_1.0.0-beta2_armhf_odroidxu.img.xz    12-Oct-2016 22:53    261M
    devuan_jessie_1.0.0-beta2_armhf_ouya.img.xz        12-Oct-2016 21:58    135M
    devuan_jessie_1.0.0-beta2_armhf_raspi2.img.xz      12-Oct-2016 22:15    290M
  6. E.M.Smith says:

    Doing ‘startx’ (launching lxde) gives a popup error message that ‘console kit’ is unhappy about not being fed something it expected in terms of history? something like that.

    In any case, everything works fine so I don’t care if console kit is grumpy. (Don’t know if it a config change on my part or if not doing the ‘clean’ step of the procedure left something dangling… More later whenever I catch a clue…

    For now, I’m going to put the ARM64 image directly onto a 32 GB Samsung chip and see how it does in the PiM3. It ought to work well as the ARM64 qualifier in the name implies compiled with real 64 bit option, not just the compatibility 32 bit v7 option… I’ll know if it boots in the M3 and not in the M2… (part of why I’m using the Samsung chip – I only have two of them and one is in the tablet, so it will stand out in the pile…)

    Don’t know when I’ll get that done, since we start ‘festivities’ in about an hour. But “as time permits” I’ll do bits and make comments.

    As of know, I’m quite pleased with the Wheezy -> Devuan conversion running in a Pi M2 card. No systemD showing in ‘top’, feels ‘fast enough’ like a PiM2 ought, and not having any ‘odd behaviours’ so far (modulo the complaint by console kit. I never really liked console kit anyway… ;-)

    FireFox (nee IceWeasel) happily uses more than one core, so is faster than the old IceApe browser on this system. I’m using it by default.

    With that, I’m off to use this Devuan to bootstrap the other Devuan builds. First up, download that ARM64 image, unpack it, and stuff it on a chip. Then boot in the PiM3. If that works, the next you hear from me ought to be from that system…

  7. Frank Rowand says:

    A little late to give debug advice since you’ve moved on, but you might consider enabling magic SysRq (Documentation/sysrq). As long as interrupts are still being processed, this will give you the ability to do things like show stack traces of processes, show locks held (if the correct config option is enabled), show a backtrace for all active cpus, show memory info, dump tasks that are in an uninterruptable (blocked) state, sync filesystems, and reboot. You may also need to enable all SysRq commands before the system locks up with: ‘echo 1 >/proc/sys/kernel/sysrq’.

    This works best when you have a serial console because otherwise most of the output will scroll off the monitor.

    For a graphics console, you need to issue the magic SysRq commands in a text console (use (or other appropriate function key other than F7) to get a text console, then
    to get back to X11).

  8. Frank Rowand says:

    Looks like html interfered with my comment.

    For text console: ctrl-alt-F1
    To get back to X11: ctrl-alt-F7

  9. p.g.sharrow says:

    :-) be sure to festivate while you can! We can wait.

    Does this mean I should order up a PIM3? Got a 1-Tb Passport Ultra last week and a hub, a ScanDisk extreme SD plus 32GB chip and a USB3 64GB flash drive last week.
    This PiM2 works alright but is a bit under powered as a Internet Cruzer.
    Your complaint about your daily driver hanging up sounds like the same thing that happens to me. Lose all IO and sometimes the screen seems to be frozen. I think it is caused by auto refresh and too much eye candy. Happens generally while I’m away from the desk. But the XP does the same thing, at times while no internet browser is up and we are playing PC card games. Likely too much demand for on chip memory addresses. My WAG…pg

  10. E.M.Smith says:

    Well, I’m back, but not on the PiM3-Devuan…

    I did get Devuan to install onto a 32 GB Class 10 Samsung chip, and it boots nicely. Fast and clean.


    Getting there was a bit more sideways than I’d expected AND I’m still working on getting X to start up.

    Have I mentioned lately that I hate X configuring?….

    So first off, after the unpack ( unxz devuan…arm64…xz) and then the dd onto the chip (dd if=devuan…arm64…iso bs=10M of=/dev/sdd ) (though that last d might be a different letter on your system…) It does give you a working booting Devuan.

    It does NOT auto resize the partition… so my 32 GB chip got a 1.2 GB or so root partition. This I found out when doing a ‘quicky’ install of lxde and having it run out of disk.

    OK, the way around this was just to boot a different chip ( I used Debian Jessie … the shame ;-) and use gpartd to grow that partition. I did that, and added a swap partition (that you don’t need to do but I do it as I’m stuck in my old ways…)

    NOW you can boot it again, do a “apt-get update” then an “apt-get upgrade” then an “apt-get install lxde”, that doesn’t work as it complains about a couple of unresolved dependencies. (libcodex or some such libraries) that it doesn’t want to install as THEY have unresolved issues….

    So you do an “apt-get -f install” and those libraries get done, then back to that “apt-get install lxde” and then you think you are done… but a startlxde can’t find the monitor… so there’s some more work to do configuring X…


    Why does everyone always leave X to the end? And often not done.

    In any case, as I’m done with the first half of evening festivities, and the second half starts after dinner, I’m not going to whack on that chip any more tonight. (At least, not before everyone else is asleep ;-)

    But the good news is I have a working Devuan with X on the PiM2 via upgrade, and a working Devuan without X on the PiM3 (that complained also about some source.file entry maybe not right for ARM64?) that also works, but needs some TLC. Given that, I’m feeling pretty good about this path leading to success overall. The 64 bit build is clearly a younger build, and has a few more ‘issues’ to iron out, but nothing that looks horrible.

    IFF I get a round-tuit I’ll try a M3 compatible ARMhf build and see how it does in the M3 and M2…


    I never had that hang issue, even on the M2, prior to SystemD. Still don’t on the Wheezy (no SystemD) images… Just sayin…

    Per a M3: I’d say “Yes, get one”. It’s something like 80% faster? on benchmarks… Just a ‘very usable’ vs a “I can make do with it”. The Pi-M2 can become your services ‘box’, with all that loverly infrastructure stuff on it, and by offloading that stuff to it, everything else goes a bit faster too.

    I’m planning on 4 x Pi boards of various kinds as my basic “shop”. The Pi-1-B+ as my DMZ “box” doing all sorts of generic things (time, DNS, adblocks, intrusion detection, etc. etc.) and the 2 x M2 as “interior services”. One set up as PXE boot server for everything else I feel like booting, and generic file server. That also says it will be a DNS server and more (as PXE expects to do the DNS stuff…) to my private network. The two M2 will also have distcc on them so I can do distributed compiles and system builds and such. (One of them available for ‘variety uses’ when not building via a chip swap / reboot if desired). The M3 will be my basic desktop / terminal / interface to all the headless ones… In reality, only it needs to be Devuan. Equally as real, I want all three of them off of systemD…

    Under Linux, if you have swap configured (like putting 2 to 4 GB of that nice hard disk as a swap partition) you ought never have memory issues. At most a slow down as swapping picks up, but typically just idle stuff swaps out and active stuff is, well, active. Do be advised that some of the USB disks like to have a sleep if not active. The new Toshiba seems to do that. The Western Digital and Seagate seem to work with swap and without an unexpected sleep state causing problems… I have a 500 GB Seagate that works well for swap and it’s my default target, but I put a swap partition on all disks (and most thumb drives) just so it is there if I need it. Usually 2 GB, but sometimes only 1 GB or even 500 MB on smaller USB thumb drives. Yes, a ‘swap file’ works just as well, but like I said, I’m ‘old school’ about a swap partition…

  11. tom0mason says:

    Have a Merry Christmas and a happy and cool new year.

  12. E.M.Smith says:


    Happy New Year to you too!


    As I had a bit of trouble getting the link to the Pi Devuan how to upgrade to load, I’m pasting a copy of the text here. At the top level, they site has a ‘login page’ so it may be that you are not supposed to be able to read the page without logging in… Just in case, I’m putting the ‘what and how’ here too…


    Upgrade to devuan and minimalism
    Last edited by dev1fanboy a year ago

    WIP, Formatting and corrections need to be done.

    If you want to install Devuan without upgrading see this page.
    Quick start guide to upgrading to Devuan and configuring minimalism

    There has been some talk about minimalism in the Devuan community and some may just be wondering how to migrate to Devuan. This document describes how to migrate to Devuan and make the system more minimal.
    Migrating from Debian to Devuan

    You can upgrade to Devuan Jessie 1.0 from either Debian Wheezy or from Debian Jessie. For other branches (to or from) you are on your own for now, as I haven’t tested this. I recommend sticking with Jessie until after the stable release, as it will require a little more care to run testing (ascii) at the moment.

    First simply open a terminal and type:

    user@debian:~$ sudo -s

    Enter your user password.

    Or if sudo is not available:

    user@debian:~$ su

    Enter your root password.

    Now we can continue with the upgrade. You need to edit the sources.list configuration file so that apt will be getting packages only from the devuan mirror (there is just one for now):

    root@debian:~# nano /etc/apt/sources.list

    Comment out ALL current lines in your sources.list and add the Devuan mirror with the Jessie (stable) branch. This is roughly how it should look:

    #deb wheezy main

    deb jessie main

    Now we need to get the devuan keyring from the repoistory so we can authenticate packages:

    root@debian:~# apt-get update

    root@debian:~# apt-get install devuan-keyring

    Many people coming over to Devuan will be hoping to escape the web of systemd in the process – if this is your choice you need to specify your init system now before you proceed. I will be using sysvinit in this example as it is what I have tested – systemd init will be removed if present:

    root@debian:~# apt-get install sysvinit-core

    The base-files package will be installed automatically in the case of an upgrade from Debian Wheezy, but it has been reported that this package will need to be selected manually when upgrading from Jessie. Either way we can do this now:

    root@debian:~# apt-get install base-files

    Start the system upgrade with:

    root@debian:~# apt-get dist-upgrade

    Depending on your connection speed it could take a while, grab yourself a drink.

    Once finished you will be using Devuan GNU/Linux 1.

    Do some optional cleaning up:

    root@devuan:~# apt-get autoremove –purge

    root@devuan:~# apt-get autoclean

    The first command will remove any ‘orphaned’ dependencies from your previous install including unwanted configurations for those packages. I highly recommend this because it’s good security practice. The second command clears up all cached packages except for those that are installed on the running system, reclaiming a little disk space.

    Now you should simply reboot so that you are using the kernel shipped with Devuan:

    root@devuan:~# reboot

    If in the upgrade process gnome was removed do not panic, the reason for this is it depends on systemd and you have opted for sysvinit. The default desktop environment in Devuan is XFCE:

    root@devuan:~# apt-get install xfce4

    Check that you can start your desktop environment:

    root@devuan:~# su – username

    user@devuan:~$ startxfce4

    If it all works you can add a display manager safely for when you next reboot:

    root@devuan:~# apt-get install slim
    Configuring APT for minimalism

    Thanks to a tip given to me by fellow minimalist ‘TheFlash’ you will be able to debloat your system in a very neat way. This is completely optional and may be done either before or after the upgrade. We are going to configure apt to ignore all ‘recommended’ packages in Debian/Devuan as the majority of these often will not make sense to be there. There are some exceptions where recommends should definitely be installed and we will take care of this as well.

    First use an editor to make the necessary changes:

    root@devuan:~# nano /etc/apt/apt.conf.d/01lean

    Add the following lines:

    APT::Install-Suggests “0”;

    APT::Install-Recommends “0”;

    APT::AutoRemove::SuggestsImportant “false”;

    APT::AutoRemove::RecommendsImportant “false”;

    Press the Ctrl and X keys together to save and quit.

    Now we are going to retroactively remove all recommended packages, along with any suggests you may have pulled in. Adjust the above accordingly to your needs if you still want either suggests or recommends. Before proceeding we will protect the ca-certificates package from getting removed along with isc-dhcp-common if it is installed. The ca-certificates package contains ssl certificates from certificate authorities and naturally you will want this for any system where you will be using a browser (if you don’t know then you need it). The isc-dhcp-common package takes care of automatic network configuration via dhcp on boot (see man 5 interfaces), if you don’t know what this means then you need this package too.

    root@devuan:~# apt-get install ca-certificates isc-dhcp-common

    This will manually select these packages and they will now not be removed. If you are asked to configure the ca-certificates package by a dialog screen you should answer to always trust new certificates authorities to avoid having to manually select them.

    Now all that needs to be done is remove the packages we have opted out of:

    root@devuan:~# apt-get autoremove –purge

    The now ‘orphaned’ recommends and suggests will be retroactively removed, cutting away some fat. Unused configuration files for those packages will also be removed. Check the list of packages to be removed before proceeding and make notes of packages you are sure you want to keep so you can install them later (man apt-get for details).

    Some optional cleaning up:

    root@devuan:~# apt-get autoclean

    Unwanted archives will be removed from the package cache, if any.
    Removing dbus

    Sadly XFCE depends on dbus and so do many other packages, there will be several solutions to removing dbus but you may have to compromise a bit.

    A quick list of window managers that do not depend on dbus with suggestions from a couple of #debianfork regs:







    For a graphical browser I suggest iceweasel, you might also like:

    ‚Äč epiphany



    For example:

    root@devuan:~# apt-get install fluxbox bbkeys menu iceweasel

    root@devuan:~# apt-get purge dbus

    Check the list of packages to be purged carefully before proceeding to ensure you really want to do this.

    Login to your user account, set your WM in the xinit file and start the X server:

    root@devuan:~# su – username

    user@devuan:~$ echo “exec fluxbox” > .xinitrc

    user@devuan:~$ startx

    You can now login by the console each time at boot and type startx. Information on display managers will come later, for now you should do some research if you need this.

    In the process of removing dbus you might have noticed the gvfs package being removed which is used for USB automounting, this is expected as it depends on dbus. A simple alternative to USB auto-mounting is to put your user in the disk group and set the possible mount points in fstab. You will then be able to mount your USB disks with ease. Further information may appear here after a little research on the topic of auto-mounting and graphical file managers.

    root@devuan:~# adduser yourusername disk

    root@devuan:~# cp /etc/fstab /etc/fstab.backup

    root@devuan:~# nano /etc/fstab

    At the bottom of the fstab simply add the following:

    /dev/sdb1 /media/usb0 auto user,noauto 0 0

    /dev/sdc1 /media/usb1 auto user,noauto 0 0

    An important thing here is that ‘user’ mode is set as it allows your user to mount the disk where usually only root can do that. The ‘noauto’ option specifies the filesystem will not be mounted at boot. See man 5 fstab and man mount for more details.

    This is based on a single hard disk system. Your device nodes for mount points may be different, if so you will need to adapt this if /dev/sdb1 or /dev/sdc1 are already in use in the fstab. If everything is correct hit Ctrl and X together to save and exit.

    Now create the mountpoints:

    root@devuan:~# mkdir /media/usb0

    root@devuan:~# mkdir /media/usb1

    You should now plug in your usb drive(s) and test that it works:

    user@devuan:~$ mount /media/usb0

    user@devuan:~$ mount /media/usb1

    When done unmount:

    user@devuan:~$ umount /media/usb0

    user@devuan:~$ umount /media/usb1

    There you have it, a retro style Devuan install that wouldn’t be out of place before systemd, dbus and other madness became the trend for GNU/Linux.

    As you might have noticed It’s a very smooth upgrade to Devuan in the here and now, not much different if you simply upgraded your Debian system. With a little more work you can get a reasonably minimal system as well and remove dbus if you want to.

    Enjoy Devuan!
    This work is released under the Creative Commons Attribution-ShareAlike 4.0 International [CC BY-SA 4.0] license.
    All trademarks are the property of their respective owners.
    Please note that this work is provided “AS IS” and comes with absolutely NO warranty.

  13. E.M.Smith says:

    FWIW, I did another ‘apt-get update’ after the keyring install… it seemed to add more stuff.

  14. E.M.Smith says:

    OK, the ARM64 version of Devuan for the Pi is still a bit buggy. I’ve “moved on” (or moved back) to the ARMhf version.

    That is, I’m running the far more widely used armhf instruction set that is compatible with both the Model2 and the Model3 and not the arm64 instruction set (and word size) that has very few users and nearly no debugging since it’s a new verion for the Pi Model3.

    At present, I’m posting this from Firefox, on Devuan, on the Model3 and it seems fine.

    The procedure that looks best is:

    Install NOOBS onto a new mini-SD chip.
    download / install Debian Full at boot of that chip.
    upgrade to Devuan (via the process noted above including the reboot.

    I’m now ready to run my usual install-stuff-and-setup script and processes… By sometime tomorrow I ought to be fully settled in on Devuan. (Unless, of course, something icky happens…)

    I’ve been using it sporadically via another chip, and mostly on the Model 2, but since the M3 is my preferred desktop, this is a nice step forward for me.

    At this point, all 3 of my ‘in production’ Pi systems are NOT running systemD (yay!!!)

    Alpine on the Pi Model 1 B+ as DMZ services.
    Devuan on the Model2 interior services card.
    Devuan on the Model3 desktop / workstation card.

    (The 4th pi isn’t running it simply because I’m short one power supply and need to get this set humming before I need all 4 running at one time…)

    One nice side effect of this setup is that all three of the 2 x M2 and 1 x M3 will be using the armhf instruction set ( 32bit hardware floating point). This will make distributed computing / compiling a tiny bit easier as they are almost identical…

    With that, I’m back to setting up my new Devuan world (and hope to be done before nightfall… ;-)

  15. E.M.Smith says:

    Hmmm…. Had the “Dave Berry” page open (link in the New Year’s page) and FireFox was chewing something like one whole core on some constantly reloading video ad. Decided to shut off Javascript. Found that this version of FireFox doesn’t have a control for that; you must go into the about:config stuff, search for it, and toggle it (rt click) to off…

    During that looking around, when on the “content” tab under preferences, for the second time, the browser hung. OK….

    Well, now I’ve got Javascript turned off and CPU use with the same tabs is down to 21% when I’m typing; 3% to 5% when I’m not… We’ll see if the ‘hang’ behaviour goes away as well. I generally have run IceWeasel, but as of now installing it gets you FireFox instead ( I’m sure there’s some kind of story there…) and FireFox is not as privacy friendly…

    OK, I guess I need to figure out what browser is the best one on Devuan… (May need to install SeaMonkey from sources… we’ll see. It’s a very privacy oriented Mozilla based browser…)

    Well, with that, back to the fray…

  16. Pingback: Orange Pi – First Fire | Musings from the Chiefio

Comments are closed.