TRS-80

There might be, but it will be difficult second or third hand (from us, to you, to him...). Easiest and fastest way will be just to install fresh from scratch. Back up any important user data first, though. I guess you might need to learn some very basic GNU/Linux terminal commands, even for that. But plenty of guides around the Internet for that (you will need cd, ls, cp, etc.). Good skills to have anyway. Another way to get your files off, if the OS drive is on sd card, or eMMC (and you have some adapter) you could mount it on working Linux desktop and go through and look for / move files in a GUI file manager. And/or, just buy more media (sd card / eMMC), write new OS image to that, and hang on to the old one until you acquire some way (tools/skills) to access it. At least that gets you back up and running in the meantime.

Yeah, this way also occurred to me today. Great minds think alike, I guess. Thanks for hints.

If it can be installed on Debian, it should be able to be installed on Armbian the same way (as userland packages are same). So maybe search Internet for regular Debian instructions? Sounds like maybe you have already though. I am unfamiliar with tensorflow, but a quick search of Debian packages for tensorflow seems to indicate whatever is available is in the experimental repo, and then only for amd64 (x86 64-bit) architecture. You would need something for some kind of Arm architecture for whatever your board is. So, unless I am badly mistaken, I think you will probably have to compile from source. Maybe search Internet for something like 'tensorflow on Arm' or similar.

Would a regular encrypted drive/volume solve your problem? I guess you could also keep the OS on an SD card, and remove it when not using it? Possibly and/or using some hardware encryption key as well? Most security really boils down to defining your threat surface (what you are trying to protect from). I am kind of tired, but I am having a hard time framing things from this perspective in my mind right now for your situation. Probably just me. And a lot of that is not really Armbian specific, anyway. You can use what you like, but you may find that Armbian is far ahead of a lot of other distros, at least on SBCs (and obviously/especially where you prefer Debian based distro). A lot of NicoD's videos are about Armbian desktop, not other distros.

That doesn't have anything to do with Armbian. Search Internet for information about Widevine. Although, personally, I would just avoid any service employing Digital Restrictions Management (DRM).

I seem to recall hearing once that the OrangePi boards were pretty popular. It seems to me that usually, less expensive boards are popular. Someone who actually knows something would have to provide you with some actual numbers. And I am not sure where this sits currently (what I mentioned above was some months ago).

You've got that right! Werner mentioned, but I will reiterate: You could learn a lot by studying/using our build framework. hanging out in IRC, etc.

More thoughts on this topic: https://forum.armbian.com/topic/19978-so-you-want-to-run-a-file-server/

Good research, @calinb. Did you take into account what Werner said up thread about PBP boot order (apologies, but I only skimmed your posts)? More people (including myself) should be receiving PBP soon, as they have done another production run. So, let's keep trying to figure this out. I'm sure others will be joining us. Am I understanding correctly that this did work at one time (my guess would be via nand-sata-install only, due to things Werner said)? If so, what changed? Another clue is that Manjaro apparently have it working currently. How are they doing it?

I mean, yeah, big problem here. Arm-RISC-V-Bian just doesn't have the same ring to it.

I had some problems trying to build today and last night as well, could not retrieve release file(s) from mirrors. Your errors look very similar to mine, not sure if related or not.

I would check out some of NicoD's videos on YouTube, as he is a desktop Armbian user and has made several videos from that perspective. I am sure there must be some other forum threads around here about it as well. If you meant swapping SD cards, then OK. But if you mean a true live distro, like on a USB thumb drive (as on x86), then probably not (in most cases) as arm/SBC world is very different from x86, especially around booting. If you can't get that to work in a (bloated) browser, a workaround I often use is to open the video in mpv. In fact you can do something like 'mpv youtubelink' and mpv has youtube-dl (or equivalent) installed as a dependency and can usually download and display the video all in one go. Saved me more than once on several low-spec or older devices. I somehow missed this on first read. But I guess it is one of your main requirements. I don't think you will find that. Because Linux kernel, and drivers, etc. (what you might call firmware) are being developed all the time. And so they will be moving forward, and released with new versions of Armbian. Having said that, at least with Armbian (and Free Software in general) you can see what the sources are, where they come from, when they get upgraded, build your own if you like, etc. There are also some options to freeze kernels, etc. which would get you pretty close to what you are looking for I think. As close as I think you will be able to get, anyway. Very few of these vendors provide any real long term (mainline) software support. Such is life in SBC world. These devices are fascinating, but it is up to us to keep them working (N.B. some of links/statements in my forum signature).

I think you might be able to install them from armbian-config (not sure)? If not, there is a build option to INSTALL_HEADERS. Edit: I did not realize that we are in WIP section, until someone in IRC pointed that out to me. Above comment still applies, generally.

AFAIK, those are just user space programs? Which would mean, that they should install just as any other program. Especially if you are doing so into some container or (Python?) environment. The only exception would be the GPIO, now this is something which might have more to do with Armbian (generally speaking). Is that a package name, or? Maybe search forums about how to get GPIO working on OPi Lite. The GPIO might even work 'out of the box' on Armbian (not sure; but if so, trying to install other things might be messing that up). Getting GPIO to work (permissions) through container might be another problem area. Maybe just use directly in user space (if possible) or sort out permissions. Sorry, I don't own this hardware so can't give specifics. But I try to help in general, anyway.

Yep, by now they are available in the store! Too bad I had to move and been spending money like a drunken sailor buying things for the new place. I might not have enough left now for a PBP.

Sorry for again disappearing. It took up much more time and energy than I thought to find a new place (very tough market here) and get moved. On the up side, I have my own separate bedroom/office now, where I can hack away on my mechanical keyboard late into the night (previously my battle station was in the bedroom and The Missus is a light sleeper, lol)! Still unpacking and getting settled in, still need to build a shed, etc. but at least my battle station (and SBCs) are back up and running again now!

Sorry could not make the meeting. I just read the notes. I am back to work now but locally (almost no travel) so I can have a little time here and there maybe to help with the release somehow. I'll try to hang out in IRC.

I have been wanting to buy one for what seems like months (a year?) now and they have not been able to do a production run due to the supply chain shortages (mainly screens, apparently). I follow them pretty closely, there was some hope maybe after CNY 2022 but then they announced no they could not source screens after all. So your information is really timely @hexdump, thanks a lot for that.

If I am recalling correctly, it was non-trivial (and thus, took some time) to figure out some solution that worked, in order to make this 'easy' for end users. It sounds like this broke now with kernel going up to 5.15. If I am interpreting this search for zfs Issues on our Jira instance correctly, it looks like the developers are aware of the issue(?). If you make any progress on figuring this out in the meantime, please do post back what you learned.

Generally speaking, yes, just burn to some other sd card and try to boot it and see if the new version works. Follow instructions in documentation. Whatever latest version is for that board, which can be found on download page. I don't own this hardware, I am assuming it will boot from inserted sd card first, but some devices don't work that way (most do).

So I would try uninstalling all those -edge-rockchip64 packages (or just flash new clean Armbian image) and then try to load that driver.

First thing I notice, is that's quite old version of Armbian, can you upgrade?

I think you did not give the most pertinent information. It depends what is your current topology. As redundancy is done at the vdev level in ZFS (if I am remembering my terminology correctly). Depending on that, it can be possible to upgrade in place. Topology will dictate how much effort that takes.

I see this a lot, and I am afraid it's a common misunderstanding. Debian is a distribution, they distribute (mostly user space) packages from various places. The kernels they get wholesale (from kernel.org, usually). Which is why the kernels in vanilla Debian (generally speaking) are going to be so far behind Armbian's (heavily patched and customized) kernels. In fact, this is essentially one of the main raisons d'être for Armbian in the first place. SBC/ARM is very different from x86, which is much more standardized on a hardware level. And that's also why, the user space comes pretty much straight from upstream vanilla Debian. Because that's not what we do here. Here we are focused on the (much more difficult) low level things, like kernels, bootloaders, etc. Where vanilla Debian do not. It will be nice if one day this is not the case, but I just don't see that happening in foreseeable future.

Yeah, I went ahead and put it into a spoiler (to fold away) but something that big (especially that likely exists publicly in some forge) I would have probably linked to, personally. Well, I give you credit for at least doing some investigation. Other than noticing the great length of that script, I will admit to not investing any time whatsoever studying it any further. However, my immediate thought is: Do you really want to rely on something so complex to continue to be maintained by a third party? Or to fork and maintain yourself? Especially given that bash scripting is admittedly not your cup of tea? Prior to seeing this script, I was already a bit skeptical about how far DietPi strays away from standard Debian ways of doing things. But that was based on very brief experience playing around with it only once some time ago. If we take a step back to the fundamental problem that is trying to be solved here, that seems to me essentially to be backup. And backup is good! However perhaps there is some other better way to go about that?