Created attachment 1725612 [details] storage.conf for test case Description of problem: If I configure storage to a directory which contains non-ASCII characters in the name, it seems podman can no longer start any containers. Version-Release number of selected component (if applicable): podman-2.1.1-12.fc33.x86_64 conmon-2.0.21-3.fc33.x86_64 How reproducible: Every time Steps to Reproduce: 1. Install a .config/containers/storage.conf as in attachment 2. podman run -it --rm alpine Actual results: kalle$ podman run -it --rm alpine Trying to pull registry.fedoraproject.org/alpine... manifest unknown: manifest unknown Trying to pull registry.access.redhat.com/alpine... name unknown: Repo not found Trying to pull registry.centos.org/alpine... manifest unknown: manifest unknown Trying to pull docker.io/library/alpine... Getting image source signatures Copying blob 188c0c94c7c5 done Copying config d6e46aa247 done Writing manifest to image destination Storing signatures conmon: option parsing failed: Invalid byte sequence in conversion input Error: write child: broken pipe Expected results: A prompt from alpine Additional info: If I change from "göran" to "goran" in the config file, the contaner starts successfully. That makes me suspect the "invalid byte sequence" refers to my "ö" in the path. The error message hints this could be a conmon rather than podman problem. As I'm uncertain about this, I start by assigning to the command I'm using.
Created attachment 1725613 [details] Log from running podman with debug output
I don't think we have a Conmon component, but this definitely looks like a Conmon bug. Assigning to Peter for now.
what is the output of `locale`?
I'm running in the Swedish locale: kalle$ locale LANG=sv_SE.UTF-8 LC_CTYPE="sv_SE.UTF-8" LC_NUMERIC="sv_SE.UTF-8" LC_TIME="sv_SE.UTF-8" LC_COLLATE="sv_SE.UTF-8" LC_MONETARY="sv_SE.UTF-8" LC_MESSAGES="sv_SE.UTF-8" LC_PAPER="sv_SE.UTF-8" LC_NAME="sv_SE.UTF-8" LC_ADDRESS="sv_SE.UTF-8" LC_TELEPHONE="sv_SE.UTF-8" LC_MEASUREMENT="sv_SE.UTF-8" LC_IDENTIFICATION="sv_SE.UTF-8" LC_ALL=
are you able to build conmon from source and let me know if https://github.com/containers/conmon/pull/215 works for you?
I'll give it a try shortly.
Unfortunately, I don't see any difference. Just to make sure I'm not doing something wrong, this is what I did: - git clone https://github.com/haircommander/conmon.git - git checkout --track origin/locale - make - sudo make PREFIX=/usr install # Thereby overwriting the binary from the conmon package - killall -v 'podman pause' # Also tried "podman system migrate" - podman run -it --rm alpine I still get the same error as in comment 0.
can you run with `--log-level debug` it should show which conmon binary was chosen. That order is defined in containers.conf I believe
Created attachment 1726001 [details] Log from running podman with debug output using patched conmon Oh, there is actually more than one installed! I thought I was safe when I replaced the one in /usr/bin. But it does not seem to be the reason it didn't help. The log indicates it is indeed /usr/bin/conomon that is being used.
This message is a reminder that Fedora 33 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '33'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 33 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Except for a slight variation in the error message, the problem remains the same in F35. podman-3.4.1-1.fc35.x86_64 conmon-2.0.30-2.fc35.x86_64
This message is a reminder that Fedora Linux 35 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 35 on 2022-12-13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '35'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 35 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
The problem remains in F37. podman-4.3.1-1.fc37.x86_64 conmon-2.1.5-1.fc37.x86_64
(In reply to Göran Uddeborg from comment #13) > The problem remains in F37. > > podman-4.3.1-1.fc37.x86_64 > conmon-2.1.5-1.fc37.x86_64 Are you still seeing this issue with the latest podman 4.5.0 and conmon 2.1.7 ?
I don't have convenient access to any F37 system, but I tried on F38 (podman-4.5.0-1.fc38.x86_64 and conmon-2.1.7-2.fc38.x86_64). The problem is still there. There is an insignificant variation in the error message, but it fails in the same way. Downloading the image works fine, but running it does not.
This message is a reminder that Fedora Linux 38 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 38 on 2024-05-21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '38'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 38 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Seems to be working in F40. :-)