UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 47: ordinal not in range(128)

[desci]

Qubes OS version (e.g., R3.2):

R3.2

Affected TemplateVMs (e.g., fedora-23, if applicable):

Not sure

---

Expected behavior:

AppVM starting either via Qubes Manager, XFCE/KDE menu or dom0 console

Actual behavior:

Some AppVMs won't start, following error given:

UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 47: ordinal not in range(128)

----
line: vm.name, thread_monitor.error_msg),
func: start_vm
line no.: 1217
file: /usr/lib64/python2.7/site-packages/qubesmanager/main.py
----
line: self.start_vm(vm)
func: action_resumevm_triggered
line no.: 1195
file: /usr/lib64/python2.7/site-packages/qubesmanager/main.py

Steps to reproduce the behavior:

Updated all TemplateVMs and dom0 after months of inactivity, rebooted the system.

Some AppVMs that were running during the updating process no longer start. Some which were also running do start.

Not sure if it's random or if there's a way to list affected AppVMs to trace the problem.

General notes:

Problem persists across reboots.

Changing the AppVM template does not make difference.

Cloning the AppVM inherits the problem to the clones.

I'm sorry about the descriptive title, you may edit the OP and the title at will.

---

Related issues:

[andrewdavidwong]

Are there non-ASCII characters in the VM name?

[andrewdavidwong]

Are there non-ASCII characters in the VM name?

[desci]

@andrewdavidwong no, just regular -, most doesn't even have that.

It seems that trying to change a ProxyVM's NetVM while it is running sometimes produces this as well.

[desci]

@andrewdavidwong no, just regular -, most doesn't even have that.

It seems that trying to change a ProxyVM's NetVM while it is running sometimes produces this as well.

[desci]

Some VMs that started showing this error randomly showed a message saying that an older kernel couldn't be found (4.4.14-11).

I changed in the VM's advanced tab of the qubes manager the kernel from default (4.4.55-11) to 4.4.55-11 and it started. This all started to happen after a dom0 upgrade from a long time without system upgrades.

The original AppVMs which made me open this issue are nhot starting however, even if I change both its TemplateVM kernel and its kernel. The old kernel error keeps poping up.

[desci]

Some VMs that started showing this error randomly showed a message saying that an older kernel couldn't be found (4.4.14-11).

I changed in the VM's advanced tab of the qubes manager the kernel from default (4.4.55-11) to 4.4.55-11 and it started. This all started to happen after a dom0 upgrade from a long time without system upgrades.

The original AppVMs which made me open this issue are nhot starting however, even if I change both its TemplateVM kernel and its kernel. The old kernel error keeps poping up.

[andrewdavidwong]

Some VMs that started showing this error randomly showed a message saying that an older kernel couldn't be found (4.4.14-11).

I changed in the VM's advanced tab of the qubes manager the kernel from default (4.4.55-11) to 4.4.55-11 and it started. This all started to happen after a dom0 upgrade from a long time without system upgrades.

This is covered by a different issue: #2757

[andrewdavidwong]

Some VMs that started showing this error randomly showed a message saying that an older kernel couldn't be found (4.4.14-11).

I changed in the VM's advanced tab of the qubes manager the kernel from default (4.4.55-11) to 4.4.55-11 and it started. This all started to happen after a dom0 upgrade from a long time without system upgrades.

This is covered by a different issue: #2757

[desci]

Indeed after fixing the kernel behavior, the problem described here still applies.

[desci]

Indeed after fixing the kernel behavior, the problem described here still applies.

[ghost]

I only have the same error when I assign a device (audio, gpu, ethernet) to a VM. If I remove the device the WM starts without errors.

[ghost]

I only have the same error when I assign a device (audio, gpu, ethernet) to a VM. If I remove the device the WM starts without errors.

[torjunkie]

Similar error in Qubes R3.2 when checking logs from Qubes VM Manager

qubes-manager v3.2.12-1.fc23

Checking the log of sys-whonix from Qubes VM Manager (based on the latest Whonix 14 templates available from unstable repos) gives the following error:

[Dom0] Houston, we have a problem...

UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 105166: ordinal not in range(128)

This is most likely a bug in the Qubes Manager

Details:

----
line:self.displayed_text += log.read()
func:__init_log_text__
line no.:63
file:/usr/lib64/python2.7/site-packages/qubesmanager/log_dialog.py
----
line:self.__init_log_text__()
func:__init__
line no.:52
file:/usr/lib64/python2.7/site-packages/qubesmanager/log_dialog.py
----
line:log_dialog = LogDialog(app,log)
func:show_log
line no.:1781
file:/usr/lib64/python2.7/site-packages/qubesmanager/main.py

No non-ascii characters in vm names etc. Just the default naming conventions. Ironically it worked just the day before.

[torjunkie]

Similar error in Qubes R3.2 when checking logs from Qubes VM Manager

qubes-manager v3.2.12-1.fc23

Checking the log of sys-whonix from Qubes VM Manager (based on the latest Whonix 14 templates available from unstable repos) gives the following error:

[Dom0] Houston, we have a problem...

UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 105166: ordinal not in range(128)

This is most likely a bug in the Qubes Manager

Details:

----
line:self.displayed_text += log.read()
func:__init_log_text__
line no.:63
file:/usr/lib64/python2.7/site-packages/qubesmanager/log_dialog.py
----
line:self.__init_log_text__()
func:__init__
line no.:52
file:/usr/lib64/python2.7/site-packages/qubesmanager/log_dialog.py
----
line:log_dialog = LogDialog(app,log)
func:show_log
line no.:1781
file:/usr/lib64/python2.7/site-packages/qubesmanager/main.py

No non-ascii characters in vm names etc. Just the default naming conventions. Ironically it worked just the day before.