going

I think we should do exactly the opposite.
As soon as the author realizes that his codebase has begun to create stable images for the family\branch, he can invite the most active members of this group to test and fix bugs.
That is, errors, changes must be made in this branch. While the master should remain stable and not create problems for the current work.

It works. I connect my accelerometer success!

Seems to work 😀
 
/dev/spidev0.0 is created. The SPI device CC1101 and therefore the Homegear gateway initializes fine.
What else information do you need? dmesg output? Logfiles?
 
Small change in your instructions: cd deb must be cd deb/nanopineo

Doing what is explained in this post make it to work but spidev isn't anymore controlled through /boot/armbianEnv.conf file but the DT.
 
I used the "quick and dirty" fix for now by using "rohm,dh2228fv" which is already in the spidev_dt_ids[] list and avoid me creating a new build with a patch to modify drivers/spi/spidev.c
 
So basically, I used armian-config to edit the Device Tree (System => Dtc),
Browse the DT over soc => spi@1c68000
And I added these lines :
spi@1c68000 { ... spidev@0x00 { compatible = "rohm,dh2228fv"; spi-max-frequency = <100000000>; reg = <0x00>; }; }  
And the same for the second SPI controller :
 
spi@1c69000 { ... spidev@0x00 { compatible = "rohm,dh2228fv"; spi-max-frequency = <100000000>; reg = <0x00>; }; }  
I also had to remove the spidev stuff from /boot/armbianEnv.conf (No spi-spidev overlay)

This way, I get two SPI devices and the SBC is working again with 5.15 kernel :
 
# ls /dev/ | grep spi spidev0.0 spidev1.0  

i have encountered the same problem as yours. i have downloaded the latest armbian from release page(my board is OrangePi Zero),flash it into sd card,and wrote this overlay:
/dts-v1/; /plugin/; / { compatible = "allwinner,sun8i-h3"; fragment@0 { target-path = "/aliases"; __overlay__ { spi0 = "/soc/spi@1c68000"; }; }; fragment@1 { target = <&spi0>; __overlay__ { #address-cells = <0>; #size-cells = <0>; status = "okay"; spidev { compatible = "spidev"; status = "okay"; reg = <0>; spi-max-frequency = <1000000>; }; }; }; }; after applying it using `sudo armbian-add-overlay spi0.dts`,it *seems* to be loaded correctly(i use a usb-serial wire to observe console log from on-board debugging serial,it shows "Applying user provided DT overlay spi1.dtbo" and no errors occurred),but when i logged in system,there were no /dev/spidev* show up.
also, i have noticed there are some spi error in kernel log:
[ 1.928114] sun6i-spi 1c68000.spi: chipselect 0 already in use [ 1.928149] spi_master spi0: spi_device register error /soc/spi@1c68000/flash@0 [ 1.928200] spi_master spi0: Failed to create SPI device for /soc/spi@1c68000/flash@0 when i change the spi0 to spi1 , the whole spi thing will not work,even if i have checked the `/proc/device-tree/soc/spi@1c690000/spidev/status` file is "okay"(and dmesg shows nothing related to spi). doesn't know what kinda thing happened.
sorry for my pool English,i'm not a native English speaker.
i wish these infomations will help the developer.

I want to test my own assumption. I will create a package for your specific OS in the environment of this OS.
And I will provide you with a download link. You will install this kernel package into your system and check its operability.
 
Ubuntu 18.04 and Debian 9. Wait for the link here.

Gentlemen, thank you very much for the topic raised.
I discovered libgpiod. Today I checked on orangepipc2. All the functionality described in the help for teams works. And I saw more advantages.
If the pin is configured as an input, then I get a timestamp about the event automatically.
Two different processes will not be able to access the pin at the same time.
There are more advantages.

Hans, It is a kernel deprecation issue.  There is a possibility that it can be added back dependent on effort required.  I will look into this.
https://www.kernel.org/doc/Documentation/gpio/sysfs.txt
https://www.kernel.org/doc/Documentation/ABI/obsolete/sysfs-gpio
https://www.kernel.org/doc/Documentation/driver-api/gpio/drivers-on-gpio.rst

In the mean time, you may want to look into whether libgpiod can do what you need. ( apt install gpiod).
A reasonable explanation and some instructions for using libgpiod.
https://www.thegoodpenguin.co.uk/blog/stop-using-sys-class-gpio-its-deprecated/

Update: The pull request has been merged and functionality restored (in nightly builds until next release).

If I understand correctly, have you installed packages from a local folder? Did you build these packages yourself and use the armbian build system?
 
If yes, then you need to look inside the kernel package. What scripts are there? And try to build a fresh kernel and then compare the scripts from the fresh kernel and the one you installed.
Unfortunately, I do not see many details and I find it difficult to give any advice.

@belegdol I don't use an odroid, but if you write down which image was originally recorded on the memory card and how the update took place, maybe I can fix it for a future release. And of course yes, 58 megabytes to accommodate the boot partition is not enough.
 

I want to add to the list the topic userpatches organization #2915, which @TonyMac32 started.
This is a fundamental principle and it requires attention.
 

I want to add to the list the topic userpatches organization #2915, which @TonyMac32 started.
This is a fundamental principle and it requires attention.
 

I guess I felt like that great discussion in rpardini's PR was sort of shut down prematurely.  Maybe the forum is a better place where we can take the long view over time and build more consensus about some of these bigger changes.
 
Here, everyone have a beer and relax, get into right frame of mind.   

@Igor @lanefu There are two options working in this branch.
For 5.12, the standard process for applying patches is.
For 5.10, a series of patches is used.
Both variants use the new mechanism and version numbering for the kernel and u-boot.
Here I have laid out a hand tool with which I extract a series of patches.
 
My lib.config
~/build$ cat userpatches/lib.config # KERNELSOURCE="https://github.com/megous/linux" if [ "$KERNELPATCHDIR" == "sunxi-current" ]; then KERNELSOURCE='git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git' KERNELBRANCH=tag:v5.10.37 fi  
Result:
~/build$ ls output/images/ Armbian_21.08.0~trunk_Orangepipc2_focal_edge_5.12.9_minimal.img Armbian_21.08.0~trunk_Orangepipc2_focal_edge_5.12.9_minimal.img.sha Armbian_21.08.0~trunk_Orangepipc2_focal_edge_5.12.9_minimal.img.txt ~/build$ ls output/debs armbian-config_21.08.0~trunk_all.deb linux-dtb-edge-sunxi64_5.12.9-21.08.0~trunk_arm64.deb armbian-firmware_21.08.0~trunk_all.deb linux-headers-edge-sunxi64_5.12.9-21.08.0~trunk_arm64.deb armbian-firmware-full_21.08.0~trunk_all.deb linux-image-edge-sunxi64_5.12.9-21.08.0~trunk_arm64.deb armbian-zsh_21.08.0~trunk_all.deb linux-libc-dev-edge-sunxi64_5.12.9-21.08.0~trunk_arm64.deb extra linux-source-edge-sunxi64_21.08.0~trunk_all.deb focal linux-u-boot-orangepipc2-edge_21.08.0~trunk_arm64.deb ~/build$ dpkg --info output/debs/linux-u-boot-orangepipc2-edge_21.08.0~trunk_arm64.deb new Debian package, version 2.0. size 287004 bytes: control archive=424 bytes. 335 байт(а), 11 строк control Package: linux-u-boot-orangepipc2-edge Version: 2021.04-armbian-21.08.0~trunk Architecture: arm64 Maintainer: Igor Pecovnik <igor.pecovnik@****l.com> Installed-Size: 1 Section: kernel Priority: optional Provides: armbian-u-boot Replaces: armbian-u-boot Conflicts: armbian-u-boot, u-boot-sunxi Description: Uboot loader 2021.04-armbian ~/build$ dpkg --info output/debs/linux-image-edge-sunxi64_5.12.9-21.08.0~trunk_arm64.deb new Debian package, version 2.0. size 28504152 bytes: control archive=72124 bytes. 483 байт(а), 13 строк control 282583 байт(а), 2821 строк md5sums 422 байт(а), 15 строк * postinst #!/bin/bash 297 байт(а), 12 строк * postrm #!/bin/bash 898 байт(а), 33 строк * preinst #!/bin/bash 295 байт(а), 12 строк * prerm #!/bin/bash Package: linux-image-edge-sunxi64 Source: linux-5.12.9-sunxi64 Version: 5.12.9-21.08.0~trunk Architecture: arm64 Maintainer: Igor Pecovnik <igor.pecovnik@****l.com> Installed-Size: 126265 Provides: armbian-edge, linux-image, linux-image-armbian Section: kernel Priority: optional Homepage: https://www.kernel.org/ Description: Linux kernel, armbian version 5.12.9-sunxi64 edge This package contains the Linux kernel, modules and corresponding other files, version: 5.12.9-sunxi64.  
P.S. I am waiting for healthy criticism and suggestions.

Other than the suggestion I made before I see nothing really wrong with it. It's way more complicated than my approach and written better, but that would be expected. This is Armbian after all. 
I see some variables I don't understand such as $MAKE and $SRCARCH, but I'm going to assume that makes sense in the builder somewhere.
 
I also notice that none of the pre/post scripts define what they are..? Such as #!/bin/bash or #!/bin/sh, but that would only be relative during the kernel install and have nothing to really do with creation.
 
Only major difference I see, is you appear to be using the builddeb/mkdebian files from 5.10.y, where as I use the 5.4.y files and patch them accordingly to the SoC I am building for. I find it to be a more simplistic builddeb script and less of hassle to deal with and the kernel doesn't complain when I replace the ones it comes with. 
 
Example packaging I use for my test builds. https://github.com/pyavitz/debian-image-builder/tree/feature/patches/packaging
Disclaimer: I don't recommend anyone using that builder, it's mostly a pet project and learning tool for myself. 
 
As for the slow down you are getting in the VM, I really have no ideas as to why that would be. I never use a VM when building, although I do use Docker sometimes.
 
 

For the sake of experiment, we will try to disable the creation of the kernel header module in the configuration for 5.12.
I have run out of ideas. Tomorrow I will make the scripts easier, as in the 5.4 kernel.
As just shown @Cornelius

I'm sorry. These are rhetorical questions.
I can't get used to articulating thoughts in the style of English grammar so that the automatic translation looks correct.
In fact, I am an experienced user and will find any information.
But if we give the user the ability to search, update, or reinstall by key tags, it will be very good.
 
sudo apt search armbin
This command will display the full list of packages provided by armbian.
sudo apt search armbin-edge
This command will only show packages for $BRANCH
It is the word combination that is important here armbian-$BRANCH
sudo apt reinstall armbian-current
This command will actually do a package update for the $BRANCH
 
Here we not only take care of the user, but also improve the armbian.
 
@Igor Yes, but only for those packages that contain programs, libraries that have their own version.
This is necessary to correctly register the mutual dependencies.
And this is especially true for the kernel and libraries that use the functionality of this particular kernel.
The final version can be formed by concatenating the original version and the armbian version.

You mean where to find information which branch is currently installed?
 
 

IMO that should be fine.

I found a solution. Tomorrow I will write in detail.

Name pkg:
linux-image-current-sunxi64_21.02.0-trunk_arm64.deb
What kernel version does this package contain?
Name img:
Armbian_21.02.0-trunk_Orangepipc2_focal_current_5.9.14_minimal.img
In this title you can see everything.
 
I was just asking. I was hoping that someone would remember the reason why they chose this particular style of name.
These package names have been around for quite some time.
@5kft  I assume this is due to reinstalling the package to a new one.
Easy installation instead of the same name. And there is always only one core in the system.
If this is indeed the case, then the best option is to leave the naming as it exists.
For a source package, it doesn't matter.
 
Yesterday I tested the collected images of a minimal system with different cores. All images are working.
The linux-source-5.*.deb, linux-libc-dev-*.deb packages are installed and uninstalled. The problem occurred with linux-headers -*. deb.
I did a clean build on the master. Tomorrow I will watch and make a comparison.

Today is December 15, 2020
I brought the code to the top of armbian master. Built for different kernel versions (5.4 5.9 5.10).
 
debs> ls -gGhR .: итого 807M -rw-r--r-- 1 43K дек 15 22:05 armbian-config_21.02.0-trunk_all.deb -rw-r--r-- 1 6,6M дек 15 22:05 armbian-firmware_21.02.0-trunk_all.deb -rw-r--r-- 1 142M дек 15 22:05 armbian-firmware-full_21.02.0-trunk_all.deb drwxrwxr-x 1 0 дек 15 22:05 extra drwxrwxr-x 1 436 дек 15 22:05 focal -rw-r--r-- 1 77K дек 15 22:05 linux-dtb-current-sunxi64_21.02.0-trunk_arm64.deb -rw-r--r-- 1 80K дек 15 22:05 linux-dtb-dev-sunxi64_21.02.0-trunk_arm64.deb -rw-r--r-- 1 57K дек 15 22:05 linux-dtb-legacy-sunxi64_21.02.0-trunk_arm64.deb -rw-r--r-- 1 12M дек 15 22:05 linux-headers-current-sunxi64_21.02.0-trunk_arm64.deb -rw-r--r-- 1 12M дек 15 22:05 linux-headers-dev-sunxi64_21.02.0-trunk_arm64.deb -rw-r--r-- 1 11M дек 15 22:05 linux-headers-legacy-sunxi64_21.02.0-trunk_arm64.deb -rw-r--r-- 1 26M дек 15 22:05 linux-image-current-sunxi64_21.02.0-trunk_arm64.deb -rw-r--r-- 1 27M дек 15 22:05 linux-image-dev-sunxi64_21.02.0-trunk_arm64.deb -rw-r--r-- 1 30M дек 15 22:05 linux-image-legacy-sunxi64_21.02.0-trunk_arm64.deb -rw-r--r-- 1 1,1M дек 15 22:05 linux-libc-dev-current-sunxi64_21.02.0-trunk_arm64.deb -rw-r--r-- 1 1,1M дек 15 22:05 linux-libc-dev-dev-sunxi64_21.02.0-trunk_arm64.deb -rw-r--r-- 1 1,1M дек 15 22:05 linux-libc-dev-legacy-sunxi64_21.02.0-trunk_arm64.deb -rw-r--r-- 1 192M дек 15 22:05 linux-source-5.10.0-dev-sunxi64.deb -rw-r--r-- 1 159M дек 15 22:05 linux-source-5.4.82-legacy-sunxi64.deb -rw-r--r-- 1 190M дек 15 22:05 linux-source-5.9.14-current-sunxi64.deb -rw-r--r-- 1 276K дек 15 22:05 linux-u-boot-current-orangepipc2_21.02.0-trunk_arm64.deb -rw-r--r-- 1 276K дек 15 22:05 linux-u-boot-dev-orangepipc2_21.02.0-trunk_arm64.deb -rw-r--r-- 1 276K дек 15 22:05 linux-u-boot-legacy-orangepipc2_21.02.0-trunk_arm64.deb ./extra: итого 0 ./focal: итого 1,4M -rw-r--r-- 1 162K дек 15 22:05 armbian-focal-desktop_21.02.0-trunk_all.deb -rw-r--r-- 1 405K дек 15 22:05 linux-focal-root-current-orangepipc2_21.02.0-trunk_arm64.deb -rw-r--r-- 1 405K дек 15 22:05 linux-focal-root-dev-orangepipc2_21.02.0-trunk_arm64.deb -rw-r--r-- 1 405K дек 15 22:05 linux-focal-root-legacy-orangepipc2_21.02.0-trunk_arm64.deb  
without any major changes, the two kernel build scripts (builddeb  mkdebian) build different versions in the same way, starting from 5.4 and higher.
Changes were required in the part that concerns the 'armbian' build system itself.
 
To be honest, I spent longer looking for places where temporary folders are created, and those places where they should be deleted after completing their function.
 
You can test this approach as before:
git remote add armbian-build https://github.com/The-going/armbian-build.git git fetch armbian-build packaging git checkout -b packaging armbian-build/packaging git pull -f armbian-build packaging  
 

As of today, may 11, the following packages are being built, installed, and uninstalled without errors:
  43K    - armbian-config_20.05.0-trunk_all.deb
 6,2M    - armbian-firmware_20.05.0-trunk_all.deb
 101M   - armbian-firmware-full_20.05.0-trunk_all.deb
 56K     - linux-dtb-current-sunxi64_20.05.0-trunk_arm64.deb
 11M    - linux-headers-current-sunxi64_20.05.0-trunk_arm64.deb
 29M    - linux-image-current-sunxi64_20.05.0-trunk_arm64.deb
 1,1M    - linux-libc-dev-current-sunxi64_20.05.0-trunk_arm64.deb
 123M  - linux-source-current-sunxi64_20.05.0-trunk_all.deb
269K    - linux-u-boot-current-orangepipc2_20.05.0-trunk_arm64.deb
 
The disk image has been assembled, and the locale with native languages is working.
1000M  - Armbian_20.05.0-trunk_Orangepipc2_bionic_current_5.4.38_minimal.img
 
Started checking the health of packages on the Board - linux-source, linux-libc-dev, linux-headers

Sorry, colleagues. Work in progress.
I have a number of problems and can't allocate enough time to finish.

In the continuation of the conversation:
PR #1836

Functions that helps you can help someone else. If they don't break anything they are welcome and gets accepted into the code. Speed of acceptance further depends on review complexity.