Werner

Moved to Common issues / peer to peer technical support

I will try, but daily job take most of my time these days ...

Prefixes as we knew them a few days ago are gone. The extension which provided those might got abandoned by the author.
Anyway I'll try to do the best of the situation and refactor this stuff.
Forums which only had a "solved" prefix before will now get the option for moderators and topic author to mark a specific post as solution which also will mark the entire topic as solved. You can check this topic to get an example how this works: https://forum.armbian.com/topic/15333-what-should-be-in-my-gnupg-directory/
 
For other forums there will be a few additional clicks needed to get a tag being used as prefix:

 
I just started to rework the forums so stay tuned if it does not work out for your specific forum you are currently enjoying yet
 
Edit: Done so far.

Examples:

- new board to existing family
- new board and new family

After mounting and unmounting several times both external units it seems to start working. Now the mount point at /sda is consistent across all the commands. The outpus you asked, @lanefu, is:
ls -l /dev/disk/by-uuid total 0 lrwxrwxrwx 1 root root 15 may 11 22:57 d4e4d15d-d587-4f5d-83d7-4cbb1700e7c5 -> ../../mmcblk0p1 lrwxrwxrwx 1 root root 9 may 11 22:57 dcb5a19c-6bd2-4c5a-8fc4-9ed4adec7074 -> ../../sdb lrwxrwxrwx 1 root root 9 may 11 22:57 e6201983-bfd8-4eae-bf54-90575f09835f -> ../../sda  
I also added a new screenshot. Thanks for the help. And I'll keep an eye on this if it happens again.

I had the same issue.
 
Created a PR: https://github.com/armbian/build/pull/2818
 
Thanks for the fix olegoldtom !!
 
 

Your issue report is not a valid bug report per the Armbian bug reporting instructions (https://www.armbian.com/bugs).  With limited resources the Armbian project is only able to spend time on issues where all the requested information has been provided and for only the boards/images/software that are supported.  Your report is invalid for one or more of the following reasons (non-exhaustive list):
 
it is for an unsupported board or image (CSC/EOS/WIP/edge) it is for software that is not supported (such as userspace modules installed on top of the core operating system) it has been logged in the wrong forum (for example requests for help that are not actual bug reports) it lacks requested data (armbianmonitor output) it could have been easily solved by a quick search and/or reading documentation  
Please review what you have submitted and the bug logging instructions (https://www.armbian.com/bugs) and either add the required information or open a new topic in the correct forum (such as Common issues / peer to peer technical support or General chit chat)

IMHO I'd omit HDMI or any sort of output other than console.    If the eMMC is a detachable module, then yeah eliminating SDCard is a good idea.

https://docs.armbian.com/Release_Changelog/#v2105-2021-05-09

No WiFi, no SDCard, M.2 socket, eMMC, SPI Flash, USB-C (power plus host), 4GB RAM, big low profile heatsink, RTC, and GPIO with I2C, SPI, and pins with USB. As small and low height as possible.
Options would be NPU, more RAM, CSI and of course a SOM instead of the whole SBC.

My $0.02.

Imagine a new SBC is developed specifically designed for computing tasks and clustering but should also be available for a rather low price.
Which features should it have or not have? What do you think? Is it even possible?

Nah, all good from here. I'll try to do the release this sunday. Might hop in the IRC if I need assistance. Release on sunday evening is good IMHO because if something critical goes wrong, we can fix on monday.

Hey @Jeremiah Cornelius 
I've been working on something similar it seems, thanks to @lanefu for making the connection.
Although the path I took was directly modifying the Armbian build scripts, instead of modifying a live image and then re-packing it.
 
My fork of Armbian is quite complex, but I'm slowly splitting and reorganising things (and sometimes writing a metaprogramming Bash framework in the process ) 
A few points that may be of interest to you:
 
- Onboarding replaced by cloud-init, instead of any interactive onboarding, I configure cloud-init to read some YAML files from /boot.
  /boot/network-config can configure all aspects of networking (including wifi), /boot/meta-data is just that, and /boot/user-data can do almost anything, create users, passwords, import SSH keys, install packages, run scripts, resize rootfs, create SSH host keys, etc.
  cloud-init is of course focused on cloud images, but actually can be used on any environment, if you can stomach its YAML and hammer on its config.
  With cloud-init comes netplan.io (in place of NetworkManager) and some other stuff that may not be appropriate for your use-case so take with a grain of salt.
  Also my implementation is not bullet-proof yet, but it aims to work just like the Ubuntu RaspberryPi 4 "Server" image (also has cloud-init out of the box).
  Most of it is done in https://github.com/rpardini/armbian-build/blob/rpardini-fragments/userpatches/fragments/cloud-init/cloud-init.sh (including the .not_logged_in_yet thing)
  Some other related stuff in https://github.com/rpardini/armbian-build/blob/rpardini-fragments/userpatches/fragments/more_like_ubuntu_cloud.sh (which disables a bunch of stuff in the BSP,  during BSP-generation, so that reinstalls/upgrades of the bsp package do not ruin everything).
 
- A trick I call rootfs-in-rootfs, during the image build process, I capture an e2image ext4 dump of the produced ext4 rootfs and then include it in the rootfs.  A bit like having a directory full of files, creating a .zip of it, then including that .zip file inside itself  but without the compression.
  Then boot the SD card (which includes the rootfs dump inside) and run "e2image -racp /root/rootfs.ext4.e2img /dev/sda2" for example.
  The nice thing is that e2image (part of e2fsprogs) can do a "smart" copy (-c), knowing that reading is cheaper than writing, it can read both the source and destination and only write the changed blocks to the target. This allows for a very, very fast version of "nand_sata_install",  especially on the 2nd+ "flash".
  More speed comes from reading/writing some hundred-thousand whole blocks instead of possibly millions of files that rsync would need to inspect individually.
  The relevant code fragment is https://github.com/rpardini/armbian-build/blob/rpardini-fragments/userpatches/fragments/rootfs_e2img_inside_rootfs.sh
 
Hopefully these will be of some help,
Ricardo
 
 

stock kernel works, issue is with orange pi 4 has badly designed FPC connector for PCIE lanes. They didn't group the diff pairs so transmission over FPC cable sucks. We had to make a flex ribbon board to correct this and route as diff pairs so Gen 2 2x works great. Might make some extra and release the board if there is enough interest. 

I agree. I'm very much in favor of making contributions, and not shy about being detailed. When the Linux world revolved around HOWTOs, not Reddit subs and siloed vendor forums, I was particularly active.

Here's a case where I'd gladly supply documentation, were I not faced with ambiguous outcomes, and a lack of authoritative information to begin!
Thanks!
— Jeremiah

You can help make this wish become reality. Everybody can contribute to make the documentation better: https://github.com/armbian/documentation
The lack of (human) resources is a big issue for the Armbian project so community contributions are more than welcome.

Yes. Grab the needed incremental patches and add them like this one and all previous: https://cdn.kernel.org/pub/linux/kernel/v5.x/incr/patch-5.4.113-114.xz
 

No. Some CPUs can run on lower voltage with same frequency to reduce their power loss but most will become unstable this way. There is only one way to find out if it works.

That cannot be answered by a simple yes or no. It depends.
Let's take the 5.4 example.
If you follow the current branch it leads us to megi's orangepi-5.4 branch. If you check the Makefile (https://github.com/megous/linux/blob/orange-pi-5.4/Makefile)
you will notice that the actual version of this branch is 5.4.18. But when you compile the kernel it is actually 5.4.47 or something like that.
This means these patches come from Armbian. If you check the patch directory for your board family (https://github.com/armbian/build/tree/master/patch/kernel/sunxi-current)
you can see that the upstream patches are added here. If you need a very specific kernel version remove or rename the patches you do not need.
 
That was a quite easy example to get what you want.
On other sources, vanilla for example, it is a bit tougher. You would need to specify a commit at which point you want to use the sources.
Sometimes a board is fixed to a specific commit or kernel version because it is known that newer version of the same kernel branch are known to be broken and (as most of the times) nobody has time or resources to deal with it.

Current situation on our test farm - except from Odroid C4 and Lepotato boot issue - power cycle is needed, things are fairly stable:

 

 

Code freeze has happened.
 
I have branched an rc version (https://github.com/armbian/build/tree/v21.05.0-rc ) please send bugfixes here (additionally to the master branch).
 
Also the version of the master branch has been set to 21.08.0-trunk.
 
Please check the remaining Jira and Github PRs to see if anything in Jira needs closing (will be used to generate the changelog). 
 
Testing and Bugfixing will be until beginning of May.
 
Kind regards,
Heisath

This is the same stuff that we incorporate via patches at the moment.
However building may become easier and we can get rid of a few of those.

Moved to Helios64 club forums.
 
I am not an expert in this but there might be differences in the boot behavior between Allwinner SoCs (sunxi family) and Rockchip SoCs (like the RK3399 which the Helios64 is built around).

Patch was merged, so you can build and use firmware from Marvell repository.

Not an official Armbian image, therefore it is most likely that official way will not work.
Ask the author of your 3rd party image for the kernel sources.