Red Hat Bugzilla – Bug 1108908
dnf dies immediately complaining that ascii codec can't decode 0xc3
Last modified: 2014-07-19 02:03:05 EDT
Description of problem:
When I try to use dnf rather than yum, it dies immediately with a complaint about the ascii coded trying to decode byte 0xc3. It happens only when I do it as my regular user id, not when doing it as root, or when other users run it.
It appears to be related to my username having non-ascii letters. My login is "göran".
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. dnf list kernel
Config error: 'ascii' codec can't decode byte 0xc3 in position 1: ordinal not in range(128)
List of installed and available kernel package.
I've tried to debug this using pdb. If I understand things correctly, the problem happens in dnf/yum/misc.py, on line 565 in getCacheDir. There it tries to put together a path in this way:
prefix = '%s-%s-' % (dnf.const.PREFIX, username)
This apparently fails when username isn't pure ascii.
I compared to yum, where the corresponding function has a second step when it calculates "username".
username = usertup
# we prefer ascii-only paths
username = urllib.quote(username)
Maybe this code could be ported to dnf too?
Hello, thank you for the report and all the useful information. We'll take a look.
Hm, wasn't quite as easy as that. Now I get errors like this:
23:51 mimmi$ dnf repolist
Fel: Failed to synchronize cache for repo 'fedora': Cannot prepare internal mirrorlist: Curl error: Couldn't read a file:// file for file:///var/tmp/dnf-g%C3%B6ran-9TL5Zi/x86_64/20/fedora/metalink.xml
Checking with "strace", I see it tries to open a file where the "%C3%B6" part has been decoded back again:
open("/var/tmp/dnf-g\303\266ran-9TL5Zi/x86_64/20/fedora/metalink.xml", O_RDONLY) = -1 ENOENT (No such file or directory)
This is after a while in the trace. It has accessed things under "/var/tmp/dnf-g%C3%B6ran-9TL5Zi/" many times first. So the string gets interpreted some of the time, but mostly not.
Given the error message, I'm guessing this is in libcurl, called via librepo. But that's just a guess so far. I just wanted to make a note right away so you know my suggested fix was insufficient.
I am unable to reproduce this. How did you set user name with non ascii characters? I tried to add new user by useradd, system-config-users and gnome user settings and all of them says that these characters are not allowed. I am using Fedora 19 and I tried it also in Fedora 20 docker image.
I don't remember exactly what method I used to create the account. It's a very long time ago.
But for the purpose of this experiment, why not just create an account without any special characters. Then edit /etc/passwd and /etc/shadow manually, and do "mv" on the home directory. (Strictly speaking, I guess you don't need to change the home directory name to reproduce this. It is enough with the login name.)
Fixed in the upstream.
hawkey-0.4.18-2.fc20, dnf-0.5.4-1.fc20, libsolv-0.6.4-0.git2a5c1c4.fc20 has been submitted as an update for Fedora 20.
hawkey-0.4.18-2.fc20, dnf-0.5.4-1.fc20, libsolv-0.6.4-0.git2a5c1c4.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.