Some advice for qubes-template-archlinux users (+net-vm, +proxy-vm, +help wanted, xorg-error bug while shutdown, high cpu usage)

[schnurentwickler]

Qubes OS version:

R3.2 testing

Affected TemplateVMs:

archlinux (by Olivier Médoc)

Expected behavior:

Fully working template-VM

Actual behavior:

At the time of 2017-07-06 the qubes-template-archlinux templateVM is nearly unusable for online working because of:

1. difficulties to get a usable pacman for uptodate packages (got it fixed, help needed)
2. the template has some missing packages
   …a: because shutdown fill up ".local/share/xorg/Xorg.0.log" to a few hundred MB, takes high cpu, ... (got it fixed, details below)
   …b: as a net-vm it is meanwhile working with handicaps (no DNS - what packages are missing?)
   …c: Still a few necessary packages are missing for qubes 3.2 usage.

Steps to reproduce the behavior:

Install and use the current archlinux template as described in the documentation (https://www.qubes-os.org/doc/templates/archlinux/) or in short via "sudo qubes-dom0-update --enablerepo=qubes-templates-community qubes-template-archlinux" as command in dom0 terminal.

General notes:

First of all I have to thank you for Qubes. Wished to get contact to you way sooner, but that was not possible.
I am writing this in here because most new users are searching and using websites instead mailing-lists. Even if they are accessible through g00gle's webinterface.
Furthermore do I keep in mind to post this issue here because of your note in your docs: "GitHub issues are meant to track more general bugs and enhancements that affect a broad range of Qubes users."

For my usage and future things I need an uptodate\overtheedge linux like archlinux within an always working and secure user interface. That is why archlinux is important to me.

After installation of the template nothing worked as it should, but am I not someone who can contribute? Sure, meanwhile...

Thanks Olivier Médoc for this hard work so far.

For the pacman issue a bash-script placed in /rw/config/ within the template someday and after made executable by the user ready to use would be user-friendly.
Below the following concept a manual method is available.
Maybe this is a topic for the https://groups.google.com/forum/#!forum/qubes-users mailing list.
(((......the script concept.... maybe later.)))

After installation of the qubes-template-archlinux the pacman gpg keys are the most important point.
For the pacman-key behavior the firewall needs to allow full access for at least five or 10 minutes. (until the process is finished)
While full internet access the following commands need to be executed in the archlinux template console:
sudo pacman-key --init && sudo pacman-key --recv-keys 0xC1833B9C && sudo pacman-key --lsign-keys 0xC1833B9C && sudo pacman-key --refresh-keys && sudo pacman-key --populate archlinux

If the key-synchronisation failed, you probably have to change the keyserver:
sudo pacman-key --init && sudo pacman-key --recv-keys 0xC1833B9C --keyserver pgp.mit.edu && sudo pacman-key --lsign-keys 0xC1833B9C --keyserver pgp.mit.edu && sudo pacman-key --refresh-keys --keyserver pgp.mit.edu && sudo pacman-key --populate archlinux

For updates over TOR use the keyserver hkp://jirk5u4osbsr34t5.onion (provided by https://sks-keyservers.net/overview-of-pools.php)

After successful initialization of the newest keys the /etc/pacman.conf needs to be edited.
Insert the following before the # REPOSITORIES line:

### QUBES CONFIG MARKER ###
Include = /etc/pacman.d/*.conf
### QUBES CONFIG END MARKER ###

Now update\upgrade the template (do not forget to confirm):
sudo pacman -Suy

After successful upgrade clean the pacman temp and old database:
pacman -Sc

So far the pacman misbehavior is corrected.

The shutdown-bug which is also filling the space with big logfiles can be fixed with installation of the package xf86-video-dummy.
I was wrong. The unhealthy shutdown behavior caused by the zsh shell, set as standard for the template user. sudo chsh -s /bin/zsh user
Obviosly some qubes(?) scripts are using the standard user shell. For now anyone who is affected should switch to the bash shell: sudo chsh -s /bin/bash user
This seems to be a bug and should not happen.
Somehow the template needs to be rebooted two times to take affect in correlated VMs. (or use the qvm-template-commit command in dom0 console?)

The template is (for me) stable useable as untrusted netVM except it is not responding to any dns query. Do I missing a package beneath dnsmasq and tinyproxy? Maybe some configs are at another spot?
DNS queries where intercepted by the FirewallVM. Problem solved.

Could someone investigate what is missing for dns resolution behind firewallVM?

The screenshot shows the starting and stopping of a netVM and a proxyVM (for testing purposes) templated with arch. Because archlinux is not enabling any service after installation, a systemctl-command needs to be implemented into /rw/config/rc.local of the netVM.

su -c "echo 'systemctl enable NetworkManager' >> /rw/config/rc.local" && sudo chmod 744 /rw/config/rc.local
The benefit is to be able to use the newest network hardware\software. (as soon as it is available in arch with their big community)
Even as usb-vm it is stable running without testing qubes' "dom0 mouse and keyboard proxy".

Related issues:

[0spinboson]

typo: lsign-keys should be lsign-key

Thanks for the remakr about zsh/bash -- arch was nigh-unusable for me because of the insane shutdown times before.

[0spinboson]

typo: lsign-keys should be lsign-key

Thanks for the remakr about zsh/bash -- arch was nigh-unusable for me because of the insane shutdown times before.

[ptitdoc]

Is the bash shell now useable inside the VM ?

zsh has been historically selected instead of bash because archlinux started to use a fork of the bash program. This fork was not initiating properly a user interactive session when using qvm-run (because qvm-run was using something like su - user /bin/bash).

[ptitdoc]

Is the bash shell now useable inside the VM ?

zsh has been historically selected instead of bash because archlinux started to use a fork of the bash program. This fork was not initiating properly a user interactive session when using qvm-run (because qvm-run was using something like su - user /bin/bash).

[0spinboson]

Once you do sudo chsh -s /bin/bash user, arch is perfectly usable, yes.

[0spinboson]

Once you do sudo chsh -s /bin/bash user, arch is perfectly usable, yes.

[ptitdoc]

About bash/zsh problem I refer to this bug:
https://bugs.archlinux.org/task/31831

This bug is apparently not fixed. You can reproduce it by:
1/changing the user to /bin/bash in your template (usermod -s /bin/bash user)
2/ shutdown the template
3/ start a VM based on the template
4/ run set in a console to see that /etc/profile is not loaded (/usr/local/bin is not present in the $PATH ...)

Switching to bash is consequently problematic if you customized your template.

[ptitdoc]

About bash/zsh problem I refer to this bug:
https://bugs.archlinux.org/task/31831

This bug is apparently not fixed. You can reproduce it by:
1/changing the user to /bin/bash in your template (usermod -s /bin/bash user)
2/ shutdown the template
3/ start a VM based on the template
4/ run set in a console to see that /etc/profile is not loaded (/usr/local/bin is not present in the $PATH ...)

Switching to bash is consequently problematic if you customized your template.

[ptitdoc]

The bash/zsh bug is probably fixed in Qubes 4.0 thanks to the following issue/commits:
#2903

[ptitdoc]

The bash/zsh bug is probably fixed in Qubes 4.0 thanks to the following issue/commits:
#2903