[BUG] Installer exited with code 1

[MrStickyPiston]

Describe the bug
When running the installation iso and after configuring the required options (default partitioning) i get the following error in the deployment starting phase:

The command 'ostree container image deploy --sysroot=/mnt/sysimage --image=/run/install/repo/base-41 --transport=oci --no-signature-verification' exited with the code 1.

My iso was build locally using bluebuild, but someone else building using the following command had the same problem:

The issue keeps occurring, i tried about 14 times building a new iso and running it in a new vm with 16gb ram and 32gb storage.

This issue also occurred while installing ublue aurora on my laptop a few weeks ago, but i dont know how that iso is build.

To Reproduce
Steps to reproduce the behavior:

1. Build a iso using bluebuild/the command above
2. Boot the iso
3. Select a language
4. Set the new user password and username
5. Leave partitioning on automatic
6. Let it run for a few minutes
7. Get a popup window with the error

Expected behavior
It would not error and install the OS

Screenshots
Video

Desktop (please complete the following information):

• Desktop OS: Kubuntu
• Desktop Version: 24.04LTS
• Installing OS: https://github.com/MrStickyPiston/Sticky-OS
• Installing version: latest

Additional context
Add any other context about the problem here.

[detiber]

Possibly related? #146 nevermind, seems unrelated

[detiber]

Adding info from discord conversation here, as I was hitting a similar issue, and others may benefit from the context.

The error given by anaconda is an overly generic error, without context as to why the command failed.

The actual error can be found in /tmp/packaging.log on the host that failed to install... Ctrl-alt-f1 will let you get to the logs (if you can interact with the tabs), otherwise, ctrl-alt-f2 for a basic shell

More on anaconda logging/troubleshooting here: https://docs.fedoraproject.org/en-US/quick-docs/anaconda-logging/#_introduction

[detiber]

Adding additional context from discord chats:

• underlying error is related to unicode/locale handling during hte ostree container image deploy process: error: Pathname can't be converted from UTF-8 to current locale

I've done a few hacks that work around the issue with other build tooling, including:

• setting the LANG env variable in the containerfile
• adding the LANG env variable to the podman args when invoking bootc-image-builder, bootc install, etc

Using bluebuild, I've also attempted to use the containerfile module to inject ENV LANG "en_US.UTF-8" as a snippet, but it doesn't seem to be sufficient to resolve the issue when invoking using bluebuild generate-iso

[xynydev]

BlueBuild dev team member here

Note that bluebuild generate-iso is not part of this project and issues happening specifically with that should generally be reported directly to us. If there's a build-container-installer command that builds a functional ISO, while bluebuild generate-iso doesn't, feel free to file that issue separately with us and we can fix that.

It seems to me that this misconfigured ennvar is something that might be able to be fixed directly in this project too, but I'm not too familiar with how to test that hypothesis.

[MrStickyPiston]

Adding context from discord:

I was able to replicate it at some point without bluebuild, but I'm in the process of completely re-working my builds in a way that diverges quite a bit from anything resembling "normal", so not sure when I'll be able to even attempt to reproduce in a way that would be of any value
(by Detiber)

So i dont really know if this is just a bluebuild/modified build system not based on bluebuild but based on build-container-installer issue or a root build-container-installer issue.

[MrStickyPiston]

I build my project using pure build-container-installer now:

mkdir ./iso-output
sudo podman run --rm --privileged --volume ./iso-output:/build-container-installer/build --security-opt label=disable --pull=newer ghcr.io/jasonn3/build-container-installer:latest IMAGE_REPO=ghcr.io/mrstickypiston IMAGE_NAME=sticky-os IMAGE_TAG=latest VARIANT=Kinoite VERSION=41

I can confirm i get the error without the bluebuild wrapping. A link to a youtube video with the error is linked below with what happens after clicking install with the settings i described above. Im sorry that i had to use youtube but github would not let me upload files > 10mb

https://youtu.be/dY25B7U4ESo

[MrStickyPiston]

After using fedora-ostree-desktops/kinoite instead of ublue-os/kinoite-main as base image the tool successfully builds an iso that successfully installs the OS inside boxes. (Image below)

[JasonN3]

In my experience, an error from the ostree command means an issue with the image that's being installed. Since someone was able to successfully install an image from fedora-ostree-desktops and ublue-os, it's probably something missing in your image, but I will leave this issue open so it can discussed. If you can point to something that's broken here, I'll gladly fix it, but right now I'm not sure what would be broken since it works for other images.

[fiftydinar]

I experience this error now on ISO built today.

When I built the ISO on 1st December, I didn't have any issues.

Basically same version of the action (no difference between v1.2.3 & v1.2.4 in code).

I didn't have any significant package changes in that time interval in my image.

My image is vanilla Fedora Atomic based (I removed all Ublue-OS related changes to test as well).

[JasonN3]

F41 is starting to have issues in my tests now too. I'm not sure what changed that it didn't show up before. I'll update this issue when I find the issue to see if it's the same problem.

[MrStickyPiston]

Is it possible to add quay.io/fedora-ostree-desktops/XXXXX to your tests? You are currently only testing ublue-os images.

[JasonN3]

Is it possible to add quay.io/fedora-ostree-desktops/XXXXX to your tests? You are currently only testing ublue-os images.

I used to test with those images but then flatpak was removed and the tests started failing so I switched to just using the ublue images since they change less. I can look into adding them back in to just the tests without flatpak if you feel it would be beneficial. Please submit a separate Issue/Feature Request

[JasonN3]

F41 is starting to have issues in my tests now too. I'm not sure what changed that it didn't show up before. I'll update this issue when I find the issue to see if it's the same problem.

I got the same error: error: Pathname can't be converted from UTF-8 to current locale. It looks like there is currently an issue with F41 build. F39 and F40 builds are not affected. I'm going to try to block the latest version of lorax for F41 to see if that fixes it. If that works, I'll look at what has changed between the latest version and the previous version to try to identify why tar/locale is broken.

[JasonN3]

This seems to be an issue with the ublue image. This job was able to run using the image quay.io/fedora-ostree-desktops/base-atomic:41 and that succeeded.
Thank you @MrStickyPiston for suggesting adding back in the tests for the non-ublue images

[MrStickyPiston]

To test, I actually installed ublue kernel and akmods on a non ublue image the way secureblue does it and it still works, so its not that. @fiftydinar 's image is also not based on ublue (base-image: quay.io/fedora/fedora-silverblue), and even with removing the ublue changes part it does not work. I think its time to look for similarities in the non ublue part of that image and ublue images.

[RoyalOughtness]

@MrStickyPiston Your comment is very interesting to me because I'm seeing this issue when generating ISOs for secureblue 😄

[MrStickyPiston]

Since when are you seeing this? I build and installed an iso for StickyOS 2 days ago.

[RoyalOughtness]

@MrStickyPiston dunno. only recently started looking into ISOs again. It was working many months ago.

Do you see the same issue with a secureblue image like ghcr.io/secureblue/silverblue-main-hardened:latest?

[MrStickyPiston]

Sorry for the late response, i have not tried this out yet.