Igor

Hi,
 
sorry for the late reply. Current state @Technicavolous : Hijax and I are pretty busy at the moment so project is progressing rather slow, but:
Hijax is done with the final (?) revision of the power&serial mux board. You can check it out here: https://github.com/armbian/mpads/tree/serial-mux-updated
Also we are working on the SD card muxing which is surprisingly hard: https://github.com/armbian/mpads/tree/sd-card-mux-redesign 
On the master branch I am working on the firmware for SD card muxer: https://github.com/armbian/mpads/tree/master (warning, the kicad files there are outdated. We should merge the branches).
 
Current state of the software/hardware combo is something like:
- Power/Serial working and controllable via i2c with a small script.
- sd card can be selected via I2C and gets accessible to the host with STM32 
- sd card can be attached to the slave. 
 
Main problem is stability and powering of the sdcards (related). Also there are some issues with the usb/mass storage driver in the STM32 but it is somewhat working. 
 
 

We can run this on actual Armbian, but for the most of the part that is not needed. We can use stock Github runners and x86 Debian & Ubuntu userland to run tests. Code must be designed as architecture independen from start and HW features has to be tested on the actual devices. But since that is a bit more complicated it doesn't need to be the part of this pipeline.

If you report troubles with self build image not many people will listen. Self build images are officially not supported since they are build from a development environment, unknown upstream quality, nobody test features and anyway we can't afford dealing with "customers" in real time. Strictly speaking only digitally signed images are a subject of our interest. Limited with our private time! Even that is extremely hard and expensive (99% is our private cost which is not small at this level) to keep those cheap board operational and usable. We lost about 30-50h for this project in total every day.
 
 
Until someone will make things together properly and provide a PR, it won't. But we don't receive help even for simple things https://forum.armbian.com/forum/54-help-wanted/ we ask while current maintainers are totally overloaded. Wishlist is estimated on millions / years of development.
 
 
I see, It looks like we don't have them for A20  But everything else ... so you will need to edit DT by hand. It could also work fine via armbian-config -> system
 

  
 

- (backup of) boot scripts are packed in u-boot or bsp package
- this is not a bug but feature. In some cases legacy kernels needs boot loader that is incompatible with current modern kernel.
 

IIRC we have (had?) some bug related to A20 / LK5.10.y / HDMI out. Try build image from sources.
 
 
https://docs.armbian.com/#what-is-supported
 
 
Those DTs are maintained upstream, but not sure if there were any changes for years. Some properties could also become obsolete in the meantime ... Also try this way: armbian-config -> system -> hardware and enable all USB ports.
 

Could be more than one reason:

- keeping wifi drivers nobody maintains aligned with modern kernel. Require constant rework - just few recent commits on the topic:
https://github.com/armbian/build/commit/ec36591108c6b96faec3c74c5421faf05a5060bb
https://github.com/armbian/build/commit/d28c170a2354bfc0413ee8594ab2e690259fe2b9
https://github.com/armbian/build/commit/03e4f604d3ee991183840ff7a3c0959be1e28637
- DT bits for Orangepi wifi are not present in Bananapi DT
 

Try not to associate question to persons. This is forum. People help if they can and have time ...
 

Kernel driver is present, but we don't have click and play experience. I don't deal with this.

This log is not from HC4. Not sure if this a problem of pastebin service or you made some mistake. Check it and do it again.

Operating system and hardware has almost certainly nothing to do with the problem you are facing. This forum has mainly just general know-how about this software. I would suggest you to form your questions on OMV forums: https://forum.openmediavault.org/wsc/
 

So, started playing around a bit. Mostly just mocking up ideas.
 
https://github.com/tparys/armbian-reconfig
 
The script currently is recursively driven by a directory system. When it hits a script, it simply executes it. Should be pretty easy to extend. Just drop a script in place and it should use it.
 
I mulled over how to "name" the various scripts and directories, and eventually settled on using gettext, which also provides internationalization support as well. Basically takes the relative menu location like "/system/firmware" and "translates" into the appropriate language. In the case that only partial translations exist, it falls back to English, which i figured wasn't a horrible default.
 
And for testing, I added some translations of the top level menu to Spanish. I did use Google Translate, as my bash-fu is strong and my Spanish is quite rusty.

Yes. Neo2 black is a part of a setup that is actively monitored on software upgrades. Test report looks like this https://users.armbian.com/igorp/2021-02-16_14.18.11.html But this testing facility is not near to the proffesional grade. To be sure, we would need much larger SBC farm ...

Armbian is (probably) the the only distribution that doesn't use u-boot from 2015. All others are still using stock private Hardkernel boot loader ... We try to get rid of vendors dirty security hazardous code as soon as possible and problems as such is the price that we need to pay.
 
Currently we use u-boot based on 2020.xx, but it looks like it's possible that we need the one from 2021 as this is the case with C2. Some eMMC needs this. Mine obviously don't since it works without any intervention.
Try this image:
https://users.armbian.com/igorp/images/Armbian_21.02.0-trunk_Odroidc4_focal_current_5.10.12.img.xz

I will just add a bit more. 
 
We want to rewrite / make this from scratch with Ansible. Basically we seek Ansible expert or someone who wants to become one.  We have this know-how but we are simply too overloaded to move on. This is yet another job for common good! To make Armbian support better. To make Debian support better. To make Arch better, OpenWrt, ... To make every Linux distro out there running better on your board.
 
The person(s) should focus only on testing. Creating and maintaining scripts for automated testing and later, when our support hardware is out of beta testing, implement that as well. It's a continuous project and will not end tomorrow. Also you don't need to stay on it forever. Do what you can. Help us get going ...
 
We would like to automate:
 
- initial board setup (after you flash the image, automated 1st login, setup network, different local repository, ...)
- simple tasks such as upgrade, change to beta repository, downgrade to specific kernel, etc.
- run various of tasks which can be added without limits
- run various of benchmarks which can be added without limits
- run tasks in parallel
- make reporting in HTML, XML (common and per board)

Most of those ideas are covered in some basic form in our first try: https://github.com/armbian/autotests
 
More ideas:
https://github.com/SoInteractive/ansible-benchmark
 

@Tim J @tsipizic @filkint @jmviper Fixed with https://github.com/armbian/build/pull/2635 for 5.10.y and 5.11.y. Available if you use self build images, otherwise wait for update.

Commercial Rpi OS is based on: https://wiki.lxde.org/en/Main_Page which is IMO not near more modern and project they have forked, seems dead. But it certainly appears more modern than its fork ... perhaps more than XFCE. Subjective.
 
Our current amateur desktop is more or less stock XFCE with custom theme and wallpaper and was not changed since years - except internal version, applications within. We only make it to provide something clean, light and stable. It has those most important properties, which is important for serious deployments. Distro hoppers or Rpi users are not our target group and on most hardware we support, Armbian is usually best choice for different reasons.
 
But as @Werner pointed out, for about a year we are developing desktop upgrade - but its again for our internal needs, to make more desktop options and to make package management easier. We hope someone will step up and tweak desktops further so they will look nicer but if not, they will remain as is.
 
If you want to trade stability and security for nice design, just say it  It is way way cheaper to make desktop looks nice then keeping OS functional. We can't cover everything and in any case - there is no reward except internal satisfaction.

Commercial Rpi OS is based on: https://wiki.lxde.org/en/Main_Page which is IMO not near more modern and project they have forked, seems dead. But it certainly appears more modern than its fork ... perhaps more than XFCE. Subjective.
 
Our current amateur desktop is more or less stock XFCE with custom theme and wallpaper and was not changed since years - except internal version, applications within. We only make it to provide something clean, light and stable. It has those most important properties, which is important for serious deployments. Distro hoppers or Rpi users are not our target group and on most hardware we support, Armbian is usually best choice for different reasons.
 
But as @Werner pointed out, for about a year we are developing desktop upgrade - but its again for our internal needs, to make more desktop options and to make package management easier. We hope someone will step up and tweak desktops further so they will look nicer but if not, they will remain as is.
 
If you want to trade stability and security for nice design, just say it  It is way way cheaper to make desktop looks nice then keeping OS functional. We can't cover everything and in any case - there is no reward except internal satisfaction.

As a fun little hack, here's a little example wrapper for the dialog program. Mark it executable, toss it in /usr/local/bin, and fire up armbian-config.
 
Obviously delete it afterwards. don't leave it there. That's probably a bad idea.
 
But might work as a brief tech demo of what an X11 driven armbian-config might look like ...
 

dialog

Mainstream x86 Ubuntu and Debian are not near  to the Armbian level of support https://github.com/openzfs/zfs/issues/11449
 
https://www.armbian.com/donate
https://forum.armbian.com/subscriptions/

You don't need to do anything. 

Sorry for the late reply. I was busy within these days.
 
I've seen you have merged it, I'll test the latest compiled kernel, if I found any issue, I'll reply to this topic.
 
Thank you

Create own menu wrapper functions so menu functionality is not hard coded and we can switch between them easily.

@Tim J @tsipizic @filkint @jmviper Fixed with https://github.com/armbian/build/pull/2635 for 5.10.y and 5.11.y. Available if you use self build images, otherwise wait for update.

There are only two different hardware layers. Stock kernel (4.4.x) and mainline (5.10.y)  based. Debian or Ubuntu is just application lawyer which doesn't have any effects on board hardware. Check modern kernel - it should be much more stable. 

We have no knowledge of OMV internals. - Armbian works, otherwise you would not be able to install that software and ZFS on Armbian as well. 
 
I would say you should ask this on OMV forums.
 
Here you need to provide at least:
 

This and the regular logs:
 
armbianmonitor -u  

OK. It seems we are sticking to BASH. What about desktop?
 
I open this Jira and put down few tasks, those which I am aware of at this moment. Feel free to add / remove things, so we can make some structure. Tasks are just a basic / quick draft.
 
https://armbian.atlassian.net/browse/AR-638
 
I am also cautious about not creating a project we would not be able to move forward. Which is why we have to count resources and see how we can handle this, to which extend and by when. 

- AFAIK discontinued
- not well supported with mainline kernel yet

Probably we should switch rather to https://vscodium.com/#install ?

There are problems with 32bit ZFS support and there is nothing more we can do. 
https://github.com/armbian/build/pull/2547 
https://github.com/openzfs/zfs/issues/9392
Broken od Debian, buildable on Ubuntu based Armbian. At least on latest (LTS) kernel 5.10.y

Upgrade to 5.10.y on 32bit target doesn't work automatically ...
 
 after reboot you need to run 
dpkg-reconfigure zfs-dkms and select that you agree with 32b troubles but at the end, it works. I could load my pool without issues.