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!