Simple Bug, Or Yet Another SystemD Screwage?

I don’t really care enough to put the time in to sort it out. Suffice it to say “that should never happen”.

What it looks like is that “something” is hanging on to history of mounts for file systems and using that history, despite the /etc/fstab being changed. Now that’s exactly the kind of thing SystemD does. It “takes over” and does things “its way”, often holding its own configs or history. So my strongest suspicion is this is Yet Another SystemD Screwage. But I just don’t care anymore.

I’m on the RockPro64, having done a nice little update / upgrade cycle and about to test the MariaDB / Python / table legends again to see if the bug was fixed.

Along the way, decided to juice up swap space a little. I’m running straight Armbian Ubuntu (since this is a new board and I want minimal software complications while debugging things on it, so want to run a supported OS “unchanged”) and it is, of course, SystemD afflicted.

For who knows what odd reason, when they made the zram (compressed memory) swap space, they didn’t make it a round number of GB. It’s just a minor niggle, but having 1.97 GB of swap is a bother. (It looks like they chop out some memory for a compresses memory filesystem /tmp and log file space; and then size swap as 1/2 x available memory instead of phys memory, but who knows). Then having only 1/2 of physical memory size as swap is “not ideal”. So I added a 2 GB partition from a disk, and got the bright idea to make a swap FILE on the u_SD card that was always there (disk or not) and that rounded the swap up to an even GB size.

Great, it all worked. Let’s save that code off where I can copy it down to my other systems, if desired.

For this, I use a cheap USB Stick stuck into my Netgear interior lab router that shares it out (as Microsoft CIFS, not NFS, unfortunately) and can be mounted on any system I’ve got, Linux, Mac, MS, whatever.

I’d initially mounted the FAT32 partition as /Netgear and the ext3 partition as /Netgear2. Then decided that since I was going to use the ext 7 GB partition much more often than the 220 MB FAT32 partition, I’d swap those two names. That worked, but every time I did a “mount /Netgear”, it would mount the FAT32 partition as /Netgear then mount the ext3 partition over it. WT? I checked /etc/fstab. It was right. I tried several times and several things. No joy.

OK, I’ll just change it all. I made /Netgear/ms and /Netgear/ext in keeping with my usual Linux disk mount point naming conventions. Then mounted /Netgear/ext. It still did the double mount. OK, let’s have a reboot…

After the reboot:

root@rockpro64:/# tail -4 /etc/fstab

// /Netgear/ext cifs x-systemd.automount,guest,noperm,sec=ntlm 0 0
// /Netgear/ms cifs x-systemd.automount,guest,noperm,sec=ntlm 0 0

You can clearly see that it’s just the two mount points. ( I also did a “grep Netgear” on /etc/fstab just to be sure I didn’t miss some line elsewhere, there wasn’t one).

OK. let’s mount up /Netgear/ext and /Netgear/ms, no worries, right?

root@rockpro64:/# mount /Netgear/ext
root@rockpro64:/# mount /Netgear/ms
root@rockpro64:/# df
Filesystem 1K-blocks Used Available Use% Mounted on
udev 1015132 0 1015132 0% /dev
tmpfs 203912 5948 197964 3% /run
/dev/mmcblk0p1 30398732 17844008 12207284 60% /
tmpfs 1019552 0 1019552 0% /dev/shm
tmpfs 5120 4 5116 1% /run/lock
tmpfs 1019552 0 1019552 0% /sys/fs/cgroup
tmpfs 1019552 12 1019540 1% /tmp
/dev/zram0 49584 1272 44728 3% /var/log
tmpfs 203908 8 203900 1% /run/user/1000
// 7224824 514396 6710428 8% /Netgear
// 220790 1 220789 1% /Netgear/ms

Now that’s just wrong. Where’d my “mount /Netgear/ext” go? Worse:

root@rockpro64:/# ls /Netgear
bin  chiefio  ems  evo  ext  lost+found  ms
root@rockpro64:/# ls /Netgear/ext
bin  chiefio  ems  evo  ext  lost+found  ms
root@rockpro64:/# df /Netgear
Filesystem              1K-blocks   Used Available Use% Mounted on
//   7224824 514396   6710428   8% /Netgear
root@rockpro64:/# df /Netgear/ext
Filesystem              1K-blocks   Used Available Use% Mounted on
//   7224824 514396   6710428   8% /Netgear/ext

So it looks like we get 2 mounts, only one of which shows up in df (and it isn’t in /etc/fstab).

Well, OK, I copied the stuff I want to share onto the /Netgear device and I’m “moving on”. I don’t really care if there’s some strange mount bug in cifs or if SystemD is pig-headedly hanging on to a mount from two boots ago. I don’t care if it “spontaneously resolves” some time next week; or stays forever. I got the bits moved and I can just “let it go”…

But that’s the kind of crap I never get (and never got) under pre-SystemD Debian / Devuan.


Mixing 2 of my “favorite” bug factories: SystemD and Microsoft. What could possible go right…

Sidebar on Swap

In case anyone cares, here’s the little script I used to add a swapfile to a system. Yes, you can type all the commands by hand, but why not just type “swapfile” and move on?

This command “swapfile” takes up to 2 arguments. If you give it none, it makes a swap file named /var/SWAPFILE of size 2GB. ( 2 Meg of 1024 blocks). Along the way it is a bit chatty and shows you present swap usage, the size of any exiting swap file, size after making, and more. I use “time” on the actual dd command as it was taking a long time (as I was playing with it several times…). Along the way I discovered a heavy page weight browser page in Chromium that was playing a bunch of videos in a rotation and in the process chewing up a lot of memory, that became a lot of swap when “dd” was running. At one point it filled 2 GB of swap. Eventually I closed that tab after I was done tormenting the machine to see what bad thing might happen leaving it running… Then this script went much faster as the memory suckage, compression load, disk & I/O channel contention and swap thrash was gone.

Yes, it really ought to check for the existence of /var/SWAPFILE and offer to just use it, but that’s a level of fancy I really don’t need. IF it’s there, I can ctl-C out and just do a “swapon -p 2 /var/SWAPFILE” long hand. I also could have evaluated the value of $ANS and looked for a Yes or No or whatever… but ctl-C is just dandy as “get me out of here” option. (return key to continue). You do not want a swap file or partition to be readable by anyone but root, so set perms to RW—- or 600. Make it as swap format, and start using it with priority 1. (Bigger numbers get used first, and the zram is 5 by default, so this says only use the file if you are out of zram swap and any disk swap with a priority number of 2 or better).

root@rockpro64:/# bcat swapfile
swapon -s
ls -l $FILE
echo "Doing dd can take a long time"
echo time nice -n 10 dd if=/dev/zero of=$FILE bs=1024 count=$SIZE
echo "Proceed? ctl-C to exit."
read ANS
time nice dd if=/dev/zero of=$FILE bs=1024 count=$SIZE
echo "Set perms and then mkswap"
chmod 600 $FILE
ls -l $FILE
echo mkswap $FILE
mkswap $FILE
echo swapon -p 1 $FILE ; swapon -s
swapon -p 1 $FILE
swapon -s

I then fiddled around a little and did some math based on best guess to find what gave me a nice round 2 GB of swap total, and made a “one line script” with that value immortalized:

root@rockpro64:/# bcat roundswap
# For adding 2 M + 30 K "round up" to swap:
# swapfile /var/SWAPFILE 2078K

# For just rounding sub 1 M zram (short 30K) up to 2 M total even:

swapfile /var/SWAPFILE 1054K

It’s just the 1024, or 2048, or 3072 with 30 more added as K sized blocks.

So now I have my nice round sized swap, more of it, and I can put in place a hard disk swap partition of higher priority by using it as 2, 3, or 4 but after the zram is used for really fast swap at pri=5.

I also put an entry in my /etc/fstab at pri=0 (not materially different from the 1 in this case) so after a reboot, it uses the file as a last priority option, without the need to rebuild it.

root@rockpro64:/# grep SWAPFILE /etc/fstab
/var/SWAPFILE		swap		swap	sw,pri=0,defaults	0 0

and here’s what it looks like after the reboot I did to try and shake loose the /Netgear mount point issue:

root@rockpro64:/# swapon -s
Filename			Type		Size	Used	Priority
/var/SWAPFILE                   file    	1079292	0	0
/dev/sda13                      partition	2097148	0	4
/dev/zram1                      partition	1019548	0	5

At the bottom is the /dev/zram1 compressed memory swap space at a bit under 1 GB (expanded) with priority 5 (so use it first). Just above that is a real USB 3.0 disk swap partition of 2 GB at priority 4, so used as soon as zram is full (and it did get used when I was doing big “dd” commands while the browser was fiddling videos and dancing java craplettes… ran up to about 1.6 GB of swap used). Then at priority zero we get the 1024K + 30K swapfile space to round it all up to a very even 4.0 GB of swap space, but only to be used last to avoid crashing after 2 GB of memory, and the other 3 GB of swap, are all used up.

As this system puts logs, /tmp, and swap all into compressed memory, the odds of needing some swap space for all that to roll over to increases. Also, since the GHCN Maria DB uses a lot of /tmp to make indexes on big files ( it took 2 GB of /tmp you may recall) when I start doing that, I’ll need a BIG /tmp which means it will roll more stuff to swap (or I put it on a real disk partition too). In any case, to avoid surprises, having a big total swap gives me some head room on all that use of memory.

FWIW, there’s another 2 GB swap partition on that same disk, though at the other end of the platter, so I can pop on enough to get 6 GB total with just a “swapon /dev/sda2” command. Then, of course, I could just do a “swapfile /disk/mountpoint/FILEswap” for anything up to the freespace limit. Though in most cases going much above 2 x memory is really slow. So 4 to 6 GB is really about as far as I would practically expect to work worth a darn. Meaning what is already in use plus that one standby partition would really be about the limit.

Note that by doing “swapon -p 2 /dev/sda2” I can assure that the swap partition at the other end of the platter only gets used after the first one is full, reducing head seeks across the platter, and then it would only use the very slow to write u_SD card as a last resort.

In Conclusion

So I’ve copied those bits of script, and some more, onto the file share. At this point, I don’t really need it mounted on this system anymore. So I’m just going to ignore whatever is causal of this odd bit of behaviour and “move on”. Is it SystemD? Can’t say. I can say that all my years of experience say to look there first. (And that is now a startling 40+ years of doing this kind of thing…) Followed closely by “CIFS Bug” or as Microsoft would say “This behavior is by design”. That IS what they said about a bug in their handling of dual network gateways. Give it 2 “routers of last resort” it swaps between them every 20 minutes. That’s “just wrong”. Have only one active “router of last resort” is most right, followed by “load share between them” with priority values. But flip / flop / flipping all the time? Just wrong… So I’d not be surprised if it is a CIFS “feature”…

But like all bugs, you don’t know what is really causing it until you have fixed it AND it has survived a few reboots…

And I just don’t care enough to fight it to that point.

Hopefully in a few months someone will have put a Devuan on one of these, or posted about doing the “uplift”, and I’ll just move it over. If not, then I’ll be the one trying that. The uplift is pretty easy. Put the right repositories in the /etc/apt/sources.list file and then “update / upgrade”. Here’s the present set:

root@rockpro64:/# cat /etc/apt/sources.list
deb bionic main restricted universe multiverse
#deb-src bionic main restricted universe multiverse

deb bionic-security main restricted universe multiverse
#deb-src bionic-security main restricted universe multiverse

deb bionic-updates main restricted universe multiverse
#deb-src bionic-updates main restricted universe multiverse

deb bionic-backports main restricted universe multiverse
#deb-src bionic-backports main restricted universe multiverse

So just straight Ubuntu. In theory, the Devuan lines, added, ought to “just work”. But that will be after I spend some more time characterizing what “issues” are in the base case (so you can say “that’s not a Devuan issue, it is in the base case”…) and that’s a few more months on.

Ah, the joys of Systems Administration ;-)

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.

15 Responses to Simple Bug, Or Yet Another SystemD Screwage?

  1. E.M.Smith says:

    I’m pretty sure this test shows it is SystemD hanging on to information from /etc/fstab at boot time.

    So commented out the systemd-automount mount entry in /etc/fstab:

    root@rockpro64:/# tail -4 /etc/fstab
    #// /Netgear/ext cifs x-systemd.automount,guest,noperm,sec=ntlm 0 0
    #// /Netgear/ms cifs x-systemd.automount,guest,noperm,sec=ntlm 0 0

    Then make sure it is unmounted:

    root@rockpro64:/# umount /Netgear

    It isn’t there, and now there is NO mount entry in /etc/fstab:

    root@rockpro64:/# df
    Filesystem     1K-blocks     Used Available Use% Mounted on
    udev             1015132        0   1015132   0% /dev
    tmpfs             203912     5956    197956   3% /run
    /dev/mmcblk0p1  30398732 17844780  12206512  60% /
    tmpfs            1019552    72732    946820   8% /dev/shm
    tmpfs               5120        4      5116   1% /run/lock
    tmpfs            1019552        0   1019552   0% /sys/fs/cgroup
    tmpfs            1019552    14180   1005372   2% /tmp
    /dev/zram0         49584     1280     44720   3% /var/log
    tmpfs             203908    20548    183360  11% /run/user/1000
    overlaid          203908    20548    183360  11% /run/user/1000/ems-firefox-96jzpjil.default
    overlaid          203908    20548    183360  11% /run/user/1000/ems-chromium

    But no worries, systemd-automounter remembers and mounts it up if you touch the directory:

    root@rockpro64:/# ls /Netgear
    bin  chiefio  ems  evo  ext  lost+found  ms
    root@rockpro64:/# df
    Filesystem              1K-blocks     Used Available Use% Mounted on
    udev                      1015132        0   1015132   0% /dev
    tmpfs                      203912     5960    197952   3% /run
    /dev/mmcblk0p1           30398732 17844780  12206512  60% /
    tmpfs                     1019552    60956    958596   6% /dev/shm
    tmpfs                        5120        4      5116   1% /run/lock
    tmpfs                     1019552        0   1019552   0% /sys/fs/cgroup
    tmpfs                     1019552    14180   1005372   2% /tmp
    /dev/zram0                  49584     1280     44720   3% /var/log
    tmpfs                      203908    20676    183232  11% /run/user/1000
    overlaid                   203908    20676    183232  11% /run/user/1000/ems-firefox-96jzpjil.default
    overlaid                   203908    20676    183232  11% /run/user/1000/ems-chromium
    //   7224824   514396   6710428   8% /Netgear

    So I’d guess the only question is “How to make systemd-automounter forget things?”…

    Maybe I’ll just try that Devuan uplift sooner rather than later…

  2. E.M.Smith says:

    Well, I’d intended to not fix it, but… I ended up doing a reboot after commenting out the lines in /etc/fstab.

    After the reboot, no automount happened. Golly, the suckage is gone… So I uncommented the two lines in /etc/fstab and now those two mounts happen as they ought to happen.

    So it looks like doing the unmounts, commenting out the lines in /etc/fstab, and then rebooting (maybe twice…) eventually gets SystemD to let go of the old state information and leave you alone. Then making the lines in /etc/fstab will get the new state information loaded into SystemD and it will accept the change. Maybe…

    There’s probably some SystemD way to achieve this, but frankly, the more I learn about SystemD the less I want to learn about SystemD…

    But at least things are normal again. For a while….

  3. E.M.Smith says:


    Looks about right. Only resets at boot or some ill defined service restart. Makes a kind of a systemD-ish extract and doesn’t look back. So I’d class it as “yet another SystemD Screwage” and not as some CIFS bug.

    Yet more from the “everything you know is wrong” school of compatibility coupled with the way over the top baroque school of SystemD “fix what ain’t broken and in as complex a way as possible!” design philosophy…

    Just another reason to convert to Devuan as soon as it is working on this board… (which might be now already…. Maybe I’ll try it later this weekend…)

  4. jim2 says:

    I haven’t revisited you Devuan uplift posts, but this appears to be an easy path to Devuan on Pi.

    I see also there is a variant for odroidxu4.

    This may be what you are already doing, but thought would post it just in case.

  5. E.M.Smith says:

    Always nice to have info on what others are doing. For the “uplift” all I do is what the Devuan folks have posted at their site. Add it to the sources.list and update / upgrade.

    Initially from Jessie ( Debian 7)

    now more frequently using the Ascii (Debian 8) install or upgrading an older Jessie

    I couldn’t get the XU4 install to work (a year or two? ago when I tried it last) but the migration from Armbian Jessie did work (with one annoying bug that at first boot the cursor is often invisible and you must pop open a window by braille to get it to show. So I go down/left/down/left/down/left until a wiggle causes the icon for the menu to change color, then use the highlighting to get htop open, then it’s fine). So on my “someday do” list is to try a straight install of Devuan 2.0 again.

    I suspect it might be that the install on their site is for the emmc card not the u_SD, but really just didn’t care enough to fight it. I had something that worked so just moved on… So was it me getting some detail wrong in the install, or emmc vs u_SD, or a bug in the release, or… Don’t know… but someday….

    FWIW, I really REALLY like the XU4. It is just a very competent little board. In some ways my favorite. I tend to use it and the Raspberry Pi M3 the most.

    Right behind them is the RockPro64. “Whenever” I get Devuan onto it, it may well move into first position. For now it is held back by the “sand in the teeth” of SystemD-isms. It generally just works, but as this post documented, there are walls you run into from time to time of WT? I mean, really, what kind of Unix / Linux has a change of fstab that sometimes has an effect and sometimes not? Just wrong. But the speed is impressive and most things just work.

    After that it’s more thin tea… The Orange Pi One boards also just work but I’ve also left them as SystemD vanilla installs. Their big selling point is being dirt cheap (though I’ve not looked since tariffs went on, so maybe $12.50 instead of $10? or whatever). Makes nice NFS server. The Pi knock-offs like the Rock64, Pine64, and similar work fine, but have a less robust community and less tuned up software. You can get anything for the Pi, but the others? Well, look at the list of Devuan supported releases you posted… And as they are at “about a Pi” of performance what’s the point? They do have some improvements, but is a bit more memory or an added usb 3.0 really that much more important than the software maturity and selection?

    Then there’s my one big disappointment. The Odroid N2. It blew out (something) in my hdmi / adapter / DVI interface to my second monitor, so now that doesn’t work with even the R.Pi (but is still usable via the other interface on old PCs). So it went to the box for a few months. A couple of days ago I tried booting it up on the TV (where it had been working before) and it seems to hang in the boot process. I didn’t change anything, but it just sits there. NOTHING on the screen. The router doesn’t report it getting a DHCP address which is why I think it is hanging. I probably ought to have swapped it from the “hide everything until you are up and logged in” default mode to the “put your actions on the screen” mode when it was working, but didn’t. For all I know it might just be asking me to log in and run fsck by hand (but on the serial console that isn’t there…) So it’s back living in the box again. Another “someday” project… to recover it.

    My usual habit is to NOT buy “the latest and greatest” and wait at least 6 months, often a year. That gives time for the software to mature some, bugs to get worked out, and sometimes even a hardware rev for some issues. I violated that practice with the N2 and the RockPro64 so that I could do reviews of them. Well, that was worth it, and it was donated money so was used for the purposes of the blog not my personal needs. I’m OK with that. But at this point I’m more likely to go back to my usual pattern and just wait a while on newest stuff.

    I’m also more likely to only buy boards on the Devuan supported list. Once I’ve got the Devuan XU4 install sorted out, I could easily see adding a couple more of them. Yeah, they are all v7 and not v8 (64 bit) so any cluster computing would be a 32 bit cluster, but I already have some 32 bit boards and a lot of math is fine at 32 bit… OTOH, codes like sysbench will run in the GPU on 64 bit ARM chips… and it is smoking fast.

    But that decision must wait on me getting the direct Devuan UX4 install running and / or getting some parallel codes running that actually benefit from a Beowulf cluster. (So far it’s been more of a wash with the overhead eating up the benefits and One Fast Board being the better path. An Octo-Core XU4 with USB 3.0 disk can sling bits off the disk way fast and run FORTRAN / SQL / Python at impressive speeds, while a stack of Pi on USB 2.0 with 100 Mb Ethernet between them has some hurdles to leap to catch up.)

    So for now I’m working more on getting the database cleaned up, fewer languages to make it go (eliminate the FORTRAN steps just because “the kids” in the field are prejudiced against it) and then port it to Docker / AWS so anyone can have a go with it.

    Speaking of which, I probably ought to get back to seeing if the latest update / upgrade on the RockPro64 fixed that graph legend bug. I DID see updates to python and libraries during the process… While it is “fast enough” on the Pi and “nice” on the XU4, it would really benefit from the Damn Fast cores on the RockPro64 and the 2 GB of memory. By now that bug ought to be fixed, and all the rest of the code did work correctly, only the legends on the graphs were messed up (and that ought to have been an easy fix).

    Oh, one final point, at Ameridroid right now they have the XU4 (with fan or without) on sale for $52
    If I had a use for it other than just making a play cluster, and the money, I’d buy a couple more of them. But I don’t, so I haven’t. They also have the Atomic Pi at $38 (down from $140…). It is an Intel arch board. I’d buy one of them to play with but for the fact that power goes in via pins on the board (solder or make your own plug) and it looks like it is basically the guts of a failed product (box / kiosk) being remaindered out as SBCs so not going to have follow on products, support, or much of a community. But still, at $38 Intel SBC? Hard to beat…

    But I have more boards than desktop already, so “not, I think, today”… At least not until I get more work done ;-)

  6. jim2 says:

    I’m slowly getting an area set up for small computers and my laptop. Lots of irons in the fire right now so it’s not a top priority.

  7. E.M.Smith says:

    Well, just to be safe(r) in the RockPro64 I changed it to let me see the boot happening and NOT autologin to the first user you build at install time. One edits


    and sets the first variable to “false” instead of “true”:

    root@rockpro64:~/SQL/bin# cat /etc/default/nodm 
    # nodm configuration
    # Set NODM_ENABLED to something different than 'false' to enable nodm
    # User to autologin for
    # First vt to try when looking for free VTs
    # X session
    # Options for nodm itself
    # Options for the X server.
    # Format: [/usr/bin/] [:] 
    # The Xserver executable and the display name can be omitted, but should
    # be placed in front, if nodm's defaults shall be overridden.
    NODM_X_OPTIONS='-nolisten tcp'
    # If an X session will run for less than this time in seconds, nodm will wait an
    # increasing bit of time before restarting the session.
    # Timeout (in seconds) to wait for X to be ready to accept connections. If X is
    # not ready before this timeout, it is killed and restarted.

    In theory I can put the Odroid N2 emmc chip on my adapter, plug it into the USB slot, and edit the file on it, too, and then ought to see the boot process happening. Maybe.

    FWIW, I’ve also tested the updated python on the RockPro64. Still having some issues with legends. It looks like it is generally working, but for example, on one with “year” across the bottom it looks to have typed every single year (almost 300 of them…) in the 4 inches of legend space. Each end looks sort of like a digit, but the middle is a dark blobby thing… Graph is nice and looks right, though ;-)

    I suppose there might be some way to tell it to only print every 50th year or some such, but it does that automagically on the other platforms, so I’m counting it as a bug. Even if a minor one.

    So for now, at least, that’s an “investigate slowly maybe” thing while doing the DB stuff on the R.Pi or XU4…

    Oh and one other minor note:

    I set about configuring all the settings on Chromium and FireFox on this SBC / Login (set to strict paranoid and forget everything mode as it is rarely used) and made this little mini-script:

    root@rockpro64:~/SQL/bin# bcat nukemid
    cat /etc/machine-id
    echo "00000000000000000000000000000000" > /etc/machine-id
    wc -c  /etc/machine-id
    cat /etc/machine-id

    The wc out to list that it is 33 char long. 32 zeros and the newline at the end:

    root@rockpro64:~/SQL/bin# nukemid 
    33 /etc/machine-id

    I’d already run it once so it didn’t show me the old version (in case I wanted to save it for some reason…) I probably could just truncate the file at zero length, but then you get log file messages saying it is missing. I figure if it is happy with all zeros, that’s a statement too ;-)

    In FireFox I added some search engines. Their “list of engines” now runs to 153 pages!! I only picked off the first 3 ;-)

  8. E.M.Smith says:

    Interesting search engine. It looks up where an image URL is located / used:

    Reverse Image Search
    Search by image and find where that image appears online
    How to use TinEye

    FWIW, the “eccellio” search engine (that is supposed to limit searches to academic sites and science oriented and such) just gives me 403 permissions errors.

  9. E.M.Smith says:
    looks interesting…

    Search Results

    Daily News

    Your search for term “Global Warming” returned 8,917 results.

    I’m surprised it’s only 9k… then again, I think it’s only searching their journals (AAAS).

  10. DAVE says:

    I know how much you love systemd – my feelings are the same. Have you heard about this stupidity?

  11. E.M.Smith says:


    Oh My God NO!….

  12. Larry Ledwick says:

    I know how much you love systemd – my feelings are the same. Have you heard about this stupidity?

    There is no such thing as a free feature.
    There is no such thing as bug free software

    Even if some of those attributes might be desirable to some it should be a “feature” you can opt into or out of, not a “my way or the highway” switch.

  13. E.M.Smith says:

    Like, oh, a LUKS container… I love encryption, but it comes with a cost. CPU, memory, reliability. What happens when a few bits are lost so ALL the decryption fails? What happens when the system crashes, will the rebuild know the right keys?

    Having had to recover from Bad Things I’m very familiar with dredging around in a semi broken file system to recover what you can… And Lord help them trying to recover a 10 year old copy once all the changes and updates have changed it all…

    One good thing, it again confirms my resistance to SystemD (mented)..

    I think the Debian base will be increasingly impossible to purify and remove SystemD Crap, so longer term a non-Debian base will be key. I think it is time for me to embrace Gentoo… It is OpenRC by default and all built from sources, so BSD like. Plus ports wider that way.

    The Stupid is stong in Pottering….

  14. E.M.Smith says:

    Just a completeness note. I put this in WOOD I think, but it belongs here.

    I’ve recovered the Odroid N2 AND a Rock64 that both looked dead in booting. The problem was really a bug in fstab / systemD Interactions. On Ubuntu, an fstab entry with ‘noauto 0 0’ ought to let the boot proceed if the disk is not there. I move disks around a lot. That entry caused a hang at boot (invisibly as the boot doesn’t show progress notices…) and so no way to log in and fix it.

    Mounting the uSD card on another system and commenting out the line entirely then lets the card boot again. I’d tried restoring from the backups, but that fails since the fstab is the same, so figured it was a dead card… it wasn’t: just systemD doing the wrong thing with fstab.

    Happy to have the boards working again. Pissed at SystemD Stupidity making my life worse.

Comments are closed.