TRS-80

I think your assessment of that page is pretty spot on. I started working on improving the docs recently, so I will add this to the list. I could swear I read this somewhere before, but I will try and give a brief summary (and if nothing else, use it as genesis for improving docs): Legacy is the kernel that comes from the mfr at the time the board is released. Some times it can include certain drivers (particularly multimedia) that can make it better for certain use-cases (i.e., desktop). Some times, with passage of time, the kernel gets older and older for various reason (some times not receiveing good ongoing support from the mfr, poor documentation so community can not write F/LOSS drivers (and thus get them into mainline kernel), etc.). Current is based on current mainline kernel, and therefore includes whatever is supported in mainline. This is best for long term support, and things which have good F/LOSS drivers (or even good docs from mfr) will often end up well supported here for a long time. However until all that is working well there is some period of time where you might be better off on Legacy (and particularly for certain use-cases). Which is better for someone's needs? Hopefully you can appreciate it's not such a clear cut decision. It also varies per board and over time. Hopefully that was at least a little bit helpful, I will work on polishing that up and getting it back into the docs. Whatever is on the download page for a particular device is the currently recommended kernel to use. This is periodically re-evaluated, but basically it is the current consensus of developers what to recommend at this time. And so, this is why Werner is recommending that one. If they are not recommending 5.x current, there is probably some reason for that. But you would have to go digging through some threads to find out why (FWIW, I also have an ODROID-XU4 and I am not even sure the full reasoning). Having said that, maybe you try 5.x and it works great for you. If so, please report back your findings. Make sure and back up any important data (as always). These Single Board Computers (SBCs) are quite a niche (and complicated) area within the broader GNU/Linux community, and a lot of what is done here at Armbian is quite cutting edge. I really do not think you will find better support (for SBCs, at least) within the broader community. Fact is, without Armbian, we would actually even be much worse off (if you can believe that). I don't think it will probably ever be anything like a MacOS sort of experience, but I agree some things could surely stand improvement. Which is why (personally) I try and contribute what and where I can. Because I really enjoy these little devices. There is no company, no business model, no nothing behind Armbian. Just a handful of interested hackers and frens spread all over the world. I'm actually amazed some times we accomplish what we already do on such limited resources. But that is the reality (to keep things in perspective).

I been curious about your setup, ever since I expand your signature at some point (and been thinking along similar lines myself lately). Did you get into these tools because they were supported on Armbian? Or you already preferred them (for whatever reason) and either luck out (already supported) or you adapt them to Armbian? For my needs I think I could be a lot better off than I currently am by simply moving up to Docker (and I think it would meet most of my needs). But who knows, I become familiar, then want to go to next stage. You know how it goes. But I think I need to do the steps in order... Also I have a lot to learn yet...

I think you might not be understanding difference between legacy and current (and dev). Unfortunately only link I could quickly find was here and it's not what I was expecting (and I think about writing something better). It seems to me this has been addressed better somewhere, but I can't seem to put my finger on it at the moment. Also not sure what you mean by "start over with Ubuntu or something very mainstream" as that could be interpreted couple different ways? There are some particulars of these little boards that need to be learned, this ecosystem is not exactly the same as x86 GNU/Linux. However it is worth it IMO, for the benefits one gets in return (small. low power, inexpensive, etc.).

I am trying to convert my recent experience into something more generalized, in order to improve documentation. I already split off into a new page of docs Recovery, now I would like to add a new section to that page about manually replacing u-boot. In my case, sunxi was pretty easy, but trying to generalize this it gets more complex. I am not too familiar, so I researched for a while today and I think I have some idea, but before I start writing I want to make sure I am recommending the right approach. Basically I think I will recommend in 2 parts: 1. Explain how to extract u-boot from deb package after downloading from e.g. https://apt.armbian.com/pool/main/l/linux-u-boot-BOARD-RELEASE. 2. Search in https://github.com/armbian/build/tree/master/config/sources/families for `write_uboot_platform` function, out of which you will get parameters for dd like where to flash to (seek=), etc. Problem with #2 as I see it, some of them are slightly more complex like ODROID-XU4 for instance: dd if=$1/bl1.bin.hardkernel of=$device seek=$signed_bl1_position conv=fsync > /dev/null 2>&1 dd if=$1/bl2.bin.hardkernel.720k_uboot of=$device seek=$bl2_position conv=fsync > /dev/null 2>&1 dd if=$1/u-boot-dtb.bin of=$device bs=512 seek=$uboot_position conv=fsync > /dev/null 2>&1 dd if=$1/tzsw.bin.hardkernel of=$device seek=$tzsw_position conv=fsync > /dev/null 2>&1 dd if=/dev/zero of=$device seek=$env_position bs=512 count=32 conv=fsync > /dev/null 2>&1 Also some are inside include directory there. I am trying to keep this as general and simple as possible (for wide audience), so I started to wonder if this is the right approach. I start to wonder, instead of docs, if I should write some script that figure out all parameters and do it automatically. But maybe it exists already? Somehow adapt some existing script, but instead of working from a running system, to run from a recovery context? Now I am not sure what is the best approach. Any feedback would be appreciated. I am willing to do the leg work, just need a bit of guidance.

Aaaaaarrrrgh!

It's a lightweight web and reverse proxy server. Many people prefer it to Apache for some years now because of its smaller footprint and thus perceived better security, etc. You may have heard people call it "Engine X" which is actually how it is pronounced. But it took me couple years to realize they were talking about "nginx." @Sergei, You are on Testing or Unstable? A quick search of Debian repositories for nginx-core seems to indicate that will be required. Don't forget to `apt-update` after changing your sources.

Yeah, you may need to take couple (few?) hundred of funds and purchase some "gayming / enthusiast" type case, unfortunately. And likely a big one. Maybe you don't like that (some don't) but I like having the room. It makes working on stuff much easier. And these sort of cases have room for radiators, plenty large (140mm) fans, etc. Mine sits right next to me on desktop (to showcase it) but I can't hear it at all (I only hear the little ODROID-XU4 fan when it winds up, lol). You will be working that board a lot harder than me though (I guess why you choose to go liquid cooling, makes sense). A number of years ago (5-6? +?) I bought Corsair 750D which is not the biggest one they made but pretty close, as I knew it would give me room to expand (including many HDD) for some years and it is still serving me wonderfully. Very happy with it. By now I have upgraded my main battle station to similar server style mobo (KGPE D-16) and 2x Cooler Master CPU coolers which are absolutely gigantic (inexpensive, but gigantic) and they fit fine. I also have a number of HDDs and a couple SBC all inside the same case. It works out pretty well (mainly as a proper place to mount all the HDDs, which are in fact connected mostly to the SBCs). That line of Corsair cases I think is still around, and (at least at the time) they were not plagued with too much of the flashy gayming crap and blinking lights, etc. In fact very clean looking, classy, and understated (IMO). And quite reasonably priced, for the quality. But this was prior to Corsair tramp stamp era. Obviously all subjective, there are many other cases out there too and things probably changed a lot in the meantime. I got a smile the first time I opened htop on my current machine (2x AMD Opteron = 32 threads total) but that is just crazy, man. The CPU list takes up like 2/3 of the screen. Nice.

The problem (as I understand it) likely is not "an A20 board" but rather "[some random] old TV Android box." Maybe, maybe not. Could be simple or complex. But it will be up to you (and/or others) to dig and find out (as it is not Supported device). What you may find (after spending some (a lot?) of time) is that there are good reasons that Armbian does not support every random board out there (and especially, TV boxes). Or, maybe you get lucky and get it working better (in which case, please share your findings here). It actually sounds to me like you are a little bit into a decent investigation already. Maybe you know more than me. I, personally, do not want to get involved in (potentially lengthy) investigations. And therefore I stick (strictly) to the list of Supported Devices. In fact, I use that as a starting point for any hardware purchases. But maybe you like a challenge? Good luck!

$ man df OPTIONS -i, --inodes list inode information instead of block usage `df -i` is giving you inodes. Sounds like your root filesystem is just full. Out of curiosity (and for comparison), I just went and did `df -h` on a couple of my own Armbian systems (a cubietruck and an ODROID-XU4) and the root file system on those was only taking up 3.8G and 2.2G, respectively. So, something is filling up your root filesystem. Are you sure the backups are going to the external drive? Double check the settings. There are a number of tools you can use to analyze the filesystem and see what is taking up the space. Personally I like qdirstat, because it gives a nice visual representation. That tool is readily available in Debian repositories. There are also command line alternatives. In your case, if the system is locked up, you may need to shutdown, remove the sdcard and mount it in some other Debian, Armbian, or GNU/Linux based system to see what is going on (and perhaps delete some stuff).

It was the little progress bar at the bottom (with apt) that won me over finally.

Just doing maintenance tonight on my boxen, regular `apt upgrade && apt update` on ODROID-XU4 and I noticed Debian upgraded to latest kernel (5.8 or whatever). I go look in boot and notice `uInitrd' is pointing at the new Debian version (instead of Armbian version): drwxr-xr-x 4 root root 4096 Nov 15 19:53 . drwxr-xr-x 22 root root 4096 Nov 15 19:50 .. -rw-r--r-- 1 root root 65 Nov 15 19:28 armbianEnv.txt -rw-r--r-- 1 root root 1536 Jun 4 15:24 armbian_first_run.txt.template -rw-r--r-- 1 root root 38518 Jun 4 15:24 boot.bmp -rw-r--r-- 1 root root 4882 Jun 4 15:24 boot-desktop.png -rw-r--r-- 1 root root 12479 Jun 4 15:24 boot.ini -rw-r--r-- 1 root root 64 Jun 4 15:24 boot.scr -rw-r--r-- 1 root root 151722 Oct 18 15:42 config-4.14.202-odroidxu4 -rw-r--r-- 1 root root 238874 Apr 23 2020 config-5.5.0-0.bpo.2-armmp-lpae -rw-r--r-- 1 root root 246529 Sep 26 13:31 config-5.8.0-0.bpo.2-armmp-lpae lrwxrwxrwx 1 root root 22 Nov 15 19:49 dtb -> dtb-4.14.202-odroidxu4 drwxr-xr-x 2 root root 4096 Nov 15 19:49 dtb-4.14.180-odroidxu4 drwxr-xr-x 2 root root 4096 Nov 15 19:49 dtb-4.14.202-odroidxu4 lrwxrwxrwx 1 root root 22 Jun 4 15:24 dtb.old -> dtb-4.14.180-odroidxu4 -rw-r--r-- 1 root root 7011311 Nov 15 19:50 initrd.img-4.14.202-odroidxu4 -rw-r--r-- 1 root root 21912634 Nov 15 19:51 initrd.img-5.8.0-0.bpo.2-armmp-lpae -rw-r--r-- 1 root root 0 Nov 15 19:50 .next -rw-r--r-- 1 root root 2394556 Oct 18 15:42 System.map-4.14.202-odroidxu4 -rw-r--r-- 1 root root 4131671 Apr 23 2020 System.map-5.5.0-0.bpo.2-armmp-lpae -rw-r--r-- 1 root root 83 Sep 26 13:31 System.map-5.8.0-0.bpo.2-armmp-lpae lrwxrwxrwx 1 root root 26 Nov 15 19:53 uInitrd -> uInitrd-5.8.0-0.bpo.2-armmp-lpae # <--- see here -rw-r--r-- 1 root root 7011375 Nov 15 19:50 uInitrd-4.14.202-odroidxu4 -rw-r--r-- 1 root root 21912698 Nov 15 19:51 uInitrd-5.8.0-0.bpo.2-armmp-lpae -rwxr-xr-x 1 root root 5728872 Oct 18 15:42 vmlinuz-4.14.202-odroidxu4 -rw-r--r-- 1 root root 4817408 Apr 23 2020 vmlinuz-5.5.0-0.bpo.2-armmp-lpae -rw-r--r-- 1 root root 4874752 Sep 26 13:31 vmlinuz-5.8.0-0.bpo.2-armmp-lpae lrwxrwxrwx 1 root root 26 Nov 15 19:50 zImage -> vmlinuz-4.14.202-odroidxu4 Only uInitrd was changed, not any others (as you can see). I'm on Buster Stable. I don't think this is supposed to happen? Just wanted to ask here before filing bug though. EDIT: I also don't think it's a big deal either, as I'm pretty sure I rebooted without issue at least once in the meantime (before noticing).

A couple things to follow up. First, there was still something we were speculating about in IRC: Does Armbian upgrade u-boot some times upon upgrades? Some thought maybe yes. But I would not even know where to look for such information. Also, I am still a little worried about the results of fsck from above. I'm too tired right now, but I think tomorrow I will try it again, now that I have a working u-boot, just to see if I get same error. As I have nagging worry in the back of my mind still about SD card.

Ahem. IT VEEEEEERRRRKS! In the end, I had to dd the u-boot into place (I got the location from sunxi wiki): # dd if=u-boot-sunxi-with-spl.bin of=/dev/mmcblk1 bs=1024 seek=8 I got the file from https://apt.armbian.com/pool/main/l/linux-u-boot-cubietruck-current/ (of course, if you are reading later, yours may be different). The advice here was very helpful. But I still would have never got there without a little help in IRC. Special thanks to @Igor, @lanefu, @TonyMac32, and @archetech, who all helped me in one way or another. Cheers (I am actually having a cold one right now)!

In general (with Armbian), the answer is yes. I am not sure there is anything Helios64 specific that may be different about this (for that, wait for gprovost, aprayoga or someone else more knowledgeable to answer specifics). The tool you are looking for is the (perhaps poorly named) nand-sata-install. However perhaps we have got all this backwards. Whether your concerns re: micro sd slot breaking are well-founded, is also a separate question. Do you plan to be swapping out sd cards a lot? I would think that with a NAS especially, mostly it would just be sitting there (after the initial setup).

OK, I did the file system check. I tried many combinations: $ sudo fsck /dev/mmcblk1 -f $ sudo fsck /dev/mmcblk1 -f -b 8193 $ sudo fsck /dev/mmcblk1 -f -b 32768 $ sudo e2fsck -b 8193 /dev/mmcblk1 $ sudo e2fsck -b 32768 /dev/mmcblk1 They all return the same result: fsck from util-linux 2.33.1 e2fsck 1.44.5 (15-Dec-2018) fsck.ext2: Bad magic number in super-block while trying to open /dev/mmcblk1 The superblock could not be read or does not describe a valid ext2/ext3/ext4 filesystem. If the device is valid and it really contains an ext2/ext3/ext4 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock: e2fsck -b 8193 <device> or e2fsck -b 32768 <device> Found a dos partition table in /dev/mmcblk1 What does it mean? Corrupted or bad sd card? Or just that I borked something somewhere along the way? It's a 64GB Samsung Evo from known good source (B&H Photo & Video), which I did thorough test (according to Armbian recommended method) when it was new, however OTOH it is few years old now, been in service the whole time... Besides that, someone in IRC (+rneese) answered my question from above. The 'root' package is apparently the root filesystem? If that is true, then my assumption from above that those instructions do not actually replace u-boot is correct? I think this is relevant, as I suspect I need to replace u-boot. I know, I know. SD CARD. However I am not convinced that is the problem. Unless above (fsck results) clearly shows that without a doubt (I am not sure)? Because everything was fine until I tried to upgrade my kernel through armbian-config. I still think that I need to "surgically replace u-boot" as Tony so succinctly put it in IRC. But I welcome feedback from anyone with more experience.

I approve this, but I am not sure if it is particular to this thread or not? @microsolar (or anyone really), If this is not specific to distribution in OP, please let me (or other moderator, via flagging) know and I will split it off to its own topic. Thanks.

I will try and provide some clarity. Because this is not what you did. I mean, you did, but then you also said (emphasis mine): Can you not see how this might be taken as "my time/effort is valuable, but I don't value the time/effort of others because I expect them to do all these things for me, and then hand me the results on a silver platter"? Everything after that just went off the rails.

Thanks for the pointer, Igor, I had not seen that before. I am reading how to unbrick the system (section at the provided link) and the first paragraph states: However, the list of (4) packages provided shortly thereafter does not actually appear to contain the u-boot: Out of those 4 packages, I understand kernel, dtb, and firmware, but what is 'root'? Further, looking in https://apt.armbian.com/pool/main/l/ I see a lot of linux-u-boot-* packages. Sorry if these are dumb questions, I'm really out of my depth here and just don't want to go flashing random stuff without understanding. I will be happy to update the docs (if appropriate) once I actually understand what is going on here. Particularly as further diagnosis (late last night) seemed to indicate that my u-boot might be the problem. I was able to boot a more recent image on a different sd card. In fact Tony was suggesting I grab a newer u-boot and dd it onto the old card (following instruction here). Which of course leaves the issue of how it got like that in the first place (sd card corruption, starting to wear out, etc.). But first things first. So I guess in the meantime I will at least do the filesystem check as outlined here.

Definitely nerd porn. Thanks for sharing pics and progress, Igor.

@lanefu, OK, so that recent test image booted! What now?

Interesting glimpse into how the other half lives, lol, thanks a lot for sharing this with us Nico. I share your concerns, and I am sure many others do as well.

My comment was in general about Debian, as I am long time Wireguard user and dealt with these problems before. But OP also did not state how he installed (Softy? Tailscale?) and I think Armbian includes some extra things already nowadays on top of vanilla kernel modules. So perhaps Werner answer is more relevant. Or maybe we need some more information from OP, or maybe I am just misunderstanding.

You know @lomady, you are right. All jokes aside, something had been bothering me a lot about MS purchase of GitHub and seeming to "get religion" all of a sudden with regards to "open source." I wasn't buying it of course. I (and I am sure many of you guys around here, too) am old enough to remember Embrace, extend, and extinguish, the Halloween documents, Microsoft's funding of the SCO lawsuit, as just a small sample of the sort of hostility towards F/LOSS that you alluded to. Although extremely suspicious, I still could not put my finger on exactly what their end game was (particularly with regards to the purchase of GitHub). Until I read an (IMO) excellent article recently by Drew DeVault called Embrace, extend, and finally extinguish - Microsoft plays their hand wherein he lays it all out. I have to say I agree with him. This resonated quite a bit with me, as I have finally gotten decent enough in writing Emacs Lisp to be close to publishing some of my functions into a package that others might find useful. And so I have been looking for / thinking about a place to share my code. But I did not want to so much as lift a finger to improve Microsoft's platform (GitHub). Though my contributions may be small, they are mine. I realize the Armbian project has a different set of concerns (likely around making contributions as easy as possible) than I do personally, and so the calculation will be different. I know a lot of projects are on (or moving to) GitHub nowadays because "everyone is there." But this sort of platform centralization is the beginning of bad things happening (IMO). However at the end of the day I do not think that those of us who are involved in F/LOSS should be giving any morale or mindshare to the Microsoft juggernaut. I agree with Stallman that even non-coders can help out a lot simply by deliberately using the term Free (or Libre) Software, by talking about freedom (instead of "open source") and why that's important, and instead discussing F/LOSS alternatives to proprietary software (or in case of VSC, why you shouldn't trust Microsoft).* Because marketing and mindshare are important. Microsoft has vast resources at their disposal, and they are going to do what they are going to do. But we don't have to help them. Remember, they tried to kill us. * Yes I realize VSC is nominally "open source." However it still contains tracking garbage. But my main objection is that it takes a lot of investment of time and energy to learn any piece of complicated software, and an IDE / editor is no exception. So, do you want to invest all your valuable time into a piece of software / platform that can be changed or yanked out from under you at any time (or perhaps more likely, subtly steer you into usage patterns that benefit some corporation, usually at the expense of free and open alternatives)? Because I sure don't. I haven't got time to re-learn another complicated platform. Which is why I decided some years ago now not only to steer clear of such software, but to actively contribute to making the (F/LOSS) alternatives better. This is a general standpoint, applicable to many types of software, not just editors of course. And one I urge you to consider.

I just noticed that mkimage command at the bottom. Do i need to run that?

I think Wireguard kernel modules were not included until 5.6. Prior to that you have to use dkms (wireguard-dkms package in Debian) which might be pulled in if you install wireguard itself. If you are on Buster, you should install from backports repository.