Cubic fails to enter Virtual Environment (Exit Code 1) despite successful manual chroot on ARM64

[gphonetest2025-hash]

Describe the question

I am experiencing a persistent failure when transitioning from the Extract page to the Terminal page while customizing an Ubuntu 24.04.1 ARM64 Server ISO on an ARM64 (aarch64) host.

Symptoms:

During the extraction process, the logs show: rsync error: some files/attrs were not transferred (code 23).

After clicking "Next", Cubic attempts to enter the virtual environment but fails 3 consecutive times with Exit Code 1.

The specific error message is: Virtual environment status message..... You are not in the virtual environment.

Full Log: (ref attach cubic_error_3.txt)

What you have tried

Manual Chroot Test: I have verified that I can successfully enter the virtual environment manually by running sudo chroot /path/to/custom-root /bin/bash. This suggests that the extracted filesystem is functional, but Cubic's automated terminal initialization is failing.

Environment Cleanup: I have deleted the project directory and started from scratch multiple times, but the issue persists at the same stage.

Expected behavior

Cubic should extract the SquashFS files without attribute errors (no rsync code 23) and successfully open the interactive Terminal (chroot) window for customization.

OS Information:

Architecture: ARM64 (aarch64)

Cubic Information:

Cubic Version: 2026.01.96-release202601030426ubuntu24.04.1

ISO Customizing: ubuntu-24.04.1-live-server-arm64.iso

cubic_error_3.txt

[gphonetest2025-hash]

@PJ-Singh-001 any suggestion for this ?

[PJ-Singh-001]

I don't think this is due to the rsync error in your logs (which you confirmed by successfully chroot-ing).

Cubic uses systemd-nspawn instead of chroot.
What happens if you execute the following from a terminal?...

sudo systemd-nspawn --notify-ready=yes --register=yes --machine="cubic" --directory="/home/ubuntu/CustomUbuntuProject/custom-root"

(I do not have an ARM machine to test this on; there may be a difference on how how systemd-nspawn behaves on this hardware).

[gphonetest2025-hash]

@PJ-Singh-001 Thank you for your reply.

[gphonetest2025-hash]

I have a question: I've noticed that I can successfully run the virtual environment with an amd64 ISO , but it fails with the arm64 ISO . Why is there such a difference?
@PJ-Singh-001

[gphonetest2025-hash]

@PJ-Singh-001 I would like to ask: Does Cubic officially support customizing ARM64 (aarch64) architecture ISOs?

I have noticed that while I can successfully customize AMD64 ISOs, I consistently encounter issues entering the virtual environment when working with ARM64 ISOs.

[PJ-Singh-001]

The builds are for AMD64.
However, Cubic is written in Python and it should theoretically work on other architectures.

Are you trying to customize an ARM64 ISO on an AMD64 computer (or vice-versa)?
Of so, that will not work.

(I think you mentioned you were customizing an ARM64 ISO on an ARM64 machine in your first coment, but just confirming).

[PJ-Singh-001]

Correction, Cubic builds for the following architectures:

• AMD x86-64 (amd64)
• AMD64 x86-64-v3 (amd64v3)
• ARM ARMv8 (arm64)
• ARM ARMv7 Hard Float (armhf)
• Intel x86 (i386)
• PowerPC (powerpc)
• PowerPC64 Little-Endian (ppc64el)
• RISC-V 64-bit (riscv64)
• IBM System z (s390x)

I just added AMD64 x86-64-v3 (amd64v3) and RISC-V 64-bit (riscv64).

I haven't tested on all of these architectures, as I expect the Linux libraries and dependencies to be the same across these platforms.