TRS-80

You will probably be better off installing Nginx (Proxy?) Manager as an add-on, assuming it is available. It will be much easier for you that way.

They may have been tests. Or they could have worked at one time. But Linux kernel (and other hardware) is always moving forward and everything needs constant maintenance.

I am going to go back to basics, so apologies if this is too obvious. Are you guys opening ports between the container and the host? I am still learning Docker myself, but isn't the default to limit containers to their own little Docker network, where they can only reach each other? For example, when I started running Home Assistant as a Docker container, I had to allow `--net=host` option (well, the equivalent in my `docker-compose` file, but you get the idea).

I don't even own one of these, but I am fascinated by how you guys finally got it stable it sounds like? After all these years. And the fact that Kobol (our once partner) went out of business years ago (I just looked and we are about a month shy of 3 years now). Such triumph of the human will (and this project!), it could almost warm an old cynics heart. EDIT: I updated (removed) the "instability" comments about Helios64 in my NAS article: So, you want to run a file server (aka NAS)?

Alas, I am but a low to (at best!) mid-level wizard. Nonetheless, I try and help people as best i can. Yes, some of that I knew, some I learned just now (thank you). Maybe the devs know this, too (and just don't have time to deal with it), or maybe they don't. In any case, do you think you might be able to get a patch together to help fix this problem, for the benefit of everyone?

It should be. OK I got mine working by installing the Armbian image using the nand-sata-install tool, but that was from an older version of Armbian. I am not sure what that does, if it just copies it like dd does then this will work. But if not then you might have a bad time. In particular, I would not recommend over-writing something that "works" (even though for me I hate Manjaro and KDE and therefore it never did "work" for me, lol) but I hope you take my meaning. I am not sure if this is supported in Armbian or not. Part of the problem is that the PBP has kind of weird boot order where it prefers eMMC over SD card. Putting all the above together was why I decided to leave Tow-Boot on my SPI, at least for the time being. It gives a lot of options which can be helpful, especially in case of recovery. Maybe Armbian get around to addressing the boot loader situation at some point, until then I would be careful about what you do, or you might end up with a paperweight!

On SPI? And...?

Armbian_23.02.0-trunk_Pinebook-pro_sid_edge_6.1.11_xfce_desktop (as mentioned above) pine64-pinebookPro-2021.10-005 (TowBoot) I did have to check my notes to find the latter. Sorry for not mentioning it previously, I thought people were asking about which Armbian version. I have not changed anything on that PBP since then, but from the sounds of it I need to test some newer versions. No idea when I might get around to that though, kind of busy with other things right now. If anyone finds a newer working combination, please post details. @Miles Raymond, I just read your linked GitHub issue, it appears you are using the same Tow-Boot version I am, which is interesting. I had got that from my notes, so I decided to double check on the actual device. So I went into Tow-Boot console and can confirm the following (transcribed by hand but double checked): => version Tow-Boot 2021.10 (Oct 04 2021 - 15:09:26 +0000)005 [variant: spi] aarch64-unknown-linux-gnu-gcc (GCC) 9.3.0 GNU ld (GNU Binutils) 2.35.1

Fearing this foe to be beyond my wizard level at the current time, I went ahead and ordered an RPi 3B+ to use in place of the Tritium H5. However, it would be nice to get this working 'some day'.

Sorry guise, I didn't log in for a while, so just saw your replies. Are recent images not working (they should be)? After checking my notes, it appears I used Armbian_23.02.0-trunk_Pinebook-pro_sid_edge_6.1.11_xfce_desktop. However, I vaguely recall switching from Sid to Bookworm (which, at the time, was Testing, IIRC). I think my thought process was: I should probably use Sid/edge for desktop stuff. But my dotfiles are based on Debian Testing (or Stable), so I simply switched to Bookworm in my Apt sources, as Sid is usually not too far off from Testing. But any Armbian build should work. The main thing (at the time, haven't messed with it since) seemed to be getting Tow-Boot onto the SPI chip. If newer image(s) aren't working, those should be the subject of new threads (or testing reports).

I have been reading into this for some hours now, and it seems like I will need to write (or perhaps modify from some existing) DTB overlay or something like that? I tried following the instructions here, and using a .dtbo file (hifiberry-amp100.dtbo) I copied from OSMC I have here on an RPi 3, but I don't think that's right as it mentions 'brcm,bcm2835' which I suppose means it can only be used with RPi. The above mentioned .dtbo file seemed to be in some binary format, although I could still make out some text in it. I can't even seem to find the uncompressed (plain text) versions, I searched OSMC and HiFiBerry repos (amongst others), I don't think I am looking in right place (maybe I need to look in RPi Foundation or Linux kernel sources?). Any help or pointers will be appreciated. This seems to be a non-trivial task (at least for a low to medium level wizard such as myself).

I haven't touched my ROCKPro64 for quite a while. Pulled it out today and starting playing with it. I was getting 2 blinks of white LED, then a pause, then repeating. I thought it wasn't booting or something. After checking a whole bunch of things, including connecting a serial terminal, I finally realized I had a bad Ethernet cable (and this was why it was not showing up on my router). The board (and OS installed to eMMC) had been fine the whole time. Now, my understanding is that the LED behavior is particular to software (bootloader, I guess?). But FWIW, on a slightly older Armbian (21.02.3) at least, this appears to be default behavior. I just wanted to make a note for search purposes, in case anyone else runs across the same issue.

I simply installed it in a Python venv, it was very straightforward. But everyone seems to love containers these days... Luckily, they provide a number of install options, did you review them? There is no 'wrong' answer really, it's just what you prefer. If this is about the base (OS) image, I can't help you there, but at least you are in the right neighborhood now (TV Boxes). Good luck!

I suppose greenknight gave the most relevant answer, if you are strictly looking for an 'IDS'. Personally I have also been looking at CrowdSec, which seems a lot less involved to set up (and also functions differently). I found the following article (even though hosted on CrowdSec blog) quite informative: Suricata vs CrowdSec. Now, besides the comparison made in the title, I found it interesting because of the historical context it gives about other software like Snort, Zeek, Suricata, etc. There is plenty of information on the Internet about this, you will need to do some research yourself and form your own opinion. It's not even related to Armbian per say, but I guess that's why we have this section now.

Actually, first you should build it yourself from sources, using the desired command line arguments, which you seem to have sussed out. At a minimum this would confirm the solution to the problem is what you suspect it is. The next step (and this is without looking into it any further, and speaking generally, etc.) is understanding that most of userspace programs (including mpv) would be coming (unmodified) from upstream Debian. If that's true (in this case, with mpv) you should contact the Debian maintainer for aarch64 build of mpv and ask them why that option is not enabled. Or perhaps, inquire first on the relevant mailing list. In any case, please do report back your findings. Good luck!

Indeed, the Helios64 mainboard was a custom board, based on RK3399, but with a lot of nice features added, and tailored for NAS use-case. An article I wrote some time back, So, you want to run a file server? comes at the problem from a broader perspective, but might give you some ideas. At the end, I come to conclusion of using similar RK3399 based device, however I have no idea if the physical form factor of that device will be a good fit for the Helios64 case. Also I know that Helios64 had some nice integrated things like power switch, PSU, etc... of course you would be losing those (and I don't know offhand what kind of power the boards require, relative to one another, so not sure if you could still use same PSU or not). So in the end, you may have to ask yourself, is it worth it trying to re-use the case, or simply go with some more generic (and thus re-usable / re-composable) components like DIN rail power supply plus some simple, cheap metal rails (from hardware store) to screw the HDDs into. Another alternative, I have read some posts from a few people who did get things stable, but maybe you tried all those things already without success. Please do report back your findings, as I am sure more and more people will find themselves in the same boat as you as time goes on.

I, too, have nothing but disdain for them. If you follow the link to LiberaPay in my signature (reproduced here for posterity: https://liberapay.com/armbian/) you will find that they also accept credit card payments via Stripe as a processor. IIRC, you can also do a one-time donation (besides the regular, ongoing subscription).

Anything that would apply to TV boxes would certainly apply even more to 'random Android device'. In other words: I hope you are up for a challenge information will be scarce etc. I wish you the best of luck. Let us know if you make any headway.

That's not the problem, the problem is the extra workload in modifying (and then maintaining) whatever parts of Armbian to support the 2 different init systems (as c0rnelius already went into some detail about). And we barely have the resources to do what we do already... Having said that, if it is something you feel strongly enough about, have at it. But as c0rnelius pointed out, you would probably have your work cut out for you.

I think this might be the problem. Although I am certainly no expert in desktop stuff, I think it involves some low level things, which may differ between their version and ours. I am also assuming that's some legacy kernel (although I didn't bother to look). This sounds like a better way forward. Let us know how it goes.

Personally I like Mean Well, they are decent brand who tend to deliver the advertised voltage (which is a whole another problem with no-name supplies, not just in SBC world but also PC and others) and last a good long while. And pretty affordable, usually. Lately I have even been switching to DIN rail mounted power supplies for my SBCs (and other devices, even monitors, as I had too many power bricks piling up around my desktop/workbench area).

I disable it at my router (which is running OpenWrt).

I don't have that hardware, nor do I use Ubuntu desktop. But what you probably want (for your use-case) is a headless/server (i.e., more like regular Debian) version of Armbian. If you insist on using Ubuntu UI, you should seek assistance from that project.

Maybe this is beyond scope of 'support' so instead of moving to that section, I will ping @TonyMac32, hope that's alright.

Yes, that should work. Alternatively, you could build an Armbian image with Mate desktop, as I think that might be one of the supported ones available in build tool (not sure)?