Sys-firewall has failed to start ascii codec can't encode character \xe4 in position 31

User Support
1

Hi all,

I have a problem with a fresh install. This issue is with current 4.2.0 and with 4.2.1rc1 fresh installations. And it appears no matter if I use Fedora (38 or 39) as the base template or Debian12.

So, freshly installed, I can login to the desktop, see my qubes, everything seems to work as expected. As soon as I do anything internet/network related, the system tries to start the sys-firewall Qube, and I get the following error message as desktop notification:
Qube Status: sys-firewall
Qube sys-firewall has failed to start: ’ascii’ codec can’t encode character ‘\xe4’ in position 31: ordinal not in range(128).

I have searched and not found anything, I have tried several installations with 4.2.0 and 4.2.1rc1, using Debian or Fedora as base template also for the sys-firewall Qube.

System: Intel Core i7 9700K, 32GB RAM, Gigabyte z390 Mainboard, AMD Radeon RX6800XT GPU.

Any help highly appreaciated.

All the best :slight_smile:

2
3

Hi, will try that as well. Wiping as I am typing.
4.2.0 stable should work, whether Fedora or Debian, right? Might be a bug in 4.2.1rc1 then, as this was the first installation on this nvme.

4

Yes.

If you have multiple unencrypted Qubes OS installations on the same or different disks on the same PC then maybe it could cause an issue as well.

5

No, only this one. I do have another NVMe with Windows for Gaming, and another SATA SSD for Arch Linux as my daily driver.

This NVMe is wholly for qubes, without anything else on it.

Wiping the disk with dd, creating a new partition table and installing 4.2.0 again solved the issue. I can recreate it by updating to 4.2.1rc1 or installing a fresh copy of 4.2.1rc1. I can repeatedly get it working with 4.2.0 if I wipe and start 100% fresh instead of just letting the installer do its thing.

btw., this also happens when the 4.2.1rc1 install is encrypted, but then a fresh copy of 4.2.0 wipes the disk and creates a new install. It is only reproducibly gone when I dd the disk before I install 4.2.0 again.

6

I don’t know what could cause this issue when you update dom0 from 4.2.0 to the latest updates. I guess you should open an issue on github so devs can look into it: