Weird Display in Archlinux Template in Qubes 4.1

Does anyone know how to fix this in Qubes 4.1?

Same problem with importing backup from 4.0 to 4.1 - centos7 is backup template from 4.0, f32 is 4.1 template;

Any ideas?

@alzer89 @khal if this issue persists, it may be good to do a formal bug report so a fix can be found and made available to all.

Also, you are probably already aware that these are not official qubes templates but community contributions instead (leaving this here in case anyone else sees this)

These templates are supported by the Qubes community. Some of them are available in ready-to-use binary package form (built by the Qubes developers), while others are available only in source code form. In all cases, the Qubes OS Project does not provide updates for these templates. However, such updates may be provided by the template maintainer.

By installing these templates, you are trusting not only the Qubes developers and the distribution maintainers, but also the template maintainer. In addition, these templates may be somewhat less stable, since the Qubes developers do not test them.

– doc: Community Template VMS

I didn’t think templates from 4.0 should work in 4.1, should they?

For Arch Linux and other templates there are bug reports already and last time I checked they were still valid.

Hi @alzer89 ! there is now a new category for discussions of the upcoming 4.1 release. I’ve moved this topic there.

1 Like

This is a gui-daemon issue. gui-deamon from previous R4.0 templates needs to be upgraded to latest protocol version in order to work. Else, it produces exactly what you get. In order to do that you can go into console directly of the VM. In dom0: sudo virsh console XXX . Then, you are logged as root automatically. For CentOS 7 there is specific steps to do like enabling latest xen virt repository. I have managed to upgrade the template itself but currently, there is issue with CentOS 7 under R4.1 due to too old python3 packages provided by CentOS 7. Honestly, we are thinking to make deprecated CentOS 7 for R4.1 and I’ve currently gave up on maintaining it for R4.1 as CentOS 8 is already giving a lot of work for having Python 3.7+ packages.

Thanks!
I don’t know why, but I thought importing templates from 4.0 to 4.1 wouldn’t work.

So I guess this dependency problem when building archlinux in 4.1 is a “little” work as well? :wink:

Certainly. I’ve not tested yet but I’m not sure if Archlinux is 4.1 ready (packaging side).

I just noticed that in the past 2 days there has been a little progress according to the report #6028 in GitHub.

So, I have managed to fix the display issue for the archlinux template. I built all the gui packages using qubes-builder, and upgraded the 4.0 template.

I am now having issues with qubes-core-qrexec. Not quite sure where everything is supposed to go, or how everything is supposed to fit together. I cannot launch anything from xfce, only while in virsh console (as user or root)

I’ll happily upload what I’ve done, if someone can tell me how (or how to rectify qubes-core-qrexec).

As fepitre said, there are packaging issues with the Arch template (both R4.0 and R4.1):

The qrexec (build) issue on R4.1 is because of some reorganization that didn’t address community templates (understandable since they are community templates and seem to only be supported to some degree officially). I mention this in #6028.

As fepitre said, there are packaging issues with the Arch template (both R4.0 and R4.1):

PRs to fix the issue in 4.0 are in place.

Arch Linux build failure on 4.1 · Issue #6028 · QubesOS/qubes-issues · GitHub

Archlinux again, Qubes 4.0 : component make gui-agent-linux-vm build failed · Issue #6114 · QubesOS/qubes-issues · GitHub

The qrexec (build) issue on R4.1 is because of some reorganization that didn’t address community templates (understandable since they are community templates and seem to only be supported to some degree officially). I mention this in #6028.

Yes, there is no regard taken for Ubuntu or Arch templates. I think that
Whonix templates get a little more love.

I understand that, and I don’t mind getting my hands dirty with a little hacking.

The community templates haven’t got as much attention as debian and fedora, which is quite justified. I’ve been trying for the past three months to get a few community templates (OpenSUSE, MacOS, Archlinux, Ubuntu, BeOS, Windows 10, and a few other) to a point in which they work out-of-the-box in 4.1. I understand how RHEL and Debian-based systems work, but I’m a little fuzzy on the details of Arch.

That’s why I asked openly for help on where to put the respective files.

I have seen in qubes-builder that the qrexec directory has been removed and replaced with core-qrexec. It’s just that the Archlinux PKGBUILD doesn’t know what it is, and I’m trying to fix that.

From https://www.qubes-os.org/news/2020/10/05/new-gentoo-templates-and-maintenance-infrastructure/: “Depending on the needed resources, we could also add the longer Arch Linux jobs into my GitLab CI instance, because we currently don’t properly validate the template itself.” :slight_smile:

Oh, my favorite glitchy thread ! :slight_smile:

for collection!

@fepitre With CentOS-8, under R4.0.3, there are also currently some problems concerning python versions. Trying to update the template aborts due to lack of xcffib. So far, I have found no way to install this module in the template.

Yes I’m aware of this. This is due to old template having packages in transition to python38. All should now be done but we need to rebuild a full template. Solving such issues is possible currently with the help of rpm -e --nodeps and removing qubes-vm-{dependencies,recommended}. Then, it should be possible update with --allowerasing.

1 Like

Thank you for your fast reply!

Even with your corrections, the update fails on qubes-gui-agent, stating broken dependencies (Nothing provides python38-xcffib). I could force the update with --alloerasing --skip-broken --nobest, but the update marker still stays on.

So far, there is no operational problem - just to inform you for your template re-build.

Can you check if you have COPR repository fepitre/epel-8-python38 enabled? If not: dnf copr enable fepitre/epel-8-python38.

1 Like

The repository was not enabled. After enabling, the update went without problems, and the Qube manager now shows the template as updated.

Thanks a lot for your help!