Jump to content


  • Posts

  • Joined

  • Last visited

Community Answers

  1. TRS-80's post in How often should fstrim be run on an SD card to help lengthen its lifespan? was marked as the answer   
    Previous estimate I totally pulled from my rear end, because I have no idea. 
    But sounds like maybe a little more often than I was thinking.  Probably whatever system default is doing is likely fine, unless you really know what you are doing and/or have some reason for changing it?
  2. TRS-80's post in Odroid HC4 - linux headers not found Armbian Buster was marked as the answer   
    Are you sure you need to containerize the WireGuard installation?  Because WireGuard should basically "just work" in recent kernels...
  3. TRS-80's post in put stable image as pinebook-a64 image, because now it displays nothing after kernel starts was marked as the answer   
    To be honest this has been bothering me ever since your OP.  FWIW I had put this in my own personal issue tracker to follow up on until now.
    So when some discussion came up today in IRC about this, and another user confirm that it's working again (I specifically ask him about screen), it made me think about this again.
    I know it's stated in other thread you linked already, but apparently there was some issue with newer kernel, and therefore PineBook A64 was rolled back to legacy (5.4.y) in the meantime, which works well enough apparently.  As I am sure you are aware by now.
    However I realize your OP was more about the term "Supported" on the download page.  I think misunderstanding may have come from not understanding what "Supported" means in terms of Armbian, so I will try to expand a bit on what has already been written at that link.
    Supported is a more general and longer term condition, based on a lot of factors mentioned in linked article above.  And so, just because something breaks (even something so important as display on a laptop) does not mean that device suddenly becomes "not Supported."  If situation were impossible, or constant breakage, etc. then that would be a different story.
    So I hope I help clear that up a bit and again I thank you for your concern and your report.  Cheers!
    I am taking the liberty to mark my own post as solution in this case.
  4. TRS-80's post in Access GPIO from Python3 as non root on a Rock Pi S (5.9 kernel) was marked as the answer   
    There is https://github.com/vsergeev/python-periphery which is somehow related to https://github.com/sgjava/java-periphery, the developer of the latter (@sgjava) is regular around here and I know at least his software is actively developed.
  5. TRS-80's post in Possible to add ksmbd? was marked as the answer   
    Userland (apt, packages, etc.) is all Debian (or Ubuntu, depending on what you install).  Armbian is focused on low level stuff particular to these little boards (boot, kernel, dtb, firmware, etc.).
    So, I imagine you would have to petition some Debian maintainer, or the ksmbd project directly?
    I am Debian user, but still not to the point of packaging, yet.  I suppose it's only a matter of time...  But I digress.
    Anyway, that might take a while.  In the meantime you could build it yourself, looks like...
  6. TRS-80's post in Image corrupted - Odroid HC1 / HC2 / MC1 was marked as the answer   
    Use regular `shasum` command (here with `--check` option):
    $ shasum -c Armbian_20.08.1_Odroidxu4_buster_legacy_4.14.195.img.xz.sha Armbian_20.08.1_Odroidxu4_buster_legacy_4.14.195.img.xz: OK  
  7. TRS-80's post in Kernel education needed was marked as the answer   
    I think your assessment of that page is pretty spot on.  I started working on improving the docs recently, so I will add this to the list.
    I could swear I read this somewhere before, but I will try and give a brief summary (and if nothing else, use it as genesis for improving docs):
    Legacy is the kernel that comes from the mfr at the time the board is released.  Some times it can include certain drivers (particularly multimedia) that can make it better for certain use-cases (i.e., desktop).  Some times, with passage of time, the kernel gets older and older for various reason (some times not receiveing good ongoing support from the mfr, poor documentation so community can not write F/LOSS drivers (and thus get them into mainline kernel), etc.).
    Current is based on current mainline kernel, and therefore includes whatever is supported in mainline.  This is best for long term support, and things which have good F/LOSS drivers (or even good docs from mfr) will often end up well supported here for a long time.  However until all that is working well there is some period of time where you might be better off on Legacy (and particularly for certain use-cases).
    Which is better for someone's needs?  Hopefully you can appreciate it's not such a clear cut decision.  It also varies per board and over time.  Hopefully that was at least a little bit helpful, I will work on polishing that up and getting it back into the docs.
    Whatever is on the download page for a particular device is the currently recommended kernel to use.  This is periodically re-evaluated, but basically it is the current consensus of developers what to recommend at this time.  And so, this is why Werner is recommending that one.  If they are not recommending 5.x current, there is probably some reason for that.  But you would have to go digging through some threads to find out why (FWIW, I also have an ODROID-XU4 and I am not even sure the full reasoning).  Having said that, maybe you try 5.x and it works great for you.  If so, please report back your findings.  Make sure and back up any important data (as always).
    These Single Board Computers (SBCs) are quite a niche (and complicated) area within the broader GNU/Linux community, and a lot of what is done here at Armbian is quite cutting edge.  I really do not think you will find better support (for SBCs, at least) within the broader community.  Fact is, without Armbian, we would actually even be much worse off (if you can believe that).  I don't think it will probably ever be anything like a MacOS sort of experience, but I agree some things could surely stand improvement.  Which is why (personally) I try and contribute what and where I can.  Because I really enjoy these little devices.  There is no company, no business model, no nothing behind Armbian.  Just a handful of interested hackers and frens spread all over the world.  I'm actually amazed some times we accomplish what we already do on such limited resources.  But that is the reality (to keep things in perspective).
  8. TRS-80's post in Tried upgrading from slightly older (4.19.62) kernel on Cubietruck, now won't boot was marked as the answer   
    In the end, I had to dd the u-boot into place (I got the location from sunxi wiki):
    # dd if=u-boot-sunxi-with-spl.bin of=/dev/mmcblk1 bs=1024 seek=8  
    I got the file from https://apt.armbian.com/pool/main/l/linux-u-boot-cubietruck-current/ (of course, if you are reading later, yours may be different).
    The advice here was very helpful.  But I still would have never got there without a little help in IRC.
    Special thanks to @Igor, @lanefu, @TonyMac32, and @archetech, who all helped me in one way or another.  Cheers (I am actually having a cold one right now)! 
  • Create New...