schwar3kat

Works: skips it completely. Works. Works. Works.

@rpardiniI tried building with BUILD_DESKTOP=yes. I expected a dialog to select which desktop and base config, but it aborted with an error. [\U0001f449] --> \U0001f4a5 2: 1401540 - 1401540 - 1401540: ehBE: err: error: stdout is not a terminal. can't use dialog. [ dialog_if_terminal_set_vars --title Choose a desktop environment --backtitle Armbian building script, https://www.armbian.com | https://docs.armbian.com | (c) 2013-2023 Igor Pecovnik --menu Select the default desktop environment to bundle with this image -8 cinnamon Cinnamon desktop environment gnome Gnome desktop environment xfce Xfce desktop environment in dialog_if_terminal_set_vars() at /mnt/data/build-armbian/armbian-next/build/lib/functions/configuration/menu.sh:17 ] ./compile.sh BOARD=pine64 BRANCH=current RELEASE=jammy BUILD_MINIMAL=no BUILD_DESKTOP=yes KERNEL_ONLY=no KERNEL_CONFIGURE=no CREATE_PATCHES=no armbian-build-b1f739f4-a394-44bf-ac80-72d8714be9f5.ansitxt.log armbian-build-b1f739f4-a394-44bf-ac80-72d8714be9f5.md

@rpardini I finally got armbian-next to build some rockchip64 orange-pi-r1plus-lts working images including some customization with customize-image.sh. This was done on both Linux Mint una (focal) and Linux Mint vanessa (jammy) The patching issues are by far the biggest headache. The second biggest headache is caching that does not pick up changes which leads to a fair amount of confusion. Summary of actions that were required to prevent errors from aborting the build: modified: lib/functions/host/prepare-host.sh line 105 changed to: run_host_command_logged ntpdate "${NTP_SERVER:-pool.ntp.org}" > null 2&>1 || true This behaves like current armbian-build and ignores errors caused by ntpd using the port. modified: lib/functions/image/rootfs-to-image.sh line 61 changed to: freespace=$(LC_ALL=C df -h > null 2&>1) || true This hides any warning messages and continues. or: freespace=$(LC_ALL=C df -h) || true This shows warning messages and continues. I disabled global patch signing (if enabled git commit will error): git config --global commit.gpgsign false I manually deleted deb files and cache/patch/kernel-drivers/ as required. I also had a problem with something cached causing makefile corruption. I couldn't find the cause and after I blew away the whole build, and started again from nothing the problem disappeared.

I think that your una/focal stuff is tested as working on una so I've upgraded to vanessa (jammy).

I disabled a non-working patch to test the rest of the build. It built to completion. Then I enabled the patch with the intention of attempting to fix it. I ran the build again, and it apparently didn't pick up the change. It skipped the kernel build and used the cached kernel. I had to delete the deb file to get it to build the kernel.

The patch parser doesn't appear to be able to parse a patch with a mbox conversation history. The attached original file is not one of mine. It is bad and has format issues resolved as follows: I moved the first three lines comment into the email body. The patch is still messy and created warnings on the checkpatch.pl test but it should have worked. I had to disguise the mbox history except for the last email before it would parse the patch. I disguised the history email headers by adding a "-" to the beginning of each line. The modified patch works. As this is not one that I'm familiar with, I can't test it so I won't submit a PR unless requested. Attached original and modified patches. general-add-overlay-configfs.patch modified.general-add-overlay-configfs.patch

Another subtle issue that may impact other developers: build attempts to create, git add, and git commit a patch. It fails to sign the commit which is not surprising. [👉] error: gpg failed to sign the data [👉] fatal: failed to write commit object I have global signing configured: user.signingkey=xxxxxxxxxxxxx commit.gpgsign=true Attempting to override this locally didn't work, I reset it globally and that worked. (git config --global commit.gpgsign false) This is not ideal for me... any ideas? Otherwise I can live with it.

My patch tested fine with the current Linux Kernel checkpatch.pl (https://www.kernel.org/doc/html/latest/dev-tools/checkpatch.html), and I couldn't see an obvious issue so I tried some manual white-space cleaning stuff, namely trim trailing spaces and remove extra file end line-feeds. It turns out that there were trailing spaces on some blank lines and extra linefeed on the end of the file. I don't know which caused the parsing issue. I will do a PR to improve the patch, but maybe the parser could perhaps be made to clean up or cope with such things automatically.

Mmmm...... ouch, that sounds painful, and it's probably not possible to cater to "a _thousand_ different ways" if those ways are unknown, so I guess some new parsing ideas may have to evolve.

When I try this build for a Rockchip64 board orangepi-r1plus-lts, a lot of patches including one of mine produce an error: "patch is not properly mbox-formatted". I guess that checking has become more strict? I don't see a log with patch errors, making it difficult to know what is wrong.

Nearly there.... still one issue. Easy fix, I think. Something goes wrong with rootfs-to-image.sh DEBUG: print free space. If I comment out from line 61 to 63 in rootfs-to-image.sh the build works: # DEBUG: print free space local freespace freespace=$(LC_ALL=C df -h) display_alert "Free SD cache" "$(echo "$freespace" | grep "${SDCARD}" | awk '{print $5}')" "info" display_alert "Mount point" "$(echo "$freespace" | grep "${MOUNT}" | head -1 | awk '{print $5}')" "info" Cause: df -h produces a warning/error along with the listing on this computer: $ df -h df: /root/.cache/doc: Operation not permitted Filesystem Size Used Avail Use% Mounted on udev 4.6G 0 4.6G 0% /dev tmpfs 942M 1.4M 940M 1% /run /dev/sda6 135G 92G 37G 72% / ..... etc If I change line 61 in rootfs-to-image.sh to this, the build works: freespace=$(LC_ALL=C df -h) || true armbian-build-bb4a34a2-99b3-43a0-bde9-afa12d894fe4.ansitxt.log output.log

Much better. Dependencies install, but ntpdate failed and aborted. (log attached) Ntpd is running on this computer. Ntpdate is not necessary, perhaps warn rather than abort. --> 🐸 167: 2401396 - 2401396 - 2401396: ehBE: command: Command debug [ /bin/bash -e -o pipefail -c ntpdate pool.ntp.org ] 6 Jan 15:11:45 ntpdate[2405625]: the NTP socket is in use, exiting If I stop the ntp service the build continues past this point. If I change line 105 in prepare-host.sh to this, it continues with an error in the logs: run_host_command_logged ntpdate "${NTP_SERVER:-pool.ntp.org}" || true armbian-build-99cee99b-287b-4fa2-907d-423fa914a11c.ansitxt.log

armbian-build-decd7989-926c-4c3c-8750-e97496c5dc56.ansitxt.log armbian-build-decd7989-926c-4c3c-8750-e97496c5dc56.md

Docker for Linux Mint various versions (I haven't used any of these) - https://hub.docker.com/u/linuxmintd # git branch -v * armbian-next f558a285a ------------------------ armbian-next END marker ----------------------------- Build recognizes Python version issue but appears to still use 3.9: [\U0001f449] --> \U0001f3a3 2: 2391286 - 2391286 - 2391286: ehBE: extensions: Extension Method being called: extension_prepare_config [ hook: extension_prepare_config ] [\U0001f449] --> \U0001f6b8 2: 2391286 - 2391286 - 2391286: ehBE: warn: Using '/usr/bin/python3.9' for [ 'una' has outdated python3, using python3.9 ] [\U0001f449] --> \U0001f438 2: 2391286 - 2391286 - 2391286: ehBE: command: Command debug [ /bin/bash -e -o pipefail -c env -i 'PYTHONUNBUFFERED=yes' 'PYTHONPYCACHEPREFIX=/mnt/data/build-armbian/armbian-next/build/cache/pycache' 'LOG_DEBUG=' 'SRC=/mnt/data/build-armbian/armbian-next/build' 'OUTPUT=/tmp/tmp.rIciovpubR' 'ASSET_LOG_BASE=/mnt/data/build-armbian/armbian-next/build/.tmp/logs-decd7989-926c-4c3c-8750-e97496c5dc56/006.' 'ARCH=armhf' 'RELEASE=bullseye' 'LINUXFAMILY=sunxi' 'BOARD=orangepi-r1' 'USERPATCHES_PATH=/mnt/data/build-armbian/armbian-next/build/userpatches' 'SELECTED_CONFIGURATION=cli_minimal' 'REMOVE_PACKAGES=' 'REMOVE_PACKAGES_REFS=' 'EXTRA_PACKAGES_ROOTFS=' 'EXTRA_PACKAGES_ROOTFS_REFS=' 'EXTRA_PACKAGES_IMAGE=' 'EXTRA_PACKAGES_IMAGE_REFS=' 'BUILD_DESKTOP=no' 'DESKTOP_ENVIRONMENT=' 'DESKTOP_ENVIRONMENT_CONFIG_NAME=' 'DESKTOP_APPGROUPS_SELECTED=' 'PACKAGE_LIST_FAMILY=' 'PACKAGE_LIST_BOARD=' 'PACKAGE_LIST_BOARD_REMOVE=' 'PACKAGE_LIST_FAMILY_REMOVE=' /usr/bin/python3.9 /mnt/data/build-armbian/armbian-next/build/lib/tools/aggregation.py ] [\U0001f449] env: \u2018/usr/bin/python3.9\u2019: No such file or directory I won't upgrade yet, in case it is useful for testing version compare and etc. I much prefer Mint, but also have a (slow) Ubuntu Jammy build computer that I can try.

Thanks for the effort Ricardo. I'm not sure that accommodating is perhaps the best option. Just change supported versions should do the trick. If the versions supported did not include una then users would know to upgrade. I will test your changes but then I should probably upgrade to 21.1 vera.

I watched the video of the Armbian developers meeting 1/4/2023 and it looks like you want testing. Not sure where to post this. Please feel free to move it. I tested the armbian-next branch build for a couple of my boards. The build computer is Linux Mint 20.3 (Una) has a dedicated separate drive for Armbian builds and works well for current armbian build. The build errors as per attached. Is this a known issue or perhaps I don't understand something? build_output.txt armbian-build-2500d172-dffc-4a16-97c4-3b509abcbd0f.ansitxt.log armbian-build-2500d172-dffc-4a16-97c4-3b509abcbd0f.md

you're welcome.

In my opinion, for what it's worth , that's exactly the sort of thing customize-image.sh is intended to be used for. It's arguably less "hackish" than many other hacks, because it is intended for the purpose.

I don't know if this will work and I can't test because I don't have your board. From a different OS same error: https://my-take-on.tech/2021/05/07/fix-docker-cgroup-errors-after-systemd-248-update/ The write-up indicates that might only affect old docker containers, so the possible fix below may only work for those containers. To do the same thing in Armbian: In /boot/armbianEnv.txt add a line (or if extraargs already exists add an extra argument separated by a comma) extraargs="systemd.unified_cgroup_hierarchy=0" Reboot and try again. Good luck. Let us know the outcome either way. Edit: great this worked for Walden.

I agree, this would be good.

orangepi-r1plus-lts works. iperf values as expected: Armbian_22.11.0_Orangepi-r1plus-lts_jammy_current_5.15.79.img.xz Armbian_22.11.0_Orangepi-r1plus-lts_bullseye_current_5.15.79.img.xz RC testing form submitted

Using Armbian build: If creating a patch for u-boot, the dts will go in build/cache/sources/u-boot/v2022.07/arch/arm/dts/ Or similar depending on uboot version. If creating a patch for kernel, the dts will go in build/cache/sources/linux-mainline/6.0/arch/arm64/boot/dts/rockchip/ Or similar depending on kernel version and architecture. Don't forget to modify the Makefile's

orangepi-r1 works. iperf values as expected: Armbian_22.11.0_Orangepi-r1_jammy_current_5.15.79.img.xz Armbian_22.11.0_Orangepi-r1_bullseye_current_5.15.79.img.xz RC testing form submitted

orangepizeroplus works: Armbian_22.11.0_Orangepizeroplus_jammy_current_5.15.79.img.xz Armbian_22.11.0_Orangepizeroplus_bullseye_current_5.15.79.img.xz RC testing form submitted