iso installation error: Pathname can't be converted from UTF-8 to current locale

[white-gecko]

When I generate an iso from my image, and try to install it, the installation breaks after a while with the message:

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

When I open the shell with ctrl-alt-f2 and look into /tmp/packaging.log I find the actual error to be:

error: Pathname can't be converted from UTF-8 to current locale

This is probably the same issue as reported here: https://github.com/JasonN3/build-container-installer/issues/150

Since I experience this issue specifically with bluebuild generate-iso but I don't understand the details about the maybe missing env var and if this issue is specific to bluebuild, as pointed out in this comment: https://github.com/JasonN3/build-container-installer/issues/150#issuecomment-2543230531 I just feel free to report the issue here ;-)

[blueniri]

Just ran into this as well. I was stepping through the tutorial (https://blue-build.org/how-to/generate-iso/), generated the ISO, and am running into this. This was with the default out-of-the-box generated recipe; zero customization.

When running in a VM to test, the installation eventually fails with:

Pathname can't be converted from UTF-8 to current locale.

I changed the base image to see if it made a difference, but it didn't. Same error.

Recipe.yml:

---
# yaml-language-server: $schema=https://schema.blue-build.org/recipe-v1.json
# image will be published to ghcr.io/<user>/<name>
name: blue-niri-os
# description will be included in the image's metadata
description: This is my personal OS image.

# the base image to build on top of (FROM) and the version tag to use
base-image: ghcr.io/ublue-os/base-main
image-version: 41 # latest is also supported if you want new updates ASAP

# module configuration, executed in order
# you can include multiple instances of the same module
modules:
  - type: files
    files:
      - source: system
        destination: / # copies files/system/* (* means everything inside it) into your image's root folder /

  - type: rpm-ostree
    repos:
      - https://copr.fedorainfracloud.org/coprs/atim/starship/repo/fedora-%OS_VERSION%/atim-starship-fedora-%OS_VERSION%.repo
    install:
      - micro
      - starship
    remove:
      # example: removing firefox (in favor of the flatpak)
      # "firefox" is the main package, "firefox-langpacks" is a dependency
      - firefox
      - firefox-langpacks # also remove firefox dependency (not required for all packages, this is a special case)

  - type: default-flatpaks
    notify: true # Send notification after install/uninstall is finished (true/false)
    system:
      # If no repo information is specified, Flathub will be used by default
      install:
        - org.mozilla.firefox
        - org.gnome.Loupe
      remove:
        - org.gnome.eog
    user: {} # Also add Flathub user repo, but no user packages

  - type: signing # this sets up the proper policy & signing files for signed images to work fully

[blueniri]

To workaround and get things going, I've abandoned the ISO utility/creation in favor of kickstart.

I host a lightweight http server to offer a ks.cfg file containing the following:

base-image: ghcr.io/ublue-os/base-main

Then I boot off a Fedora server netinst and edit (append) the following to the boot line, then F10 to boot, ex:

... inst.ks=http://10.11.12.13:8080/ks.cfg

Anaconda takes over, allowing me to use the installation GUI for disk partitions/etc. and then applies the base image.

[white-gecko]

Hey @blueniri how did you get this working?

(edit: I got it with the inst.ks option but now the installer will not start.)

Those are my steps:

I have a file ks.cfg:

base-image: ghcr.io/white-gecko/bluejay

That I server with python -m http.server --directory . 8080

I got the "Fedora Server 41Network Install iso" from https://fedoraproject.org/server/download (link). I write it to a a pen drive with the media writer. Boot it, in its GRUB on the "Install Fedora 41" entry I press [e] and add [edit] to the linuxefi line the following[/edit]:

inst.ks=http://192.168.XXX.XXX:8080/ks.cfg

so it looks like:

setparams 'Install Fedora 41'

        linuxefi /images/pxeboot/vmlinuz inst.stage2=hd:LABEL=Fedora-S-dvd-x86_64-41 inst.ks=http://192.168.XXX.XXX:8080/ks.cfg quiet
        initrdefi /images/pxeboot/initrd.img
        

and press F10. [edit] I see, how it retrieves the ks.cfg file from my http server but I get the error:

An error occurred during reading the kickstart file:
The following problem occurred on line 1 of the kickstart file:

Unknown command: base-image:

The installer will now terminate.

[/edit]

[white-gecko]

@blueniri would it be possible for you to paste your complte ks.cfg file?

[anh0516]

I'm experiencing the same issue when trying to build a base image.

@blueniri What exactly did you put in your ks.cfg? There isn't a base-image option listed, even in the latest version of the docs https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/automatically_installing_rhel/kickstart-commands-and-options-reference_rhel-installer.

[gmpinder]

Ok, so according to @fiftydinar in our Discord server, this issue started showing up because of the RPM based install of just that Universal Blue was using. It has some Chinese characters in the README that was causing builds to fail. They moved to installing it from the releases page instead and that solved the issue.

https://docs.bazzite.gg/General/Installation_Guide/troubleshoot_guide/#error-code-1

[fiftydinar]

Ok, so according to @fiftydinar in our Discord server, this issue started showing up because of the RPM based install of just that Universal Blue was using. It has some Chinese characters in the README that was causing builds to fail. They moved to installing it from the releases page instead and that solved the issue.

https://docs.bazzite.gg/General/Installation_Guide/troubleshoot_guide/#error-code-1

To add on this, you need to be sure that just wasn't ever installed in the image, so removing the existing just RPM doesn't fix it, as removed stuff still remains in ostree layer, which would trigger the issue again.

[gmpinder]

To add on this, you need to be sure that just wasn't ever installed in the image, so removing the existing just RPM doesn't fix it, as removed stuff still remains in ostree layer, which would trigger the issue again.

You think this could be solved with rechunk?

[fiftydinar]

You think this could be solved with rechunk?

It theoretically should, I didn't try it.

[luizansounds]

Confirmed fix using rechunk, it correctly purges the just from the installed image