Applying patch/misc/rtw88/6.6/001-drivers-net-wireless-realtek-rtw88-upstream-wireless.patch fails about build

[theCalcaholic]

Thank you I'll give that a try

[igorpecovnik]

Also check how we make images via extensions - we do it for HA, OpenHab, for demo https://github.com/armbian/os/tree/main/userpatches/extensions and we can also make and distribute them automatically:

[hqnicolas]

It's fixed @theCalcaholic

[github-actions]

Jira ticket: AR-2115

[theCalcaholic]

EDIT: RELEASE is bullseye, not bullseye-security

[igorpecovnik]

Try to use branch v24.02 as there upstream sources should be frozen. Upstream sources are changing daily so its a lot of maintainainace. Tags doesn't have frozen sources and you will need to deal with this on your own. Alternatively is using main branch, which is fixed, v24.02 should probably also works.

[theCalcaholic]

That looks very interesting... Right now, I have the issue that Armbian builds tend to break basically for every release, which requires hours of testing and troubleshooting from my side. That's why I was trying to work with fixed versions in the first place. Unfortunately, branch v24.0.2 doesn't build for me for other reasons (that I've yet to troubleshoot).

However, at the moment, I'm considering moving to a immutable distro anyways (since NextcloudPi is a great fit for a immutable system as it's not really meant to be interacted with by users outside of the admin interface). Therefore, I'm not sure if it would make sense to provide a userpatch extension.
But I'll definitely keep it in mind in case I change my mind!

[igorpecovnik]

Right now, I have the issue that Armbian builds tend to break basically for every release,

This has to work well, but perhaps not the way you are doing right now. If we help you prepare this?

In past 2 years we reworked build framework and our 24.02 is the first semi "immutable" on source level. I think we forgot to freeze one or two sources, but otherwise its there. Troubles are in some legacy functions ... But on the other hand, it is significantly easier for you to build application images for various arhitectures with single extension https://github.com/armbian/os/blob/main/userpatches/extensions/ha.sh and single YAML file:
https://github.com/armbian/os/blob/main/userpatches/targets-release-apps.yaml
and leave the nasty work to us.

If you have NCPI as a docker instance, its almost the same as HA.

[theCalcaholic]

git clone --depth 1 --branch ${BRANCH} https://github.com/armbian/build armbian

# NCP userpatch
mkdir -p armbian/userpatches armbian/userpatches/overlay
cp build/armbian/armbian.sh armbian/userpatches/customize-image.sh
rsync -Aax --delete --exclude-from .gitignore --exclude *.img --exclude *.bz2 . armbian/userpatches/overlay/

# Armbian build config

cat > "armbian/userpatches/config-ncp.conf" <<EOF
BOARD="$BOARD"
BRANCH=current
RELEASE=bullseye
KERNEL_CONFIGURE=prebuilt
BUILD_DESKTOP=no
BUILD_MINIMAL=yes
USE_CCACHE=yes
INCLUDE_HOME_DIR=yes
EOF

export INCLUDE_HOME_DIR=yes


armbian/compile.sh ncp

This is basically how I've been building images ever since moving to armbian next (with BOARD being e.g. "rock64" and BRANCH being tags or main - I even tried checking out individual commits to find working versions since main tended to break so often). The script that gets actually executed (copied to armbian/userpatches/customize-image.sh is this one).

NCP does not come as a docker container. It is, as of today, a quite complex installation script that installs many services into the debian host system.
After installation, we perform a number of integration tests on the built images to ensure successful installation.

[igorpecovnik]

NCP does not come as a docker container. It is, as of today, a quite complex installation script that installs many services into the debian host system.

I understand the complexity ...

I tried ... problem seems to be related to Bullseye packages / Qemu. When Debian make a new stable release (Bookworm is out for some time), old stable starts to detiriorate. For us, it is mission impossible to deal with increasing number of problems that are not sorted out upstream anymore. I tried to build bookworm, but your script says "unsupported". How far away you are from bookworm? That would just work. And can you build natively on aarch64 machine without qemu? That might work for bullseye too.

[theCalcaholic]

@igorpecovnik Funnily enough, building with the main branch works, but with 24.02 it fails in group prepare_partitions with:

Error: Partition(s) 1 on /dev/loop3 have been written, but we have been unable to inform the kernel of the change, probably because it/they are in use.  As a result, the old partition(s) will remain in use.  You should reboot now before making further changes.

I'm currently working on bookworm support and it should hopefully land in 1-2 weeks.

Anyways, I'll use the main branch for the upcoming release and hope it won't break too soon :D
Thank you for your help and sorry for my frustration previously.

[igorpecovnik]

Anyways, I'll use the main branch for the upcoming release and hope it won't break too soon :D

IMO you should be fine. Also our next "stable" branch will be more stable in the future. An improved version of sources freezing is in the PR.

You can achieve additional hardening by applying BSPFREEZE="yes" where kernel/firmware/uboot packages won't upgrade on apt upgrade. It will apply apt-mark hold on them.

I'm currently working on bookworm support and it should hopefully land in 1-2 weeks.

That would help here too. All the best in adjusting.

and sorry for my frustration previously.

Oh, its software development. We have plenty of that around ;)

[hqnicolas]

Hello!
Same problem here

https://paste.armbian.com/aretubesey.sql

Will test the v24.02 branch

[theCalcaholic]

FYI: The main branch was working for the last release and the next release will be based on bookworm, so this shouldn't be an issue anymore for NCP.

Thank you for the support!

I'll leave the issue open for @hqnicolas, feel free to close it if it is solved for them as well or not relevant anymore