TRS-80

EDIT: Solution in next post (this started as a question; yeah maybe I should have split it, but whatever). Apologies if this is dumb question. I finally got my hands on some appropriate (64-bit) hardware, and ready to install software now. I have read so many threads (in Kobol Club and elsewhere), Issues (at GitHub as well as Atlassian) and I think this is solved by now (on Armbian) but cannot confirm? Official install instructions (on OpenZFS website) don't really seem applicable to Armbian (kernel headers will be different, etc.). I guess what I am asking is, do I just do something like the following: $ sudo apt install zfs-dkms zfsutils-linux And it should "just work"? Or is there more to it than that? Looks like I should make sure backports are set up beforehand, as ZFS version is significantly newer there (2.0.3 vs 0.7.12). Target device is ROCKPro64, on latest Armbian 21.02.3 Buster Current, which is kernel 5.10.21.

You know, at one point I thought "maybe I should just try" (exactly as you say). I dunno, I prefer to actually try to read/research and know what I am doing beforehand as much as possible. But I know, some times you have to just go for it. EDIT: I figured it out, simple instructions now here: ZFS "just works" now on Armbian (2 step instructions if you are thick like me)!

I will be doing just regular NAS for bulk storage on spinning rust (large, inexpensive 3.5" HDDs). Maybe a story will illustrate. I will try and keep it short. So, few years ago I bought a Cubietruck because you could connect directly an HDD with this little add on power board. I barely knew anything about GNU/Linux at the time. So it was half playing around. Getting back into tech stuff that I had got away from for a long time, because life happened in the meantime (when I was young, I used to play a lot more with computers and stuff). Anyway, so this toy / experiment worked so well, we started putting more and more of our valuable personal data on there. Photos, documents, music, media, etc. So then I start to think about reliability. Because I am not a fan of "cloud" stuff, either.[0] Now, Google is certainly spying on you. But OTOH Google probably has your data backed up in 3 different physically separated data centers. So, once you start "rolling your own" solution, you have to start thinking serious about backups, redundancy, etc. So that is where I am at now. First, file level reliability with ZFS. And then later, doing ZFS snapshot stuff to remote boxes to have also off site backup (at friend or family house). Does that answer your question? [0] A euphemism for "someone else's computer."

Well, my interests were more in a practical "how do I install it", assuming regular tools and command line, etc. (personally, I don't prefer GUI stuff like OMV). ZFS is the cat's meow, if you are concerned about reliable filesystems. If you are not aware of what it is and how it works, do yourself a favor and spend a few minutes reading about it. It's very impressive! And amazing to me that mere mortals like us can nowadays obtain industrial grade filesystems like this, thanks to the power of F/LOSS! I do appreciate the offer though, mate.

I guess, as long as we can find these cheap cards on AliExpress (or wherever), and they are supported in Linux, the only other thing to test will perhaps be longer term reliability? Like you, I also plan on building more of these ARM based NAS (eventually). This one is just a bit of a prototype. So I may get different cards in future. In which case I will try and remember to report back results here (or perhaps even better, add them to Pine64 wiki). I did not think about a 5 port card, I guess it would be useful for some 2 + 2 mirrors plus a hot spare. Not a bad idea, now that I think about it. Maybe next time... @soerenderfor, Are you using any ZFS perchance? I have been reading all the relevant threads and issues (I think), but I am still a bit confused if it actually is ready to go in Armbian or not yet, whether we still need to compile, or what. I was going to make a new thread about that, but I guess I try to ask you here first.

Finally had time to play with this today. I had same problem as you, @soerenderfor. I did not recognize it at first however, because the card showed up in lspci right out of the box, without me having to do anything: trs80@rockpro64:~$ lspci 00:00.0 PCI bridge: Fuzhou Rockchip Electronics Co., Ltd RK3399 PCI Express Root Port 01:00.0 SATA controller: Marvell Technology Group Ltd. 88SE9230 PCIe SATA 6Gb/s Controller (rev 11) But the HDD(s) were not showing up in lsblk. So I search internet again for "88SE9230 linux" which led me to this helpful thread at Pine64 forums discussing similar thing. It was only then I remembered what you had said, and I came back here. So, one helpful thing from Pine64 thread above, is you can do this right away to test in your current session: echo "0000:01:00.0" | sudo tee /sys/bus/pci/drivers/ahci/bind After I did that, the drive showed up immediately in lsblk. Of course, now I know that's the problem, I will need to make permanent settings as discussed in both these threads. FWIW, someone (foresto) at end of Pine64 thread said (2020-08-20): Now I just today installed Armbian_21.02.3_Rockpro64_buster_current_5.10.21.img and I still had to do this workaround, so I guess YMMV. I am really happy to have this working finally. I have been wanting to build a 64-bit ARM / RK3399 based NAS (so I can do ZFS) for a long time now.

I am not familiar with that software in particular, but in general, if it works on Debian, it should work on Armbian. Some of these emulators though come in the form of Debian (or other) packages, and some as a whole ready to go distro in their own right. You would be looking for the former, if you want to install in Armbian. But some times there are some multimedia optimizations, where you might be better off with the whole distro version.

@@lex, I must admit that some of your "noob" questions are even a bit beyond me, at least at the moment. There are a couple relevant factors in play from my end at the moment: 1. So far, I have done only surface level playing around. My time is limited currently, as I am heading back to work and during these periods I have little to no time for anything at all outside of work. 2. Honestly I am only a low to mid level wizard in my own right after all. With that out of the way, I will do my best to answer you. I guess you are referring to what they call the convergence dock. Yes, I completely forgot to mention that earlier. So, here are some more pics: You can order PinePhone in 2/16 or 3/32, but only the latter come with this "convergence dock." I have to be honest, personally I spent the extra money (+ ~50 USD) strictly for the extra RAM and internal storage. I thought the dock was a gimmick/meme. But now that I am starting to actually play with the PinePhone, my mind is starting to change, for a couple reasons: 1. I thought the thing would be some plastic piece of cheap crap. However it does not seem that way at all. It is actually a fairly nice piece of what appears to be maybe anodized (or at least painted) extruded aluminum. I was actually quite pleasantly surprised upon opening the packaging. 2. Vast majority of software is no where near usable on a mobile / phone / touch interface yet. So this thing is going to actually help out a lot with making the PinePhone actually useful for anything in the meantime. And now I also understand why I keep reading people saying to think of it less as a phone and more like a portable GNU/Linux computer with a touch screen. Because that is more accurate description of what it really is (at least, currently). Now, as to your specific question, I do actually own a USB/bluetooth barcode reader. I am vaguely aware the difference you refer to with UART, but so far my use case was served well enough just by using it as a USB HID keyboard (and my understanding is this is the way the vast majority of them work, especially newer ones like mine, but maybe you have some existing specific hardware). So, for me to tinker around in order to answer that might take me some time to get around to, unless you can maybe give me some specific hints or link to some instructions I could quickly follow. In other words, I am willing to test / report, I just never did that before and don't really know what I am doing there. Here I must again admit to being more of an "Armbian on servers / command line" guy (and that even only for a few years). I am still trying to get my head around the graphical stuff. I am afraid someone like @NicoD or @JMCC or @fabiobassa or @balbes150 or @Myy (apologies if I am forgetting anyone) or one of other people who know about graphical stuff (maybe even @lanefu?) might have some better information for you there. Sorry. Edit: looking at Community Governance, apparently Allwinner maintainers are @martinayotte, @Igor, and @jernej (assuming that's up to date). Hopefully one of above people can cast some light. Because I am actually curious as well. And apologies for spamming everyone. These are things that, given the development status of the device, I am sure I will get around to eventually, but due to above stated reasons it might not be right away. For example, one extremely annoying thing is that the decision was made not to have any empty desktop in Mobian with Phosh. It just goes immediately from app drawer to running / switching app management. If you close all apps it reverts to app drawer. Never you can get to a plain empty desktop. Maybe it is only my OCD/autism but that is currently driving me bananas. Luckily someone at Pine forums already made a thread about it (and further in the thread they link to their fork of Phosh to put it back to "normal"). Above annoyance aside, some aspects of UI on Mobian / Phosh are much better IMO. For example, there is always a button to hide the keyboard. Which is something I really struggled with on KDE Plasma (where keyboard often seems in the way). It also seems to be snappier than KDE / Plasma. FWIW, Mobian also seem to have some better documentation, wiki, etc. than some of alternatives. Which I suspect may be driving some of its higher adoption / development. I only briefly look around so far, but I am sure you could probably find an answer over there. They also have a quite active IRC / Matrix. There seems to be a lot of excitement and activity around the project currently. But again, no time (for me, personally) at the moment for any of this. That would certainly be nice! However I think Pine64 are actually taking a good approach here, strategically speaking. Current state of GNU/Linux phone ecosystem is honestly in very early days. A lot of work will still need to be done to adapt the many existing programs to phone/touch interface. So I think their plan to get a lot of devices out there into the hands of devs and tinkerers is a good one. Because, even if you had such nice spec device, it would be essentially useless for lack of usable software (on phone/touch interface, anyway). This device is not ready for end users, especially if they are going to compare it to current gen iOS and Android devices, which have had many years and millions of dollars of development. If you are interested in tinkering / helping make GNU/Linux phones a viable alternative to incumbents (I certainly am), then buy one. They are cheap (relatively speaking). In fact, if anyone here is higher level wizard than myself, and cares as much about moving the state of GNU/Linux phones forward, and has some time available to do so, but cannot otherwise afford one, I will buy you one! Just send me a PM!

Being a noob is not a problem, mate. Only nasty / entitled attitudes are. And expecting people to do things for you. Neither of which I see here (in fact you seem grateful, which is proper IMO). As long as you are making some sort of effort to learn, more experienced people will (generally) be happy to help (see also "how to ask questions" link in my sig for more on this). Some more strategic level things are also not immediately apparent to the newcomer. But we were all there at one point. Just keep trying to learn as much as you can. Lurking the forums (and/or IRC) is really good for that, studying ancient scrolls of wisdom (man pages, documentation, wikis, etc.) you will learn a lot. WireGuard is pretty low level kernel networking stuff. I don't know as much as lanefu about containerization, but the sense I get is that WireGuard will need to (or maybe because of permissions it is easier to) configure directly on the host, because of those low level kernel networking permissions. And I feel like it's harder to containerize that. I could be wrong of course. Anyway, good luck with it, and have fun!

Sorry, no, I did not realize the thread we were in at all (I got here from All Activity stream and was replying to the two posts above mine). Anyway, back to the topic. Just today I came across bmap-tools, which not only appears to perform the all-important write verification, but also apparently have some advantages over tools like dd because it is capable of writing sparse file maps, and thus can save a lot of time while writing (depending on the image). Another interesting feature, you can give it a URL as an argument and it will download the image and then flash it all in one go. Not sure how it handles checksum verification in that case (or if it does at all). I had never heard of it before today, and have not used it yet. Heard about it while reading install instructions for PinePhone at Mobian wiki. I am thinking I might try it out to burn Mobian to an SD card here shortly. Apparently it's available in Debian as package bmap-tools. EDIT: I am not sure if this is available on Windows or not. I forget that was one of the original criteria, as this is irrelevant for me, personally. But I know the topic is about something which can be recommended for Armbian users overall. EDIT2: OK, I found what I was looking for about checksums a little further down (under "Usage scenarios" section): So, there is no direct checksum verification of the downloaded file (AFAICT), however their special bmap file format (which is some XML) includes checksums of the actual original contents, which are checked against the final written result.

Thank you for the kind words. They are always appreciated. I just did the same for a friend's laptop I installed GNU/Linux on. Since he is new to it and (much) less technically inclined than myself, I was almost certain he will need me to remote in at some point to help him with some problem or another. A (perhaps?) little known fact is that WireGuard can do NAT "for free" if you set PersistentKeepalives on the remote end, and you have a fixed URL / IP address (or a DNS update service) at your end. Which it sounds like you have (same as I do). In our case, we decided to manually bring the interface up and down as needed. I made sure to write down the exact command for my friend, saved locally on his machine in a text file, should that ever be necessary. But if you want even easier, you could set the interface up as a systemd service to be on all the time. At the "cost" of sending keepalives all the time. If you are feeling frisky, you are welcome to submit a PR for that.

I started playing with my PinePhone last night. It's KDE Community Edition, so out of box it comes with Manjaro KDE installed (which can be changed of course) and the KDE logo on back cover plate. Probably would not have been my first choice, but I just wanted whatever was available at the time. I gave Manjaro KDE a fair shake I think. From what I have been reading / watching, it has apparently come a long way in the last few months. It definitely looks/feels like KDE (I used to use KDE when I first came to GNU/Linux). I thought it actually looked quite nice (but maybe I had just set my expectations very low, lol). Button presses don't always register though (could be hardware related for all I know) and there are some times some slowdowns, so I think I am going to try a different OS. My understanding is a lot of people saying Mobian w/ Phosh is the way to go currently. The cool thing is, you can pop in an SD card, and that will be preferred over internal eMMC when booting. So, you can essentially experiment with new OS whilst leaving main one intact. So I will probably do that with Mobian, as I am Debian guy anyway (as soon as I tried to do apt update in Terminal and it didn't work, I was like "Oh yeah this is Arch based, screw this!"). Maybe some day I play with Arch and learn it, I just don't have the time right now.

I know it's a bit old thread, but I just came across it. Whatever software/packages are available in Debian, should be available in Armbian, too. In other words, I would suggest to investigate why (or why not) the package you seek is not in Debian itself. Armbian is handling more low-level, board specific stuff (for the most part).

A great start to the weekend! Cheers! Armbian can do... almost anything you want / are capable of setting up... Enjoy!

Yeah, that ought to be plenty for that little board. Well, that's the two most common things. I must admit, I am scratching my head a bit at the moment. Small possibility that something broke in recent development / kernel? If that's the case, someone else ought to be along shortly, adding to the chorus. EDIT: If you want to try eliminating above as a possibility, maybe try with previous image (click "Archived versions" at bottom of Download page)?

Board is CSC (no Support), so I moved to Peer to Peer forum.

I was going to suggest attaching a serial cable. I don't own this board, so I took a quick peek at it and realized there is no HDMI or anything, so I am assuming you are already doing that. In which case, I am not sure how to proceed next. How are you powering it?

Are you sure you need to containerize the WireGuard installation? Because WireGuard should basically "just work" in recent kernels...

Were you using same SD card on your successful boot(s)?

Suddenly it makes sense what I read in the recently published March Update: Status Report:

I do not speak for devs, but it seems to me like a lot less effort goes into legacy than mainline (generally speaking). As mainline is the future, more open, more maintainable, etc. It really boils down to whether someone wants or has time to do it. Because of above considerations, that answer is often (but not always) "no."

This is why I personally have disdain for RPi / Broadcom. IMO companies who are riding the current wave of popularity of "open source", whilst being actually nothing of the sort, I just find obnoxious (and actually, sociopathic, even). I also don't like that RPi seem to have become synonymous with SBC, in the mind of many casual users. You hear RPi being mentioned all the time on the broader Internet (I don't think we should be giving such mindshare / free advertising to such a closed platform). So to me it was actually like a breath of fresh air to find this community, where people weren't "drinking the Kool-Aid" so to speak.

You sure it halts? I have this problem on some laptop (haven't figured it out yet). But if you wait a long time, it will get past it. Annoying, I know, but...

You could always flip a coin. Jokes aside (and Reading your OP again carefully) you did state that you lean towards ZFS. Which I do too, personally. Anyway, I can tell you that running ZFS on Armbian have become significantly easier lately, as all the excitement around it got Igor working on it and I am pretty sure the relevant bits are built into the kernels that Armbian are shipping these days. And this was not the case even just a few months ago (it was just being worked on around the time of the above linked post in fact). As that seemed to be your main objection, I am not sure if that fact alone is enough to finally nudge you to decide in that direction or not. FWIW, I am planning a ZFS build finally, based on ROCKPro64 and a SATA board which I read reports of working well. I would just recommend doing your homework, especially around related hardware, and how well supported it is in Linux.

I guess in my mind, the notion of starting to play around with SBC (especially headless)[0] without wanting to learn how to do it "the old fashioned way" in plain vanilla Debian, via terminal, etc... I just find bizarre! But I guess I will just have to take your word for it. In fact, I always considered the fact we try to stick as close as possible to plain Debian (/Ubuntu) as one of the main selling points. For me anyway, the further things get away from those standard tools, the less I like them. Am I alone in this? Well, sorry for the noise. Hopefully if we break this project up into some manageable bits as discussed, I will be able to contribute one or two little pieces at some point. I guess I better get to looking at the existing code, as I never have even used the software, much less dug into the code yet. [0] Which Armbian have been more so historically, although changing recently with more desktop stuff and support things like PineBook Pro, etc.