Igor

Apparently we have fix it, but we have no time to test properly - autotest facility is developing too slow:
https://github.com/armbian/build/commit/a84c69ddea886172b7aa876793dc561487c2e538
Also making just a few images is only half automatic ... in the following days. You can build from sources and it should work.

That is expected. We don't support P1.
 
In the making
https://github.com/armbian/build/pull/2508

This problem should be fixed by now.
 
One of our mirror is "Kubernetes Native, High Performance Object Storage Amazon S3 compatible" and there we had to use different sync method. We also synched from there further since host has a fast connection ... 
 
tl;dr; Wrong sync parameter 

This problem should be fixed by now.
 
One of our mirror is "Kubernetes Native, High Performance Object Storage Amazon S3 compatible" and there we had to use different sync method. We also synched from there further since host has a fast connection ... 
 
tl;dr; Wrong sync parameter 

DEV version is fixed now / new u-boot. Need testing on other boards ... 

Didn't know that we support it  But yeah, nice toy.

1. Probably works, but elsewhere was always a lottery / unsupported.
2. Try. I didn't.
3. Once we will support this type of building, we will ship what's needed. Currently this is still formally in development and it doesn't have high priority. Desktop has. We are aware that certain things doesn't work at all.
4. Desktop and native arm building is still months to go to reach v1.0 / user level. We plan to merge support in 1/2021 but only XFCE setup will be officially supported. Further official support will remain dependent from community involvement. We expanded that tool can handle desktops pretty easy, but maintaining more than 1-3 configurations is not planned / not possible. We are also considering partnership with desktop designers, which could develop this further. Our focus was not to provide good looking desktops with top UX. We actually didn't do anything about that ... we were focused only on a framework which now supports much easier desktop development ...
 
Building latest trunk Ubuntu userland is related with a great portion of luck and its most likely not related to our build engine. There are no plans nor resources to support Canonical beta userland development. Official Armbian support will be tied to stable / LTS versions as we do it since ever.

https://blog.popcorncomputer.com/2020/12/22/perfecting-pocket-p-c/

Corrected. Merry Christmas!

Enviado desde mi moto g(6) plus mediante Tapatalk

I'm currently in contact with maintainers of this driver "at803x" - the first assumption that just a single line regarding the device ID (see my post above ... modules.aliases, which btw is created by depmod) was missing in the driver source was (unfortunately) wrong. The driver for this device has been widely reworked from 5.7.x (rather simple, only recognizing AT8030 and AT8035) to 5.8.x (now rather complex and supporting much more devices from that family beyond 8030/8035) - 
Another finding was that NOT ALL cuboxes are impacted -  already reported by Igor that his regression box is still ok.
From my collection 2 out of 3 are working ok also with 5.8.x kernel and higher
This one has issues (stopped working after upgrade to 5.8.x)
SolidRun i4P TV-300-D
while these are still working
SolidRun 4x4 300-D 
SolidRun i2EXW 300-D 
if the (last 3 bytes from) MAC address is just incrementing during production then the one box having issues is in between the two which are working - 
The two which are working have WiFi and the one which has issues does not -  but that does not fit to the post above from "Armbian User" who reported issues on a WiFi version
 
There might be one more thing
find /sys -name phy_id
/sys/devices/platform/soc/2100000.bus/2188000.ethernet/mdio_bus/2188000.ethernet-1/2188000.ethernet-1:00/phy_id
reported on the systems which work (on 5.8.x and beyond)
while my system which breaks reports
/sys/devices/soc0/soc/2100000.bus/2188000.ethernet/mdio_bus/2188000.ethernet-1/2188000.ethernet-1:04/phy_id
which has two differences:
after /devices/ we see /soc0/ instead of /platform/
and further in the path
/2188000.ethernet-1:04/ instead of /2188000.ethernet-1:00/
device tree seems to be the same for all 
there are small differences - and these seem to matter - 
 
if someone still reads this post ... and wants to contribute ... and has a system which broke from upgrading 5.7.x > 5.8.x *kindly check on your system* and post results here - for
find /sys -name phy_id
 
which is always an important part of troubleshooting to sort apart systems which still work and those which break - and to find reliable criteria which belongs to which group

Hello.
 
@ Igor
I'm sorry if I wasted your time with my first post. That wasn't my intention. I have great respect for the work you are doing here and I am very grateful for that. I can already find out from the article that there is a problem in the kernel so far. I just wanted to confirm that my Orange Pi 3 is the same. That may have been stupid of me. I'm sorry.
 
@ Werner
Thank you for the info!
I'm switching back to a system with kernel level 5.8, and I'm waiting for development.

Got the info that on stock debian, this /usr/bin vs /bin mess is normally handled by debootstrap, but the `usrmerge` package can be installed to "fix" an existing debian system.

Because mainline kernel is a RAW generic material which we use, make certain (actually quite a lot of - we deal with base development) changes, add certain boards to it and distribute. Integration and acceptance to mainline kernel takes a lot of time and many things are never accepted / integrated. While they can be a part of Armbian for weeks, months, years. It's our burden of maintaining and advantage at the same time. The same goes for u-boot.
 
All changes are public and you can study them in the following folders:
 
kernel
https://github.com/armbian/build/tree/master/patch/kernel
https://github.com/armbian/build/tree/master/patch/misc
https://github.com/armbian/build/blob/master/lib/compilation-prepare.sh
https://github.com/armbian/build/tree/master/config/kernel
 
u-boot
https://github.com/armbian/build/tree/master/patch/u-boot

Because mainline kernel is a RAW generic material which we use, make certain (actually quite a lot of - we deal with base development) changes, add certain boards to it and distribute. Integration and acceptance to mainline kernel takes a lot of time and many things are never accepted / integrated. While they can be a part of Armbian for weeks, months, years. It's our burden of maintaining and advantage at the same time. The same goes for u-boot.
 
All changes are public and you can study them in the following folders:
 
kernel
https://github.com/armbian/build/tree/master/patch/kernel
https://github.com/armbian/build/tree/master/patch/misc
https://github.com/armbian/build/blob/master/lib/compilation-prepare.sh
https://github.com/armbian/build/tree/master/config/kernel
 
u-boot
https://github.com/armbian/build/tree/master/patch/u-boot

I decided to go through the tutorial from Digital Ocean and it works! Thanks guys. 
I got a domain name from dynu.com as well which I pointed towards my Helios Ip address as a A record. 
 
Now, I struggle to get a SSL certificate with Let's Encrypt. It says "no valid IP addresses found"
I am following the commands from Digital Ocean Tutorial.
 
I do manage to access my NextCloud account on Safari despite the warning. Chrome on the other hand does not allow it. 
 
any idea on how to sort it out? 
 
I decided not to go with Docker but maybe I should have done that instead and use certbot. 
 
Should I redo my setup with Docker then? 
 
 
 
Edit: I realized that since Helios4 only supports 32bit. I will not be able to install docker anyway... 

change of .dtb (activating 1c22000) & creating overlay (armbian-add-overlay ./sun8i-h3-I2S-out.dts) does also work on 
uname -a Linux npi-neo-25 5.10.0-sunxi #trunk SMP Wed Dec 16 17:45:03 +03 2020 armv7l GNU/Linux package bsp-kernel[21.02.0-trunk] u-boot[21.02.0-trunk] dtb [21.02.0-trunk] firmware [21.02.0-trunk] config[21.02.0-trunk] branch[dev] like before on kernel 5.9.0

Well, you guys here in this thread do seem to "get it" and I for one certainly appreciate that.  And in fairness, probably even the majority do.  However, and unfortunately, a few others do not.  And that just wears on Igor after a while.  He is only a human bean like the rest of us, after all.
 
In fact that is one of main reasons I try and help out around forums, to try and relieve some pressure from devs by not only taking care of some "low hanging fruit" type issues, but also some times act as some sort of buffer.  Because I see both sides of the issue.  And I really worry that Igor will have enough one day and quit.  I have seen it too many times over the years in F/LOSS projects.  And then, well, "this is why we can't have nice things." 
 
If anyone would like to assist me in this task, it would be enough to simply scan forum's "All Activity" stream and reply anywhere you think you can help.  Currently I am doing this at level of part time job (many hours every day) however I have the luxury of taking a break from regular "work" at the moment.  All of that comes to an end after the first of the year however as I need to go back to making money...  However my hope is a few other people will step up and "with many hands make light work" but that is perhaps only wishful thinking on my part...
 
So yes, the forums (to my understanding) were designed as a sort of middle ground, "bug reporting" area, and place where users can help one another until devs can get around to particular issues.  Therefore please continue to do those things.
 
I guess all we can do is continue to try and set realistic expectations in the meantime.  I have for instance seen threads go un-answered for months, years even before achieving resolution.  And a lot of people (especially nowadays) seem to have some sort of "instant gratification" mentality.  Not you guys.  Just talking in general.
 

Is there someone experienced in ZFS building around? We would like to include support directly to the kernel but troubles doesn't want to go away https://github.com/armbian/build/pull/2414

Tnx.  https://armbian.atlassian.net/browse/AR-584

I've been having this problem off and on for a while now as well.  The only solution that I found is simply to wait longer until more mirrors are updated and hope that one of the updated ones is selected.
 
@IgorHave you tried this: https://apt-mirror-updater.readthedocs.io/en/latest/readme.html
I realize it's still in beta but it may be worth testing.

IT'S FINALLY HERE...

THE OFFICIAL ROCKCHIP-LEGACY MULTIMEDIA INTEGRATION
 
After two years of using a separate script to enable the multimedia features in RK3399 Legacy Kernel, the whole framework has been incorporated to the official Armbian packaging system. The choice distro for this integration is Debian Buster (see FAQ at the end of this post about the reasons).
 
I. Installation
Download a Armbian Buster Legacy Desktop image for your board, and install it with the standard Armbian method. Install the complete multimedia solution with sudo apt update && sudo apt upgrade sudo apt install media-buster-legacy-rk3399 --install-recommends The switch "--install-recommends" will add the whole Kodi binary addons collection (retro-gaming cores, music visualizations, screensavers, additional media decoders/encoders, vfs, etc.), plus the GLES-to-OpenGL wrapper "gl4es".
 
II. Features
Accelerated GLES/EGL X desktop: No action needed. Accelerated Chromium, with WebGL and video display acceleration: No action needed Desktop video player capable of smooth 4K HEVC-HDR: Use the "Rockchip Gst Player" from the Multimedia menu, or choose it with right-click on the media file. Command-line 4K playing is also possible with "gst-play-1.0 --videosink=kmssink". RKMPP-accelerated MPV: Use normally for standard operation (windowed with mouse-operated GUI). For fullscreen, keyboard-operated mode, use the command line switch "--gpu-context=drm" (this will allow you to play smooth 4K).
        - See instructions below, in the next post, for playing YouTube videos up to 4K with this MPV.
ISP Camera with real-time h.264/1080p HW encoding: Using the Gstreamer Plugin. Check this wiki for instructions on how to use it. Most of it applies to Armbian, except for the selection of ov5647/imx219 camera, which must be done using DT overlays. OpenCL 1.2 support: It will be fully functional, no further action needed. You can download some tests and examples from this link. Kodi 18.9 Leia with full RKMPP+GBM acceleration, 4K-HDR capable: You can start it from LightDM menu as your user account: 


Alternatively, you can also run it as a system service with these command lines: sudo systemctl disable lightdm sudo systemctl enable kodi-gbm sudo reboot Full collection of Kodi binary add-ons: Includes retrogaming cores, media encoders and decoders, PVR, screensavers, vfs and audio visualizations. They are all installed with the package "kodi-addons-full", but are disabled by default. They need to be enabled individually within the Kodi GUI. OpenGL 2.1 support through the gl4es wrapper: It is installed with the package "gl4es", with no further action needed.  
III. Sources
This is the list of the sources used for the packages:
 
IV. FAQ
¿Why did you use Debian Buster as a base for this implementation?
It was the most appropriate for several reasons. Upstream Rockchip-Linux developers use Debian buster, so the software could be ported with less modifications than if we chose a different distro. Besides, it is a completely stable distro, unlike Bullseye, which is a moving target as of today. It also has Chromium as a package, unlike Focal that uses snap instead. For last, it has a good backports repo, with several libs that would otherwise need to be compiled and maintained if we chose, for example, Focal.
  ¿Why Legacy instead of Mainline?
This is an implementation based on the vendor's BSP kernel. It has been tested and is reliable, which many people will prefer rather than having a bleeding-edge, less stable implementation. In addition to that, Mainline upstream multimedia support is still a WIP, and lacks many features that are only present on Legacy kernels.
  ¿Will you add new features to this implementation?
No, this implementation will only receive bug fixes if necessary. From now on, all multimedia work will be focused on Mainline and recent distros (like Focal or Bullseye). All new features will go there.

We don't deal with images you find on the internet. We don't know them and they represent extra cost on already extensive support service which you support with nothing. You pay zero and I need to waste lets say 50 EUR for dealing with the problem you have. I would need another few hours to see and understand changes in the image you use. Another lets say 500 EUR worth of research ... you pay nothing for and you press on us for assistance on a problem that is most likely not our work in 1st place.
 
Free support is limited to our work and its also further limited. We can't fix all problems, but we at least try if possible, while when 3rd party image is in question ... we don't even start.
 
Clear?

./compile.sh LIB_TAG=desktop EXPERT=yes  

eMMC has higher priority by (Amlogic chip) design. In some cases / boards they have buttons or pads on the PCB that disabled eMMC temporally so you can force boot from SD. 

We don't record general Linux kernel bugs and we don't record user space bugs. Why not? Because covered R&D budget is zero, nothing. Your contribution to this project is about 1000x too small that we (<10 people) could afford to cover problems that are discovered in the Linux kernel or in any out of several thousands of community made and maintained code. I am talking about this round the clock, things are improving but sadly remains on the same level. We are losing opportunity to get a better code, I know, but since this project is heavily attached to our scarce time and private pocket, you really not in a position to complain or ask for more.
 
Because most of the people have no perception on the scale of this project or their (your) questions and the fact that we can't pay millions for working hours needed to solve bugs you find and code your wishes. We established a wishes section here: https://forum.armbian.com/forum/38-feature-requests/ but TBH, even reading them is not possible. Its always a trade - helping you or dealing with our families.
 
Now think again and remember that public level of co-funding only mitigates the problem of download / infrastructure costs. Luckily we don't need to put disgusting ads to this website to cover those expenses. You cover them. But there your contribution ends. We can't pay for to hire 1, 10 or 50 full timers that would start dealing with what "you" want for free. We rely only on a few volunteers.

Can you change this? You have a better idea? https://www.armbian.com/get-involved
 
Bugs we decided to and are able to work on, are recorded in our Jira: https://armbian.atlassian.net/browse/AR Only contributors can open, close or comment there.