going

@Igor This line may sound rude, but you are probably waiting for the developers of the source code to take some action to improve patches or kernel settings. As long as this heresy is present in the build system (bad package build scripts), the project will receive crumbs from what developers can and do locally.

The developers of Armbian have signed their own impotence with this. They cannot or do not want to add support for creating an additional package with debugging symbols. If we look at simple scripts for creating debian packages directly in the kernel source codes, we will see that the debugging package is created automatically when the configuration option is selected: CONFIG_DEBUG_INFO The only way is to change the script of the build system itself by removing these lines and adding 10 lines to the script to create a debugging package. With respect to all free software developers. Leonid.

This option can only be used when you have already done the build once. The sources in the cache folder have been updated or created. By applying this parameter, the build system should not update local sources and their state should not change. In this case, it is possible to achieve repeatability of the assembly. But this is only local. It is not possible to re-build a package that exists in a remote repository.

Ambiguity of the translation Unfortunately, it is not possible to build a specific version or, in other words, repeat the build. Let's assume that I'm building all the packages and installing them in a future image. I have made my custom changes in the kernel package and in two other packages. And I don't want these packages of mine to be updated when the OS is updated. In this case, I install a version larger than the latest version in the Armbian repository. Another case. I've put together three packages and just want to install them into an already running OS on the device. I'm doing the same thing with the version. That's what I meant.

The entry in this file is used as the package version. If you want the packages you have collected to be installed and then they are not updated to packages from the Armbian repository, then the version in your build should be higher than the current one for today. I.e. 24.5.1-trunk.

@Andrea @Jens J. Currently, the build system is not designed for the development process and does not have convenient tools for this. Alternatively, you can copy the entire kernel tree after patches have been applied and changes have been made to it in other non-traditional ways. Stopping the compilation process as soon as it has started. The build system deletes some files and replaces them by copying its own or simply copies its own files. In this copy of the tree, make a commit of the git with the addition of all unindexed files. Next, you make your changes and commit them. Extract the changes as a patch and place it in custom patches. This method avoids many time-consuming processes, but has one drawback. The process of applying patches using the python script is accompanied by dividing large patches into separate pieces and applying them separately. At the same time, some pieces can be applied with displacement and diffusion in one line. Thus, the changes end up in another function. Externally, it looks as if all the patches were applied without errors. Let's assume that you found this bug and made your own patch of fixes. But after a while, the patch author may make corrections and your custom patches will need to be redone. Thank you for your attention.

😄👍

thanks. I understand your point of view. For a clean system, you may need this key: KEEP_ORIGINAL_OS_RELEASE=yes The script that @Igor advises will add the Kali repository to the /etc/apt/sources.list.d/kali.list file. But one inaccuracy remains. You'll probably want to change that: https://github.com/armbian/build/blob/27a07d918e3e010f74dc24fcc17f510a8eb35252/lib/functions/rootfs/distro-specific.sh#L150 @Igor sid and unstable are synonyms of the same repositorysid and ustable. sid|unstable) cat <<- EOF > "${basedir}"/etc/apt/sources.list deb ${DEBIAN_MIRROR} $release main contrib non-free non-free-firmware #deb-src ${DEBIAN_MIRROR} $release main contrib non-free non-free-firmware EOF Otherwise, apt will read the same thing twice.

If you know the Kali Linux distribution well, then you can try installing Armbian and then change the sources in the /etc/apt/source.list file. Then just update the sources. Or do you need some special changes in the kernel? I am not familiar with this distribution. My questions may look strange.

Why do you want to get support for this particular Kali Linux?

The problem with displaying the actual temperature was noticed a long time ago and I fixed it in this core for the A83T processor. I did not notice any overheating problems during normal no-load operation. You just need to check if this will work for the H3 processor. You will be able to return to the 6.1 kernel in the same way if there are problems. And then just delete it using apt. Is 52 degrees the real temperature? How did you measure it? What does htop say? armbianmonitor?

@mc510 I tried to fix this situation. There are ready-made kernel packages here. Can you check it out? Just install the kernel package. The DTB package is not required.

I'm wondering how you measure the temperature? The readings of armbianmonitor and a finger touch? If the finger on the radiator feels warm, it means that the temperature is in the range of 35-45 degrees Celsius. At the same time, the readings in 26 C are false.

This question is not about Armbian and not about large SD cards. This question is about who produced this SD card and what technology, what kind of controller is there. Very well-known manufacturers (expensive ones) can release a SD card with a controller that will work well with the MSDOS partition table and the FAT, VFAT file system and will be very slow or will reduce the size with the EXT4 file system, and will not work with the GPT partition table. I have such an SD card. You can understand what you bought when you start using it.

@dhlii Thank you so much for the detailed answer. Now I see that you are a much more experienced developer than me. The H3 and H5 processors are pin-to-pin compatible. Theoretically, it is possible to solder one and solder another processor. And it should work.😁Of course it's a joke. Therefore, comparing the DTS sun50i-h5-nanopi-r1s-h5.dts and sun8i-h3-nanopi-r1.dts, I can see many identical nodes of the same name. This comparison will not be difficult for you. I wrote buildroot as an example. There are several such build systems for embedded operating systems. From my point of view, buildroot is not the most convenient to use.