Error update DietPi from v8.23.3 to 8.24.1

[diment08]

Details:

• Date | Mon Nov 20 23:16:55 EET 2023
• Bug report | 332563f4-1cf7-4bbe-98ce-5d67edb2dad3
• DietPi version | v8.24.0 (MichaIng/master)
• Image creator |
• Pre-image |
• Hardware | RPi 4 Model B (aarch64) (ID=4)
• Kernel version | Linux DietPi 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16 BST 2023 aarch64 GNU/Linux
• Distro | bullseye (ID=6,RASPBIAN=0)
• Command | apt-get -y --allow-change-held-packages install ./package.deb
• Exit code | 100
• Software title | DietPi-Patch

Steps to reproduce:

1. ...
2. ...

Expected behaviour:

• ...

Actual behaviour:

• ...

Extra details:

• ...

Additional logs:

Reading package lists...
Building dependency tree...
Reading state information...
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 shairport-sync:arm64 : Depends: libc6:arm64 (>= 2.31-13+deb11u7) but it is not installable
                        Depends: libasound2:arm64 (>= 1.2.4-1.1) but it is not installable
                        Depends: libavahi-client3:arm64 (>= 0.8-5+deb11u2) but it is not installable
                        Depends: libsoxr0:arm64 (>= 0.1.3-4) but it is not installable
                        Depends: libconfig9:arm64 (>= 1.5-0.4) but it is not installable
                        Depends: libpopt0:arm64 (>= 1.18-2) but it is not installable
                        Depends: libglib2.0-0:arm64 (>= 2.66.8-1) but it is not installable
                        Depends: libmosquitto1:arm64 (>= 2.0.11-1+deb11u1) but it is not installable
                        Depends: libssl1.1:arm64 (>= 1.1.1w-0+deb11u1) but it is not installable
E: Unable to correct problems, you have held broken packages.

[Joulinar]

Probably similar to this one #6766

[diment08]

Hello, I've been using DietPi for a couple of years to run Signalyst's HQPlayer via NAA Daemon, I never fiddle with the thing and all updates work like a charm, first time I encounter this problem.

[Joulinar]

Please hold off for a moment, we need to find out why system is behaving like this.

[diment08]

Sure, no problem, no rush :-)

[MichaIng]

Can you paste the output of these commands:

cat /etc/debian_version
cat /boot/dietpi/.hw_model
/boot/dietpi/func/dietpi-obtain_hw_model
cat /boot/dietpi/.hw_model

EDIT: Ah sorry, I misinterpreted the issue. Please paste the output of this command instead:

apt policy libc6

[MichaIng]

Ah I found it already. On Raspbian, the packages have version strings like this 2.31-13+rpt2+rpi1+deb11u7, on Debian its 2.31-13+deb11u7, which is alphanumerical lower... although, actually then the 2.31-13+rpt2+rpi1+deb11u7 version installed on your system should satisfy >=2.31-13+deb11u7 already. Not sure why it doesn't.

However, the rpi/rpt suffixes used to be after the deb ones, but it seems that some recent pushes have changed this. Our build script already removes those suffixes from the dependency packages, but I need to check/change it so that the deb suffixes are removed as well, respectively everything after+including +rpi/+rpt.

[MichaIng]

Ah, this is all done correctly for the armv6l packages. The problem is that here an aarch64 package is installed on an armhf userland, as the systems runs a 64-bit kernel. We handle this correctly in dietpi-software but not in the patch script. I'll fix this.

[MichaIng]

Okay solved with: b87b3e2

And backported to master via: dc4cbb4

In your case, since apt upgrade will throw the error before the correct package is installed, please do this manually once:

cd /tmp
curl -fo package.deb "https://dietpi.com/downloads/binaries/$G_DISTRO_NAME/shairport-sync_armv7l.deb"
dpkg -i --force-confdef,confold package.deb
rm package.deb

[diment08]

Just tried it and the update to v8.24.1 ran flawlessly. As I understand the problem was a 32-bit userland/OS (but 64-bit kernel enabled) where wrong package variants could have been installed during patch stages as you say in your notes. Thank you very much @Joulinar and @MichaIng for your support, this community is awesome! :-)

[MichaIng]

Jep right, the mismatch between kernel and OS/userland architecture was the problem. I rechecked, and indeed this was the first time we installed DEB packages from the patch script directly, instead of doing a reinstall via dietpi-software to update some software titles (Shareport Sync in this case), just to skip some processing overhead. But that way we bypassed handling this architecture mismatch.

I think we'll implement this fix more deeply into the script which creates the related variables/entries in /boot/dietpi/.hw_model in the first place, so across all our scripts, they will always represent the OS/userland architecture, not necessarily the kernel architecture. We'll need to review the cases where these variables are used to assure this does not cause issues, but I cannot think of a case where it does:

• https://github.com/search?q=repo%3AMichaIng%2FDietPi%20G_HW_ARCH&type=code