Bootc gives me "error due to: Non-ASCII characters found"

General
1

I wanted to take the plunge and switch my Bluefin from gts to lts and I got this error:

# bootc switch ghcr.io/ublue-os/bluefin:lts --enforce-container-sigpolicy
layers already present: 2; layers needed: 70 (2.4 GB)
Fetched layers: 2.19 GiB in 3 minutes (12.04 MiB/s)                                                                                         /proc/self/fd/30/usr/etc/selinux/targeted/contexts/files/file_contexts.bin:  line 1 error due to: Non-ASCII characters found
/proc/self/fd/30/usr/etc/selinux/targeted/contexts/files/file_contexts.homedirs.bin:  line 1 error due to: Non-ASCII characters found
⠐ Deploying                                                                                                                                 /proc/self/fd/24/usr/etc/selinux/targeted/contexts/files/file_contexts.bin:  line 1 error due to: Non-ASCII characters found
/proc/self/fd/24/usr/etc/selinux/targeted/contexts/files/file_contexts.homedirs.bin:  line 1 error due to: Non-ASCII characters found
⠉ Deploying                                                                                                                                 /proc/self/fd/24/etc/selinux/targeted/contexts/files/file_contexts.bin:  line 1 error due to: Non-ASCII characters found
/proc/self/fd/24/etc/selinux/targeted/contexts/files/file_contexts.homedirs.bin:  line 1 error due to: Non-ASCII characters found
  Deploying: done (8 seconds)                                                                                                               Pruned images: 1 (layers: 60, objsize: 6.8 GB)
Queued for next boot: ostree-image-signed:docker://ghcr.io/ublue-os/bluefin:lts
  Version: stream10.1
  Digest: sha256:53710fb56d5a0bc0ad089676d8833de8f7ab0acaf9aa250034825c1445f9f566

The only thing I did that is “special” is that I followed these instructions to add a disable composefs kernel param.

What does the error mean? What non ASCII character could it be referring to?

EDIT: after a reboot I was unable to start LTS. I got the error “SHIM not found” and was forced to use the previous grub entry, so my situation is now:

 ~  rpm-ostree status    
State: idle
AutomaticUpdates: stage; rpm-ostreed-automatic.timer: no runs since boot
Deployments:
  ostree-image-signed:docker://ghcr.io/ublue-os/bluefin:lts
                   Digest: sha256:53710fb56d5a0bc0ad089676d8833de8f7ab0acaf9aa250034825c1445f9f566
                  Version: stream10.1 (2025-06-02T03:25:12Z)
                     Diff: 553 upgraded, 733 downgraded, 1237 removed, 133 added

● ostree-unverified-registry:ghcr.io/ublue-os/bluefin-dx-nvidia-open:gts
                   Digest: sha256:da18376bd2244a6971a00f31cf1dc25e9764ce4dad1a031a472b12dc82d5644a
                  Version: gts-41.20250525 (2025-05-25T06:16:50Z)

  ostree-unverified-registry:ghcr.io/ublue-os/bluefin-dx-nvidia-open:gts
                   Digest: sha256:5903d9ce291e6d07605b94579d2454096ca7cbc6ecae948a6988e76d9d5b7cbc
                  Version: gts-41.20250514 (2025-05-14T19:26:29Z)
                   Pinned: yes
2

I have switched to bluefin-dx-nvidia-open:stable and removed the offending bluefin:lts with no issues:

 # rpm-ostree status
State: idle
AutomaticUpdates: stage; rpm-ostreed-automatic.timer: no runs since boot
Deployments:
● ostree-image-signed:docker://ghcr.io/ublue-os/bluefin-dx-nvidia-open:stable
                   Digest: sha256:a635062e723adabe0b8094c1ba3164cca99b9f4f93cbd1a544e6e5cb03de4738
                  Version: 42.20250601.2 (2025-06-01T06:35:01Z)

  ostree-unverified-registry:ghcr.io/ublue-os/bluefin-dx-nvidia-open:gts
                   Digest: sha256:da18376bd2244a6971a00f31cf1dc25e9764ce4dad1a031a472b12dc82d5644a
                  Version: gts-41.20250525 (2025-05-25T06:16:50Z)
                   Pinned: yes

  ostree-unverified-registry:ghcr.io/ublue-os/bluefin-dx-nvidia-open:gts
                   Digest: sha256:5903d9ce291e6d07605b94579d2454096ca7cbc6ecae948a6988e76d9d5b7cbc
                  Version: gts-41.20250514 (2025-05-14T19:26:29Z)
                   Pinned: yes

Is there some limitation to switching from bluefin-dx to the new centos-based images?

3

Yes, it is unsupported, please see: Introduction to Bluefin LTS | Bluefin

4

Thank you, I marked this as solved.

I am curious as to why this decision was made:

  • Rebasing: We will explicitly not support rebasing from the Fedora based images and ensure the rebase helper keeps users protected.

I was under the impression that this would be no different than switching between Aurora/Bluefin/Bazzite/etc… What is special about the CentOS-based root image that leads to this decision?

5

They’re not supporting this as a feature (no one’s testing this) - maybe someday in the future but not sure, this is more of a question for fedora/centos than us.

6

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.