Xterm not working for AppVM but works fine for sys-firewall.

[revelation1]

Qubes OS version:

R4.0

Affected component(s):

GUI

---

Steps to reproduce the behavior:

Add Xterm onto sys-firewall and untrusted.
In dom0 terminal run:
qvm-run sys-firewall xterm
xterm window appears.

In dom0 terminal run:
qvm-run untrusted xterm
xterm window does not appear and no errors!

Expected behavior:

Expect xterm window to appear for AppVM.

Actual behavior:

Xterm works for sys-net and sys-firewall but not for AppVM.
This is actually the case for all applications on AppVM but I am using Xterm as the simplest test.

General notes:

---

Related issues:

[marmarek]

What is exit code (echo $?)?

[marmarek]

What is exit code (echo $?)?

[revelation1]

I can't get exit code that way since no prompt but if I run...

qvm-run --verbose --autostart --service sys-firewall qubes.StartApp+xterm
echo $? == 0
qvm-run --verbose --autostart --service untrusted qubes.StartApp+xterm
I expect a prompt like the previous command but no prompt. Appears hung.

[revelation1]

I can't get exit code that way since no prompt but if I run...

qvm-run --verbose --autostart --service sys-firewall qubes.StartApp+xterm
echo $? == 0
qvm-run --verbose --autostart --service untrusted qubes.StartApp+xterm
I expect a prompt like the previous command but no prompt. Appears hung.

[marmarek]

Oh. Is the VM running? Check if qvm-start-gui process is running in dom0.

[marmarek]

Oh. Is the VM running? Check if qvm-start-gui process is running in dom0.

[revelation1]

Yes VM is running. qvm-start-gui is also running. Thanks for your help btw.

`/usr/vin/python3 /usr/vin/qvm-start-gui --all --watch

[revelation1]

Yes VM is running. qvm-start-gui is also running. Thanks for your help btw.

`/usr/vin/python3 /usr/vin/qvm-start-gui --all --watch

[marmarek]

Ok, lets dig deeper. Check list of processes - on what qvm-run is waiting. Especially is it qrexec-client with qubes.StartApp or qubes.WaitForSession? Next step - access VM console with sudo xl console untrusted, login as root and see if X server is running. If not - check qubes-gui-agent service status and X server log (~user/.local/share/xorg/Xorg.0.log)

[marmarek]

Ok, lets dig deeper. Check list of processes - on what qvm-run is waiting. Especially is it qrexec-client with qubes.StartApp or qubes.WaitForSession? Next step - access VM console with sudo xl console untrusted, login as root and see if X server is running. If not - check qubes-gui-agent service status and X server log (~user/.local/share/xorg/Xorg.0.log)

[revelation1]

Some more info... I started up both fedora-26 and debian-9 templates. They are working fine, xterm opens. I created an AppVM using debian-9 template and it is also working fine. So, this seems to only affect fedora VMs.

qvm-run appears to be waiting on WaitForSession.

I ran (ps -e | grep -i x) on the offending AppVM and do not see Xorg running.

Can you help me with the last part...where do i check qubes-gui-agent status and where do i find that log file (dom0? I can't find /home/user when in vm console)?

[revelation1]

Some more info... I started up both fedora-26 and debian-9 templates. They are working fine, xterm opens. I created an AppVM using debian-9 template and it is also working fine. So, this seems to only affect fedora VMs.

qvm-run appears to be waiting on WaitForSession.

I ran (ps -e | grep -i x) on the offending AppVM and do not see Xorg running.

Can you help me with the last part...where do i check qubes-gui-agent status and where do i find that log file (dom0? I can't find /home/user when in vm console)?

[marmarek]

I can't find /home/user when in vm console

Oh, this might be the problem. Is /rw mounted? Also, see systemctl status qubes-mount-dirs.

[marmarek]

I can't find /home/user when in vm console

Oh, this might be the problem. Is /rw mounted? Also, see systemctl status qubes-mount-dirs.

[revelation1]

mount: /rw: wrong fs type, bad option
quebes-mount-dirs.service: Main process exited
Failed to start Initialize and mount /rw and...

OK, seems we are getting closer haha.

[revelation1]

mount: /rw: wrong fs type, bad option
quebes-mount-dirs.service: Main process exited
Failed to start Initialize and mount /rw and...

OK, seems we are getting closer haha.

[marmarek]

See dmesg in that VM. What kernel version you use there?

[marmarek]

See dmesg in that VM. What kernel version you use there?

[revelation1]

4.14.18-1

When I do a (parted /dev/xvdb), print, it doesn't look like there is a filesystem. I see partition table: unknown and its missing ext4.

[revelation1]

4.14.18-1

When I do a (parted /dev/xvdb), print, it doesn't look like there is a filesystem. I see partition table: unknown and its missing ext4.

[marmarek]

It should have ext4 directly (no partition table).

[marmarek]

It should have ext4 directly (no partition table).

[revelation1]

For some reason all fedora VM aren't creating ext4 correctly. Or it is getting corrupted.

Is there a way I can manually rebuild /dev/xvdb?

[revelation1]

For some reason all fedora VM aren't creating ext4 correctly. Or it is getting corrupted.

Is there a way I can manually rebuild /dev/xvdb?

[marmarek]

Just mkfs.ext4 /dev/xvdb and reboot the VM.
You can also create fresh VM and see if that happens again. If so - collect journalctl --no-pager -b output using xl console. To transfer it out of dom0, you can save the output to a file (copy&paste), then copy it to some VM with qvm-copy-to-vm.

[marmarek]

Just mkfs.ext4 /dev/xvdb and reboot the VM.
You can also create fresh VM and see if that happens again. If so - collect journalctl --no-pager -b output using xl console. To transfer it out of dom0, you can save the output to a file (copy&paste), then copy it to some VM with qvm-copy-to-vm.

[revelation1]

mkfs.ext4 fixes the issue. I will try to upload the log file tomorrow but the basic error on new vm creation is:

private device management: fsck.ext4 /dev/xvdb failed:
fsck.ext4: Bad magic number in super-block while trying to open /dev/xvdb

Its great to have a workaround for this. Thanks for your help!

[revelation1]

mkfs.ext4 fixes the issue. I will try to upload the log file tomorrow but the basic error on new vm creation is:

private device management: fsck.ext4 /dev/xvdb failed:
fsck.ext4: Bad magic number in super-block while trying to open /dev/xvdb

Its great to have a workaround for this. Thanks for your help!

[marmarek]

Just to be sure - the above happens only in new VM based on fedora-26, but not in new VM based on debian-9, yes?

[marmarek]

Just to be sure - the above happens only in new VM based on fedora-26, but not in new VM based on debian-9, yes?

[revelation1]

Yes, I think it happens with every new fedora-26 (latest updates) VM. I only created one debian-9 VM and it was good. It could be a race condition and I could have just gotten lucky with debian but it seems unlikely. I will do some more testing when I have time (ie, create 30 fedora-26 vm's and see if any of them have xserver on boot).

[revelation1]

Yes, I think it happens with every new fedora-26 (latest updates) VM. I only created one debian-9 VM and it was good. It could be a race condition and I could have just gotten lucky with debian but it seems unlikely. I will do some more testing when I have time (ie, create 30 fedora-26 vm's and see if any of them have xserver on boot).