Package 'apt:amd64' has no installation candidate

[IsaacJT]

Problem description

Building an arm64 Debian image using kiwi-boxed-plugin (haven't tested natively yet) sometimes triggers the following error message when the OBS apt repository is included:

[ DEBUG   ]: 11:32:29 | EXEC: Failed with stderr: E: Package 'apt:amd64' has no installation candidate
, stdout: Reading package lists...
Building dependency tree...
Package apt:amd64 is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

This is not reproducible every time - every ~3rd time that the build is run it works without any issues.

Unfortunately adding architectures="arm64", introduced in #2640, does not solve this issue.

Expected behaviour

The image can be successfully built with the OBS repository included reliably every time.

Steps to reproduce the behaviour

Add the following repository to a Debian arm64 image description:

    <repository type="apt-deb" repository_gpgcheck="false" architectures="arm64">
        <source path="obs://Virtualization:Appliances:Builder/Debian_12"/>
    </repository>

OS and Software information

• KIWI version: 10.1.12
• Operating system host version: Debian 12
• Operating system target version: Debian 12
• Open Build Service version (N/A if not using OBS): N/A
• Koji version (N/A if not using Koji): N/A

[IsaacJT]

Hi @schaefi, unfortunately this is rearing its ugly head again :(

[schaefi]

Hi @IsaacJT , yes I also heard it from other users. The Architectures setting is in place as you suggested but it still happens occasionally. The only stable solution found was to re-organize the repos building kiwi packages for Debian to be no longer multiarch. I did that a few days ago and that affects the repo definition as follows:

• for amd64

<repository type="apt-deb" repository_gpgcheck="false" package_gpgcheck="false" imageinclude="true" arch="x86_64">
    <source path="obs://Virtualization:Appliances:Builder/xUbuntu_24.04_x86_64"/>
</repository>

• for arm64

<repository type="apt-deb" repository_gpgcheck="false" package_gpgcheck="false" imageinclude="true" arch="aarch64">
    <source path="obs://Virtualization:Appliances:Builder/xUbuntu_24.04_aarch64"/>
</repository>

This worked for me, let me know if this helps you too ?

Thanks

[IsaacJT]

Unfortunately we need the Debian 12 repo - is there any chance you could also please reorganise that?

[schaefi]

@IsaacJT yep, done

Debian_12_x86_64     x86_64     scheduled
Debian_12_aarch64    aarch64    scheduled

you need to wait for the build to finish and publish though...

[IsaacJT]

Thanks! I'll let you know if it helps.

I haven't been able to reproduce the issue outside of Kiwi, and not for lack of trying... I'm really not sure where it's coming from.

[IsaacJT]

Thanks @schaefi - that seems to have fixed it. I'll close this now :)

[IsaacJT]

Hi @schaefi unfortunately I'm seeing this again... but this time on an arm64 build server. Building https://github.com/OSInside/kiwi-descriptions/tree/main/ubuntu/aarch64/ubuntu-noble-rpi on Debian 12 arm64 results in the following:

[ ERROR   ]: 13:55:24 | KiwiDebianBootstrapError: KiwiCommandError: apt-get: stderr: E: Unable to correct problems, you have held broken packages.
, stdout: Reading package lists...
Building dependency tree...
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:
 apt : Conflicts: apt:armhf but 2.7.14build2 is to be installed
 apt:armhf : Conflicts: apt but 2.7.14build2 is to be installed
 base-files : Conflicts: base-files:armhf
 base-files:armhf : Conflicts: base-files
 base-passwd : Conflicts: base-passwd:armhf
 base-passwd:armhf : Conflicts: base-passwd
 bash : Conflicts: bash:armhf
 bash:armhf : Conflicts: bash
 bsdutils : Conflicts: bsdutils:armhf
 bsdutils:armhf : Conflicts: bsdutils
 coreutils : Conflicts: coreutils:armhf
 coreutils:armhf : Conflicts: coreutils
 dash : Conflicts: dash:armhf
 dash:armhf : Conflicts: dash
 debianutils : Conflicts: debianutils:armhf
 debianutils:armhf : Conflicts: debianutils
 diffutils : Conflicts: diffutils:armhf but 1:3.10-1build1 is to be installed
 diffutils:armhf : Conflicts: diffutils but 1:3.10-1build1 is to be installed
 dpkg : Conflicts: dpkg:armhf
 dpkg:armhf : Conflicts: dpkg
 findutils : Conflicts: findutils:armhf
 findutils:armhf : Conflicts: findutils
 grep : Conflicts: grep:armhf
 grep:armhf : Conflicts: grep
 gzip : Conflicts: gzip:armhf but 1.12-1ubuntu3 is to be installed
 gzip:armhf : Conflicts: gzip but 1.12-1ubuntu3 is to be installed
 hostname : Conflicts: hostname:armhf but 3.23+nmu2ubuntu2 is to be installed
 hostname:armhf : Conflicts: hostname but 3.23+nmu2ubuntu2 is to be installed
 libc-bin : Conflicts: libc-bin:armhf
 libc-bin:armhf : Conflicts: libc-bin
 login : Conflicts: login:armhf
 login:armhf : Conflicts: login
 ncurses-bin : Conflicts: ncurses-bin:armhf
 ncurses-bin:armhf : Conflicts: ncurses-bin
 perl-base : Conflicts: perl-base:armhf but 5.38.2-3.2build2 is to be installed
 perl-base:armhf : Conflicts: perl-base but 5.38.2-3.2build2 is to be installed
 sed : Conflicts: sed:armhf
 sed:armhf : Conflicts: sed
 sysvinit-utils : Conflicts: sysvinit-utils:armhf
 sysvinit-utils:armhf : Conflicts: sysvinit-utils
 tar : Conflicts: tar:armhf
 tar:armhf : Conflicts: tar
 util-linux : Conflicts: util-linux:armhf
 util-linux:armhf : Conflicts: util-linux

[IsaacJT]

Actually, adding architectures="arm64" to each of the sources does fix this, so it might be a different but related problem

[schaefi]

@IsaacJT I have no idea how to fix this on the kiwi side. From my perspective this is an issue when using apt for bootstrap, but I don't see what we could change here. As soon as the resolved (apt) has more metadata than only one architecture several very weird things happens.

At the moment we offer two workarounds for this

1. You already mentioned it with architectures="arm64" which set Architectures to the generated repo files
2. Don't build multiarch repos, which we can only influence on e.g. the open buildservice but of course not on any other repository

I'm sorry I feel stuck with this issue. I'm happy that there is at least a workaround available