This is more easily reproducible in a container because the default locale might not be set or set to POSIX. The error looks like: ------------------->8---------------------------- [122/348] Installing rtkit-0:0.11-70.fc44.x86_64 100% [==================] | 45.9 MiB/s | 140.9 KiB | 00m00s >>> Running %post scriptlet: rtkit-0:0.11-70.fc44.x86_64/usr/include/c++/16/string_view:305: constexpr void std::basic_string_view<_CharT, _Traits>::remove_prefix(size_type) [with _CharT = char; _Traits = std::char_traits<char>; size_type = long unsigned int]: Assertion 'this->_M_len >= __n' failed. container exited on segmentation fault Error: while running runtime: exit status 1 ------------------->8---------------------------- Messages from systemd like Created symlink '/etc/systemd/user/sockets.target.wants/pipewire.socket' → '/usr/lib/systemd/user/pipewire.socket'. can trigger the problem due to the multi-byte character → Reproducible: Always Steps to Reproduce: 1. container=$(buildah from fedora:44) 2. buildah run $container -- dnf install -y pipewire 3. Actual Results: dnf crashes Expected Results: dnf should not crash in any circumstance [edited] This seems to only reproduce in buildah now. In the default podman shell the locale is set to C.UTF-8
Proposed as a Blocker for 44-final by Fedora user kanru using the blocker tracking app because: 🔗 Post-install requirements 🔗 Installing, removing and updating software The installed system must be able appropriately to install, remove, and update software with the default console tool for the relevant software type (e.g. default console package manager). This includes downloading of packages to be installed/updated. Install software in a fedora container fails consistently.
Thanks for the Fedora report and the PR. Upstream issue: https://github.com/rpm-software-management/dnf5/issues/2553 PR: https://github.com/rpm-software-management/dnf5/pull/2638
Discussed in a blocker review meeting [1] on 2026-03-09. The outcome was: !agreed 2443774 - RejectedBlocker (Final) - this is potentially a blocker per various criteria related to package installation, but we agreed we can't think of or demonstrate any common or criteria-covered situation where the system locale is likely to be C or POSIX [1] https://meetbot-raw.fedoraproject.org//blocker-review_matrix_fedoraproject-org/
This is really easy to hit when installing packages in a container. A lot of CI jobs running on Fedora will hit this. I don't really follow how this does not violate basic package installation criteria.
Proposed as a Blocker and Freeze Exception for 44-final by Fedora user siosm using the blocker tracking app because: Potentially impacts a lot of CI jobs that will start using F44 images soon now that F44 is in Beta.
I install packages in containers quite a lot, and haven't seen this. The first comment suggests it only happens when using buildah (not podman) which isn't a very common way to run containers. This is a conditional violation: it breaks the criterion *in the case where the system locale is C or POSIX*. We don't have an explicit criterion or footnote covering that case. So that means a subjective determination is required: how common do we expect it to be? Based on the info in the bug report at the time we made the decision, we figured it's not very common. A bare assertion that it's "really easy to hit" and "a lot of jobs will hit this" is something, but it's not really evidence. A more specific "you can hit it by doing X, Y or Z, which are common things done by developers and/or CI systems" would be more useful.
Indeed, my bad, sorry for the broad statements. I am consistently hitting this in my CI setup for building sysexts using podman and running containers in GitHub workflows, via privileged containers. Example: https://github.com/fedora-sysexts/fedora/actions/runs/22992940319/job/66757968841?pr=213 I agree that it's a somewhat uncommon setup. I've given it a try locally and I could not reproduce it on my F43 system so far so I agree that blocker is too strong. It also appears that working around the bug is relatively easy so I'm OK dropping the freeze exception too: https://github.com/fedora-sysexts/fedora/pull/213/changes/c3eb045edaf3a328de2f98eba5c3edd105b7e1de Sorry for the noise.
AGREED AcceptedFinalFreezeException Discussed at the 2026-03-16 (blocker / freeze exception) review meeting: this is accepted as an FE issue as it could affect folks on first update and require a workaround, but we will evaluate any proposed fix during freeze for its risk of affecting more important paths and only take a sufficiently safe fix. https://meetbot-raw.fedoraproject.org//blocker-review_matrix_fedoraproject-org/2026-03-16/f44-blocker-review.2026-03-16-16.01.log.txt
Affected build is dnf5-5.4.0.0-2.fc44.x86_64. A reproducer is installing a package with a postscriptlet which prints non-ASCII characters in C locale.
We have a build failure on i686: In file included from /usr/include/cppunit/TestCase.h:6, from /builddir/build/BUILD/dnf5-5.4.0.0-build/dnf5-5.4.0.0/test/libdnf5-cli/test_progressbar.hpp:24, from /builddir/build/BUILD/dnf5-5.4.0.0-build/dnf5-5.4.0.0/test/libdnf5-cli/test_progressbar.cpp:21: /builddir/build/BUILD/dnf5-5.4.0.0-build/dnf5-5.4.0.0/test/libdnf5-cli/test_progressbar.cpp: In member function ‘void ProgressbarTest::test_progress_bar_multi_byte_character()’: /builddir/build/BUILD/dnf5-5.4.0.0-build/dnf5-5.4.0.0/test/libdnf5-cli/test_progressbar.cpp:55:5: error: no matching function for call to ‘assertEquals(long unsigned int&, unsigned int&, CppUnit::SourceLine, const char [1])’ 55 | CPPUNIT_ASSERT_EQUAL(expected, num_lines); | ^ • there is 1 candidate • candidate 1: ‘template<class T> void CppUnit::assertEquals(const T&, const T&, SourceLine, const std::string&)’ /usr/include/cppunit/TestAssert.h:161:6: 161 | void assertEquals( const T& expected, | ^~~~~~~~~~~~ • template argument deduction/substitution failed: • deduced conflicting types for parameter ‘const T’ (‘long unsigned int’ and ‘unsigned int’) /builddir/build/BUILD/dnf5-5.4.0.0-build/dnf5-5.4.0.0/test/libdnf5-cli/test_progressbar.cpp:55:5: 55 | CPPUNIT_ASSERT_EQUAL(expected, num_lines); | ^
The build failure is caused by size_t having a different size on 32-bit platforms than unsigned long int. I will sent a patch upstream.
Fedora 43 (dnf5-5.2.18.0-2.fc43.x86_64) seems not to be affected.
FEDORA-2026-30fc6214bb (dnf5-5.4.0.0-3.fc44) has been submitted as an update to Fedora 44. https://bodhi.fedoraproject.org/updates/FEDORA-2026-30fc6214bb
FEDORA-2026-30fc6214bb has been pushed to the Fedora 44 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-30fc6214bb` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-30fc6214bb See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-30fc6214bb (dnf5-5.4.0.0-3.fc44) has been pushed to the Fedora 44 stable repository. If problem still persists, please make note of it in this bug report.