TRS-80

My guess (without looking) is that their tool uses legacy kernel. You might have better experience with Armbian Legacy branch/kernel (like theirs, but maybe with some improvements usually). As a workaround in the meantime. I don't know much about graphical stuff, sorry. Maybe someone comes along who does.

Don't do it! Soon we will be seeing much less of Werner I fear the place might fall apart.

Yes it's a bit of an architectural change. But one I actually prefer. In fact, I have MQTT server running on one SBC, controller (OpenHAB in my case) running on another, etc... But you could just as easily containerize things (and one day I probably will, too). You can also position the gateway in a more ideal location (for the radio). Mine is centrally located in our home. I actually bought a PoE switch and run the power and data to it all in one wire.

If you don't mind spending a couple bucks on an Ethernet module, you could also use Open MQTT Gateway which is what I use to control my cheap 433mhz stuff. It works pretty well. uC is standalone that way (with separate SBC controller, talking over MQTT / Ethernet).

Moved to Common issues / peer to peer technical support

Moved to Common issues / peer to peer technical support I never tried to do something like this, so a bit of a shot in the dark, but have you tried using a serial debugging cable?

Do you have apt-transport-https installed? $ dpkg-query -l apt-transport-https And/or try again in few minutes? But what lanefu said might be better advice, he knows more about it than me.

Is it the same as this issue (sounded vaguely familiar, so I dug up the link): https://wiki.pine64.org/wiki/ROCKPro64#PCIe_Controller_Hardware_Error_Handling_Bug Note: Even though this is on ROCKPro64 wiki, if you read you will see it's about the PCIe controller in RK3399 itself... Having said that, it's been a while since I read it, so not sure its same thing or not. EDIT: Or maybe it's just problem with ROC-RK3399-PC only. There is a long thread here where people been working on it for years already, if I recall correctly the last I read it still wasn't working. But that link training error sounds familiar, if the answers are not in either of places mentioned above, I will have to try harder to remember where I saw that.

I dunno, I use youtube-dl, which seems quite well supported by lots of other things nowadays. In fact mpv even uses it to fetch content, you can simply do `mpv URL` and it will start playing. It's much more lightweight than the web interface, as you already noticed. Many other tools and interfaces leveraging it as well.

Ha! You already went further than me, and I been hanging around here few years now. It takes time. You are encouraging even me. And I already learned a couple new things just reading this thread. Keep up the good work.

Did you know about Recovery section of Docs? Maybe there is something helpful in there.

PinePhone becomes Supported device when? inb4 Igor (or anyone else) takes that as me volunteering to become device maintainer for it.

Shouldn't this be in bug report, so we can update the Device Tree Overlay? Or is that maintained in Linux kernel?

Hi Rainer, Thanks for sharing your solution, and welcome to the forums! Do you feel up for making a PR?

I guess you start it once and it just publishes the events as they happen. No need of shell script, it essentially does the same thing (apparently, as I have yet to try it). Also, I was pretty sure I read that the /sys/class/... interface is (going to be? already is?) deprecated. It's great to have multiple ways to do things, and maybe you prefer that way. But it might go away at some point? Being new to it all anyway, I figured I might as well learn the "new / supported" way. But you wrote a lot of helpful info, so thanks for that. I think we are hitting the goal / title of the thread from multiple viewpoints, so, good thread.

First let's get some basics out of the way. I don't want to assume your knowledge level, so maybe you know this already (or maybe not). How familiar are you with Debian, in general? The differences between Stable and Testing? Because you used the term "upgrade" but I would not say that's accurate. It's more like a trade-off. https://www.debian.org/doc/manuals/debian-faq/choosing.en.html Also, this is a general Debian question, so I moved it to the appropriate forum.

First let's get some basics out of the way. I don't want to assume your knowledge level, so maybe you know this already (or maybe not). Unless you have 2 sets of antennae on the device, won't this split your available bandwidth in half? Assuming you meant client mode on the Wi-Fi as well, as this would essentially be a repeater. Is it possible to wire Ethernet on one side? If so, you could spare that loss. I think some COTS router supported by OpenWrt might be cheapest (and/or perhaps even best). But even that depends. There have been some router discussions before around these forums, let me know if you have trouble finding them. Some Armbian supported devices and some not. Be aware that some devices had some flaky Wi-Fi interfaces (one in particular, it's escaping me at the moment, but that should be in the basic info page for the device).

At some point I had thought about connecting some LED pin by pin, but your way is better, and in retrospective, obvious. In fact, if I am correctly understanding what gpiomon (part of gpiod package) does, it should be a snap just to go around with a properly[0] jumpered button hooked up pin by pin and map everything out. That will have to wait until I am home again though (working a lot and traveling currently). Then the only remaining question should be whether these are reliably mapped to the same pins all the time? I really don't feel up to digging through gpiod sources to understand how the enumeration works. But if it's consistent / reliable, I will post a table with my findings. And if not, this method is still helpful for the individual who is just trying to hack something together for their own reasons. [0] minding voltage, etc.

Thanks for the pointers @tony013, they are very helpful. So, you are saying you did not need to enable any "overlays" as discussed in the Docs I linked above? Just the stock .dtb that Armbian provided should be enough to already enable the pins from the Linux kernel perspective (in other words, they should be enabled already, in fact perhaps I proved this already with the output of gpioinfo, above)? Also, the docs that manufacturer (ODROID) provide all only show the stupid and useless WiringPi numbers, instead of the actual ones. Well, at least that I could find so far. Maybe I need to look again (or look elsewhere, like somewhere in one of these libraries for instance, for the correct/real mappings).

My main desktop workstation is, in actuality, a server motherboard (KGPE-D16). I have a need to turn it on remotely from time to time. Apparently it is not capable of Wake on LAN, as that is a feature reserved for some add on server management card (which I don't have and am not going to purchase, as it requires some proprietary software). So I realized I could simply hook up some relay to a microcontroller to pull the power switch low for 200 ms or whatever. Well then I thought, I have a Cubietruck and an ODROID-XU4 (and a ROCKPro64 for that matter) right in the case which should have GPIO available and are already connected to Ethernet, why not use those instead... I never played with GPIO before (on SBC), so I spent the better part of yesterday reading, but I'm still not quite sure how to proceed. Here are the problems I ran into: Cubietruck uses nonstandard size pin connectors (and I don't have any of those), so pretty quickly I started focusing on ODROID-XU4 instead. Lots of resources I found seemed to be geared towards the older sysfs interface (instead of newer gpiod one). Many resources geared towards WiringPi numbering scheme (and RPi tier nonsense in general), including the official ODROID-XU4 wiki info about pin numbering. Which is absolutely Fing useless. /facepalm I am aware about the few tools that are available to abstract this away (WiringPi, pyGPIO, as well as ArmbianIO, and User Space IO) but I did not really want to have to write Python, C, or Java (I feel a simple shell script with gpiod commands, ex. gpioset should suffice for my very basic needs here). So currently I am stuck at the mapping between physical pins and what they are called according to Linux's gpiod interface. Here is output of gpioinfo on the ODROID-XU4 for instance: I even found this post from @sgjava detailing the line names: XU4 gpio device line names, but as you can see that does not match what I see above. Then I thought maybe I need to enable some overlay or something, as these names should be into Armbian by now? I was reading the Armbian Device Tree Overlay docs, which say to look in /boot/dtb/overlay, but I could not seem to find anything in there on my ODROID-XU4 other than already compiled .dtb files (no README or anything else, as it states in docs). I tried to look through Armbian sources to find this information, but I guess I don't know where to look. I was trying to find the name of the overlay to use for plain old on/off GPIO (as opposed to i2c or others). Any tips will be appreciated. I think the docs might need to be updated, which I will be happy to do once I can get this working. I don't think I'm too far off (but could be wrong).

Well I'm embarrassed to say I haven't had time to get further than physically setting up the hardware and installing ZFS. Did not even create pools or do any real migration of data or anything else yet, really. So personally, no first hand feedback to report, sadly. However in this thread, a few people report quite reliable and long term usage without problems. Which is what encouraged me to pull the trigger in the first place. A few different ones are discussed in the above linked thread, I also posted my research there at the time. There is some supported hardware info on Pine wiki as well (of course not being listed there does not mean it won't work). I would steer clear of the card they sell in their shop however (I read several bad reports about it).

Thanks for sharing your experience, it should be helpful to someone sooner or later. I was also looking for RK3399 based NAS solution (for a long time) and even piter75 (RK3399 dev here) and some other guys in IRC were very keen on RockPi 4. And reading about the company and doing more research, I could see why. I was ready to buy one, but at that time, those Penta SATA HATs were unavailable. So I kept looking around... Eventually I ended up with a ROCKPro64 because, unlike all other RK3399 based solutions, it comes with a standard PCIe slot. Therefore no need for special SATA HAT from the vendor, you can use almost any off the shelf and widely available standard PCIe to SATA adapter card instead. Not only now, but in the future should something break (i.e., how long will these special SATA HATs be available? Not only from Radxa but others with similar solutions?).

I get the sense I will be much better off with the newer version (in the case of ZFS). However, as I am now become a "ZFS system administrator" I have gone back to more actively monitoring their mailing list.

To clarify, OP wrote "Board: Not on the list" which was the last line in his post. No idea what they meant by that. If you look closely at the edit note below that, you will see a reason. It is the same as your own post immediately above this one. Anyway, in my case, my edit to OP was simply to "put long output inside spoiler" and that's all I did.

Following the @lanefu School of Systems Administration ("here, hold my beer!"), I decided to just give it a go. And IT VEERRRRRKS! Here are step by step instructions for my fellow nervous, trepidatious sorts out there: 1. Install kernel headers. I did this through armbian-config (Software -> Headers_install), rather than dicker around trying to figure out which exact package I needed for my board and architecture. 2. Issue the following command: $ sudo apt -t buster-backports install zfs-dkms zfsutils-linux Note: I did not have to enable backports, as apparently they already are "out of the box" in Armbian; however, follow instructions at link if this is not the case for you. Result: It took "a little while" to build the module(s). Just be patient, go grab $BEVERAGE or whatever, take a break... I don't know how to express how happy I am about this. I have wanted to do ZFS on some ARM based device for literally years now. RK3399 was very exciting when it came out, but took years to finally get stable. A special thanks to all RK3399 devs, here and elsewhere, for making this a reality. Beers are on me if/when we ever get around to having ArmbianCon!