TRS-80
-
Posts
768 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by TRS-80
-
-
2 minutes ago, lanefu said:
How's that been working for you?
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.
4 minutes ago, lanefu said:What SATA card are you using?
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?).
-
16 hours ago, Igor said:
slightly more recent ZFS version which could be good, could also be bad
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.
-
17 hours ago, dippywood said:
@TRS-80(it seems that you might be a good person to ask) I note that, in the first post, this has been flagged as having a board that is not on the list - this board is the Sopine A64 compute module, which is intended for use in the 'baseboard' and the 'clusterboard' The Sopine A64 is explicitly listed as supported. Is it that this compute module is only supported when used with the baseboard? It seems as though the clusterboard has been supported until now, with changes having been made to support networking just recently
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-linuxNote: 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:
Spoilertrs80@rockpro64:~$ sudo apt -t buster-backports install zfs-dkms zfsutils-linux Reading package lists... Done Building dependency tree Reading state information... Done The following additional packages will be installed: libnvpair3linux libuutil3linux libzfs4linux libzpool4linux Suggested packages: debhelper nfs-kernel-server samba-common-bin zfs-initramfs | zfs-dracut Recommended packages: zfs-zed The following NEW packages will be installed: libnvpair3linux libuutil3linux libzfs4linux libzpool4linux zfs-dkms zfsutils-linux 0 upgraded, 6 newly installed, 0 to remove and 60 not upgraded. Need to get 4,094 kB of archives. After this operation, 23.3 MB of additional disk space will be used. Do you want to continue? [Y/n] Get:1 http://deb.debian.org/debian buster-backports/contrib arm64 libnvpair3linux arm64 2.0.3-1~bpo10+1 [57.4 kB] Get:2 http://deb.debian.org/debian buster-backports/contrib arm64 libuutil3linux arm64 2.0.3-1~bpo10+1 [56.4 kB] Get:3 http://deb.debian.org/debian buster-backports/contrib arm64 libzfs4linux arm64 2.0.3-1~bpo10+1 [220 kB] Get:4 http://deb.debian.org/debian buster-backports/contrib arm64 libzpool4linux arm64 2.0.3-1~bpo10+1 [1,065 kB] Get:5 http://deb.debian.org/debian buster-backports/contrib arm64 zfsutils-linux arm64 2.0.3-1~bpo10+1 [464 kB] Get:6 http://deb.debian.org/debian buster-backports/contrib arm64 zfs-dkms all 2.0.3-1~bpo10+1 [2,231 kB] Fetched 4,094 kB in 0s (11.8 MB/s) Preconfiguring packages ... Selecting previously unselected package libnvpair3linux. (Reading database ... 66267 files and directories currently installed.) Preparing to unpack .../0-libnvpair3linux_2.0.3-1~bpo10+1_arm64.deb ... Unpacking libnvpair3linux (2.0.3-1~bpo10+1) ... Selecting previously unselected package libuutil3linux. Preparing to unpack .../1-libuutil3linux_2.0.3-1~bpo10+1_arm64.deb ... Unpacking libuutil3linux (2.0.3-1~bpo10+1) ... Selecting previously unselected package libzfs4linux. Preparing to unpack .../2-libzfs4linux_2.0.3-1~bpo10+1_arm64.deb ... Unpacking libzfs4linux (2.0.3-1~bpo10+1) ... Selecting previously unselected package libzpool4linux. Preparing to unpack .../3-libzpool4linux_2.0.3-1~bpo10+1_arm64.deb ... Unpacking libzpool4linux (2.0.3-1~bpo10+1) ... Selecting previously unselected package zfsutils-linux. Preparing to unpack .../4-zfsutils-linux_2.0.3-1~bpo10+1_arm64.deb ... Unpacking zfsutils-linux (2.0.3-1~bpo10+1) ... Selecting previously unselected package zfs-dkms. Preparing to unpack .../5-zfs-dkms_2.0.3-1~bpo10+1_all.deb ... Unpacking zfs-dkms (2.0.3-1~bpo10+1) ... Setting up libnvpair3linux (2.0.3-1~bpo10+1) ... Setting up zfs-dkms (2.0.3-1~bpo10+1) ... Loading new zfs-2.0.3 DKMS files... Building for 5.10.21-rockchip64 Building initial module for 5.10.21-rockchip64 Done. zavl.ko: Running module version sanity check. - Original module - No original module exists within this kernel - Installation - Installing to /lib/modules/5.10.21-rockchip64/updates/dkms/ znvpair.ko: Running module version sanity check. - Original module - No original module exists within this kernel - Installation - Installing to /lib/modules/5.10.21-rockchip64/updates/dkms/ zunicode.ko: Running module version sanity check. - Original module - No original module exists within this kernel - Installation - Installing to /lib/modules/5.10.21-rockchip64/updates/dkms/ zcommon.ko: Running module version sanity check. - Original module - No original module exists within this kernel - Installation - Installing to /lib/modules/5.10.21-rockchip64/updates/dkms/ zfs.ko: Running module version sanity check. - Original module - No original module exists within this kernel - Installation - Installing to /lib/modules/5.10.21-rockchip64/updates/dkms/ icp.ko: Running module version sanity check. - Original module - No original module exists within this kernel - Installation - Installing to /lib/modules/5.10.21-rockchip64/updates/dkms/ zlua.ko: Running module version sanity check. - Original module - No original module exists within this kernel - Installation - Installing to /lib/modules/5.10.21-rockchip64/updates/dkms/ spl.ko: Running module version sanity check. - Original module - No original module exists within this kernel - Installation - Installing to /lib/modules/5.10.21-rockchip64/updates/dkms/ zzstd.ko: Running module version sanity check. - Original module - No original module exists within this kernel - Installation - Installing to /lib/modules/5.10.21-rockchip64/updates/dkms/ depmod... DKMS: install completed. Setting up libuutil3linux (2.0.3-1~bpo10+1) ... Setting up libzfs4linux (2.0.3-1~bpo10+1) ... Setting up libzpool4linux (2.0.3-1~bpo10+1) ... Setting up zfsutils-linux (2.0.3-1~bpo10+1) ... insmod /lib/modules/5.10.21-rockchip64/updates/dkms/spl.ko insmod /lib/modules/5.10.21-rockchip64/updates/dkms/icp.ko insmod /lib/modules/5.10.21-rockchip64/updates/dkms/zavl.ko insmod /lib/modules/5.10.21-rockchip64/updates/dkms/znvpair.ko insmod /lib/modules/5.10.21-rockchip64/updates/dkms/zcommon.ko insmod /lib/modules/5.10.21-rockchip64/updates/dkms/zlua.ko insmod /lib/modules/5.10.21-rockchip64/updates/dkms/zzstd.ko insmod /lib/modules/5.10.21-rockchip64/updates/dkms/zunicode.ko insmod /lib/modules/5.10.21-rockchip64/updates/dkms/zfs.ko zfs-import-scan.service is a disabled or a static unit not running, not starting it. Processing triggers for libc-bin (2.28-10) ... Processing triggers for systemd (241-7~deb10u6) ... Processing triggers for man-db (2.8.5-2) ... Processing triggers for initramfs-tools (0.133+deb10u1) ... update-initramfs: Generating /boot/initrd.img-5.10.21-rockchip64 update-initramfs: Converting to u-boot format trs80@rockpro64:~$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!
-
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-linuxAnd 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.
-
2 hours ago, soerenderfor said:
what about
apt install spl-dkms zfs-dkmsit it fails you can check the status with
dkms statusYou 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...
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/bindAfter 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):
QuoteFor the record, Debian unstable now supports the Marvell 88SE9235, so I expect the 9230 is probably supported as well. Tested with kernel 5.7.10. No custom udev rule required.
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.
-
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.
4 hours ago, @lex said:* Would you know if it is possible to have access and use the UART to interface with some peripherals? I know there is an extension with HDMI, ethernet and USB. I don't mean USB to Serial.
* Can you stick a barcode reader, or something similar like a proximity reader (if you have that extension)?
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.
4 hours ago, @lex said:* Last time i checked (was really long time ago) there was no HW acceleration. today there is A64 HW in kernel 5.x , how is the status?. I know GNOME is a bit slow but maybe with HW accel it would be great.
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.
4 hours ago, @lex said:* rebuild Mobian w/ Phosh image and provide some inside info and what is needed?
* Disclose the blobs that are still needed?
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.
4 hours ago, @lex said:I was expecting to see a similar device but with rockchip inside.. and then join the club.
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):
QuoteThe additional benefit of using bmap for flashing is the checksum verification. Indeed, the "bmaptool create" command generates SHA256 checksums for all mapped block ranges, and the "bmaptool copy" command verifies the checksums while writing. Integrity of the bmap file itself is also protected by a SHA256 checksum and bmaptool verifies it before starting flashing. On top of this, the bmap file can be signed using OpenPGP (gpg) and bmaptool automatically verifies the signature if it is present. This allows for verifying the bmap file integrity and authoring. And since the bmap file contains SHA256 checksums for all the mapped image data, the bmap file signature verification should be enough to guarantee integrity and authoring of the image file.
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.
12 hours ago, Mindaugas Idzelis said:My main project/use-case is ... I need a surefire way to remote access/login to my in-laws router/network, in case it malfunctions. Problem is they are behind a CNAT, and do not have publicly routable ip addresses.
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.
12 hours ago, Mindaugas Idzelis said:but maybe at least add a note to the download page
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)?
pine64: massive date/time clock problem
in Pine A64
Posted
Armbian is doing many things to get stuff to work, fix bugs, etc. In fact that is one of the primary raisons d'être for Armbian in the first place, as well as one of the main differences between Armbian and Debian/Ubuntu.
Insofar as running GNU/Linux on SBCs goes, Armbian is likely your best bet, unless you really want to start digging deep into kernel patches and other stuff like that. Sorry if you are a Fedora guy, but other distros (including upstream mainline Debian themselves) are no where close to us in this regard, on SBCs anyway, due to all the various hardware and other peculiarities of these otherwise fascinating little boards...