TRS-80
-
Posts
768 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by TRS-80
-
-
7 hours ago, svenoone said:
Is there some update or a walkaround you know?
The current status last I read seemed to me that people are currently testing and looking for a solution. I think it's a regression introduced by newer kernel or something like that. You can find more info in this other thread which is about desktop however there seems to be a lot of RK3399 specific discussion starting at the post I linked.
Best thing you could do at this point is familiarize yourself with the discussion / issue, perhaps try and modify dtb and other things if you are capable, if not just follow along and give additional testing when more advanced users eventually post their solutions. Because the evidence becomes much stronger if testing has been done by multiple people to confirm results (instead of jut one person).
Also, if you don't own a UART yet, you probably should to get one (or more) on their way to you in the mail. They are only couple bucks apiece, and IMO anyone who play with SBC should own at least one!
EDIT: NicoD advice a few posts up (use legacy kernel) or Pedro Lamas' may be best in this case. I did not read it until after posting. Understand that as a Mod I read almost everything that is posted, so I end up with shallow (therefore sometimes wrong) understanding on a wide variety of topics. lol Don't mind me, carry on. Some of general ideas in my post still apply, however, so I leave those. Cheers.
-
I had two questions, which were mostly for my own education:
1. I don't see "Orange Pi Zero H2" listed at all on Downloads page for Orangepi, although I see several very similarly named boards (but no exact match).[0] Is OP's board same as "Orange Pi Zero 2" or one of the others? Or not?
2. Maybe dumb question, but how is it possible that kernel, drivers, etc. can be on mainline (latest kernel) but userspace would not work? In other words, why would upgrade from Stretch to Buster not be supported if "userspace is upstream Debian anyway" as I often tell people?
[0] This is one of things which drive me nuts about SBCs in general, there is often such similar naming which makes it at times confusing what board someone is referring to.
-
Well, FWIW I just asked in IRC if ssd are faster than sdcard, and one person said "yes" so, take that for what it's worth. From what you say though, it seems like there is also some consensus at HA forum about this. And if that's the case, maybe you do want to run the OS on the ssd after all?
Running OS on ssd would be for performance reasons then, I suppose. For what I do (light server type loads) I guess sdcard (or emmc) have been "good enough" for me, but maybe your use-case is different and maybe you benefit from that.
OTOH, there could be an argument made about whether you want to keep your OS and data separate. This is something I do on many of my GNU/Linux systems, in general (/home on one drive or partition, and / (root, OS) on another). This gives the advantage of being able to completely blow out the OS and start over from scratch, while not affecting your data.
So maybe this is is why you post. To discuss this tradeoff. If so, hopefully I give you some more things to think about.
I guess I learned something today. Thinking further, maybe the reason sdcard are more common is not because they are faster but rather that they are cheaper.
Let us know how it works out.
-
I mean, you can do whatever you like.
But I never had problems with my few boards with Armbian running on sdcard nor eMMC. However I make sure I take care of all important details like buying only certain brand name sdcards, and only from known good suppliers (which no longer includes Amazon, IMO), checking them thoroughly upon arrival, using good power supplies, etc...
Basically everything in Getting Started section of docs. Which I would hope you have read by now. We wrote those for a reason, you know.
I never tried running from SSD, nor saw the benefit of that (and usually prefer to save my few available SATA / USB slots for hooking up storage drives) so I would be interested to hear anyone else who does that or thinks it's a good idea. Now, I could be wrong, but my perception so far is that's not too common?
13 hours ago, metRo_ said:Since HA will run on a docker, could I just run docker from SSD and keep armbian on sdcard?
By default, Docker will run as a service by the OS, storing it's images on whatever media that the OS is installed on (usually in /var/lib/docker). Unless you were referring to the "volume" (persistent storage) for Docker being on your SSD. Which would also work. I don't know how much persistent storage HA needs, just some configs, right? I wouldn't think a lot.
Anyway to answer your question, something like this (Armbian on scdard) seems like a much more "normal" option to me. Where you want to put persistent storage for HA is up to you but in my mind it's just some config text files, so very small. And therefore I wouldn't want to waste a whole drive just for that. Unless you were talking about storage for your Docker images.
From your post, I suspect you had some problem with scdard corruption. Armbian do a lot of things to mitigate this (like writing logs to zram, etc.) to minimize wear on your sdcard. Maybe you know this already (and maybe this is why you decide to switch to Armbian) but if not, all of this info is also right there in the docs for you to study.
Having said that, sdcards do wear out after some number of years. So keep spare sdcards (also good for troubleshooting), make backups of your important data, etc. But these things always apply and are not particular to Armbian.
-
11 hours ago, scargill said:
or am I missing something
I think so.
https://forum.armbian.com/topic/6617-the-purpose-of-this-subforum/
-
1 hour ago, ASword said:
that was the latest build when I grabbed it
What you think we are doing around here? Playing around?!
-
On 11/30/2020 at 9:09 AM, jeanrhum said:
I don't see real questions in your post
Yeah just trying to get a cozy thread going.
I am still reading and studying about it. Which I tend to to extensively, perhaps to a fault even some times.
On 11/30/2020 at 9:09 AM, jeanrhum said:s912 tv box with a 4.20 kernel installed maybe two years ago (I don't remember exactly
):
Up time: 135 days
Amazing, I would never have thought such things were possible with one of (oft maligned) "TV Boxes"!
Well done! 
On 11/30/2020 at 9:09 AM, jeanrhum said:On my next install, I plan to use docker for several applications that I installed the classic way.
This is pretty much right where I am at, and mostly for all the same reasons. In addition I think I became convinced of the wisdom of viewing the services I am running as "cattle" and not "pets" as they say.
My current Cubietruck is definitely a "pet." Bespoke manual configuration, I spent a lot of time setting each of those services up, etc. Therefore to set that up all again would take a lot of time.
Now I think, well if I have service A, B, or C defined as containers, they are more like "cattle." They can die off and just be re-created. If one SBC (hardware) goes down, I just start the services on a different SBC.
Taking that philosophy to the next level, if I have some SBC at friend/family house, even if my Internet goes down, I could re-start services over there and just re-direct DNS. Potentially even automatically (i.e., failover). But that gets much more complicated, I am aware. So baby steps. But I am excited at possibilities of thinking in a different way.
On 11/30/2020 at 9:09 AM, jeanrhum said:they mainly failed on the stability criterion
By doing my homework and sticking with well supported devices (Cubietruck and ODROID-XU4, but there are others) I have had very good "luck." But I also take care of all important details like good brand name sdcards (or more recently, eMMC), well tested upon arrival, from known suppliers, high quality (Mean Well) power supplies, etc... In case all of that fails, I have multiple physical spares as well (not only for SBC, but all my "infrastructure"). You probably know all this. And I am still amazed at your "TV Box" results which fly in the face of everything I think "I know."
My issue is learning all this stuff, time and implementation. I only started with GNU/Linux around the time I bought my Cubietruck, so I think I came a pretty good way so far. Just time now I think to take it to next level which will be to start playing with containers.
I fired up my first container just the other day, the official Docker (which is now recommended) version of Tiny Tiny RSS. I was able to log in and add some feeds. It worked a treat and was a piece of cake. Last night I play around just launching containers with docker run and exploring shell in Alpine or other OS on command line. Real sh is a bit different for me, coming from bash. All those "bash-isms" I read about at Wooledge FAQ over the years coming back to bite me now.
But a lot of other things I want to do, I know will be more complicated. So I keep studying, and thinking about architectural decisions. And picking @lanefu brain when he's not too busy.
-
You have to replace the variable ${fdtfile} with the actual name of your... something.
I did not write those instructions (only edited them) but I think it is supposed to be... dtb file (maybe)?
-
-
Igor's comment was more directed at the others in the thread who are trying to solve this particular bugbear. In other words, mostly development talk.
There are lots of clues and instructions littered throughout these forums that will tell you how to get this working. However if you get too frustrated or can't figure it out, just wait a bit longer and eventually something will be released to make this "easier" for the average Joe.
-
First off, my apologies for not recognizing your friend / partner, the OP, @jtremblant.
32 minutes ago, Salvador Liébana said:we are tired of RPI4 fanatism while the hardware clearly sucks
Well that's great to hear! Welcome to the club!
32 minutes ago, Salvador Liébana said:if that isn't enough for you or fpr anyone else
It was never about that. Please take a step back and try to see it from my point of view as a Moderator on a forum where someone (who I never heard of before, apologies again to @jtremblant) post some binary for download without sources. This is even why I stated:
1 hour ago, TRS-80 said:This is not meant to impugn your efforts
1 hour ago, TRS-80 said:standard disclaimer
(emphasis mine) This is not the first time I point such things out, and it will not be the last I am sure.
I think we just got off on wrong foot, maybe could have been avoided if you made the announcement post yourself @Salvador Liébana, and/or @jtremblant would have been introduced to us in @NicoD post some days ago (and apologies again (third time now, lol) if that was actually the case and I just missed that part of it).
-
And now working again. I can see Technicavolous tag working now, too. Is my eye deceiving me, or are these the new ones you were working on? They look ever so slightly different (maybe)?
-
18 minutes ago, Salvador Liébana said:
we don't care if you don't like it
I made no judgement whatsoever about your distribution. Only warned people (most especially, "noobs") to be aware of what they are downloading, and from whom. Which always applies, to everyone (including Armbian itself, upstream Debian, or anyone else who distribute executable, compiled binaries).
Now, I only even heard of you what seems to me like a few days ago, after NicoD introduced you here. Because I don't follow "desktop / gaming" circles (but I know he does). Therefore forgive me if I do not recognize your apparent partner (OP) who made the announcement. Because in my mind, the only place I heard "Twister OS" mentioned was with your name attached to it.
18 minutes ago, Salvador Liébana said:pro user's like you
I am, at best, a solid low to mid level wizard.
-
This is not meant to impugn your efforts or anything, however I am personally not a big fan of random compiled images which are not verifiable in any way (I don't even see any hashes, much less reproducible source code). Also due to the latter, I am not sure how...
17 minutes ago, jtremblant said:feedback and contributions from other devs
...is supposed to take place?
Therefore the standard disclaimer applies: Individuals need to be very well aware of what they are installing on their systems, and ask yourself how much you trust the source of any executable code which might run.
-
On 11/30/2020 at 4:37 PM, Technicavolous said:
After my last post I noticed the cute little tag 'Donator' was missing from my avatar so I went to re-subscribe and it shows conflicting info - if I roll over the blue badge top right it shows 'Subscription active' but in red in the middle of the box it states 'Subscription expired'
Mine seemed to be fine until today, when I noticed exact same symptoms. Followed exact same steps, with exact same results.
Just letting you know.
-
2 hours ago, konki said:
I was of the same opinion but the absence of GNU Sed from the /usr/bin directory is very strange under debian.
sed is installed under armbian 20, but the binary is in the /bin directory.
┌─[ 2020-12-05 03:01 trs-80@host:~ ] └─▶ $ which sed /bin/sed ┌─[ 2020-12-05 13:01 trs-80@host:~ ] └─▶ $ dpkg --print-architecture amd64 ┌─[ 2020-12-05 13:01 trs-80@host:~ ] └─▶ $ lsb_release -d Description: Debian GNU/Linux bullseye/sid ┌─[ 2020-12-05 13:06 trs-80@host:~ ] └─▶ $ ls -al /bin | grep sed -rwxr-xr-x 1 root root 122224 Dec 22 2018 sed
-
Awesome news! Kindly report back after some more time and let us know if it's still running stable (and eventually, even if you disable your reboot cron job).
-
I liked the first title?
Anyway, you are on a roll today.
If I'm being honest, I thought the Pine Distro sponsorship was a bit gimmicky (and also infected with "social justice" nonsense) however giving away 1,000 boards to people (even if they are small and inexpensive) is still quite a nice gesture. Good marketing for them, anyway, and still a lot cheaper than hiring another dev...
All cynicism aside, if we end up with an actual blob free, small form factor, low power multi mode device, it will be a win-win. So maybe even brilliant on their part? I dunno.
-
Awesome project, I wish them all the best!
Although I think many of us (including OP) realize the extreme challenges that are involved.
The point (in my view) is not to take that as a sign not to try (as average person probably thinks) and to give up but rather to try anyway, in spite of those odds.
At first I wondered if they were related in any way to Libre-SOC but apparently not. This is certainly a nascent area, but there are several different projects going in this direction and all need to be applauded (and even IMO helped, by whatever means we are able).
Libre-SOC are also getting a lot of those nlnet.nl and EU grants. So maybe not just a pipe dream after all.
Cheers to our friends across the pond!
We are kindred spirits, although mostly covered up with our own work here, already.
-
4 hours ago, JMCC said:
How can a casual discussion in the "General chit-chat" subforum and a check in motd be turned into officially "encouraging users to rely on ZFS"?
Maybe that's the perception because I am a Moderator? And/or considered part of "the team" even though I only work on Docs, forum, writing, etc.?
And since it was apparently not already clear, opinions in this thread are my own, and do not represent any official Armbian project position.
The MOTD part, well I can't speak for @Igor however it looks to me like he is just trying to give the people what they want, as there have been a lot of clamoring about it by users (look in Kobol Club as there have been some number of threads and posts about it lately).
Anyway, it's always easy to stand on the side and throw rocks.
-
20 hours ago, tkaiser said:
btrfs lives inside the kernel
So does ZFS, essentially (the down low parts). The only reason it's built as modules or whatever is because of license incompatibility (CDDL) and because Linux kernel developers don't trust Oracle.
20 hours ago, tkaiser said:ZFS is most of the time used on more reliable hardware than btrfs and that's mostly due to [...]
Check which mainboards feature ECC memory and you'll realize that exactly those mainboards are the ones with proper onboard storage controllers. If you believe you need at least 8 GB of RAM this also rules out a lot of crappy hardware (like eg. vast majority of SBCs)
This is interesting. I am well aware of common urban myths you speak of, and I agree with you about them.[0]
However, are such myths the most important factor leading to using better hardware for ZFS? Or is ZFS documentation somehow better? Or...? I don't know.
But this is an interesting point, maybe you are on to something here.
20 hours ago, tkaiser said:you need a recent kernel version
20 hours ago, tkaiser said:Putting a btrfs on top of hardware raid, mdraid or lvm is as 'great' as doing the same with ZFS
20 hours ago, tkaiser said:Choice of hardware.
3 hours ago, tkaiser said:correct write barrier semantics [...] might be recipe for disaster with both ZFS and btrfs
3 hours ago, tkaiser said:confusing redundancy with backup
None of these things apply uniquely to ZFS, in fact they apply equally to both (as you even state yourself in many cases).
3 hours ago, tkaiser said:based on FUD (data losses with btrfs) or theoretical superiority '(the guys at Lawrence Livermore National Laboratory' for example)
I am trying to argue in good faith here. And I have read a lot of reports about data loss on btrfs. Therefore I would not characterize that as FUD. I have no reason to make that up. I (personally) have not seen the same sort of reports from ZFS users (even after quite a lot of reading on the topic).
My point (which you seem to have completely missed) was they have a lot of development resources behind them. I like how you conveniently also skipped over the fact that these are the original authors of ZFS from Sun. The fact they work now at LLNL was just connecting the dots for anyone who may be unaware of that fact (and making point they have lots of (government) funding behind them).
21 hours ago, tkaiser said:Which is the reason why the choice of filesystem (btrfs or ZFS) at my place depends on x86 (ZFS) or ARM (btrfs). And that's not because of the CPU architecture but solely due to with x86 being able to rely on professionals who take care about the updates they roll out vs. situation on ARM with a team of hobbyists
3 hours ago, tkaiser said:Btrfs [...] receives a lot more testing than the ZFS situation at Armbian allows for
Well, unlike you I don't feel the need to get my digs in on handful of people who I know personally who are trying to make things better by improving the situation in whatever way they can, working with very limited resources. But, manners aside, the facts are essentially: you are making same argument I made above about resources going into development. In case of ZFS on x86 that's quite a lot. And much less so on ARM currently (that I am aware of, I am not actually sure who is working on this specifically, nor how much of a priority it is for OpenZFS project, so maybe I start following that more closely again now, as the time seems right for it).
I agree it's very early days for ZFS on ARM. Which is why I suppose, that for all my interest and arguments in favor of ZFS (in general), I personally am still not running it on any ARM devices, either. Because I suppose that, deep down, my gut feeling has still been that we are not quite there yet. And I guess, now that I think about it, it's for same reasons as you point out (resources in development). In fact the situation on ARM is flip side of (development resources) coin that I made in favor of ZFS (in general).
[0] Lots of RAM is only needed for de-duplication, and you will still be better off with ZFS with no ECC than traditional filesystem, anyway, as at least now you will be more often aware of data corruption. ECC only brings this to even higher levels of reliability, but we are now talking about difference between (~) very^4 reliable and very^5 reliable level (or whatever).
-
I guess I could be (sort of?) considered a "CLI fan boy."
But I became this way after having enough of being frustrated by limited "off the shelf" and/or GUI options. Which you seem to be also, although apparently not enough to quite push you over the hump of learning something new.
You correctly point out that it is an investment of time, perhaps one you are unable to make currently. Fair enough. I used to be on the hamster wheel, too. But that's the tradeoff. What do you value more, your freedom/independence, or your time? It's quite personal and subjective and there is no "right/wrong" answer. Right now it seems you value your time and you are certainly not in the minority in that calculation in the broader population (technical forums like ours perhaps more being the opposite).
As far as forgetting things, even as a "CLI fanboy" I take extensive notes[0] on many of the things I do, especially those which are new to me or that I also seem to never be able to remember. Which I think is just good practice in general, but especially in technical disciplines.
[0] I really like Orgmode in Emacs for taking notes, but if you are throwing terms around like "CLI fanboy" then Emacs might not be for you.
-
You know, I take a lot of notes, but not always. So I am not 100% sure of following, however if I am recalling correctly, in one of NicoD videos where he goes through all his boards, the Odroid N2+ he says is very powerful (maybe even the most powerful?). but limited on I/O. And maybe that's what you were hinting to about USB, @lanefu?
And this is what I mean by "little gotchas." Also I want to make the point that there probably is no clear "best" as it depends a lot on your application, etc.
Also just now looking up the above video to get URL I came across another video (which I don't think I watched yet) called Comparison NanoPi M4 - RockPi4 - Odroid N2 - Khadas VIM3 which is perhaps even more directly applicable to this conversation.
-
I am guessing you mean for "desktop" usage (many of us, including myself, primarily only use Armbian for "server/headless" usage).
@NicoD has some great video reviews on his YouTube channel, I want to say (if I am recalling correctly) his favorite right now for desktop usage is... NanoPi M4 V2(?) but check his channel to be sure (and check it anyway, lots of good info on there).
@lanefu was reporting really good results with a PineBook (Pro?) the other night in IRC, but that might be WIP/dev stuff, so not sure it's public/available yet or not. But in general, a lot of work has been done lately on "desktop" branch and should be getting released Soon(TM).
Many of these boards are compelling, however the best advice I can probably give you is to do your homework, as there are potentially little gotchas with any particular board. The more time you spend up front researching, the less hassle down the line.
A good starting point is usually always the Supported Devices List, but for "desktop" you are probably looking for one of the RK3399 based boards these days. Until you know the board families by heart, the home page of forums makes a handy cross reference (note which boards are listed for which family sub-forums).
Good luck, let us know how the search goes / what you pick, and don't be a stranger.
u-boot- files location.
in Amlogic CPU Boxes
Posted
I am posting because I can empathize with your frustration, so please take this in the way it is intended (a constructive hint, even if not directly related to the issue you are trying to solve).
So now perhaps you guys start to understand why TV Boxes are not officially supported. Because getting them to work can be "an adventure" to say the least.
I wish you both the best of luck, sorry I don't know any more specifics which might be directly relevant.