Archlinux template for QubesOS 4.0

[na--]

Qubes OS version:

R4.0

Affected TemplateVMs:

archlinux
(template used for building: fedora-25)

---

Steps to reproduce the behavior:

Try to build the archlinux template:

1. Install and set up the needed prerequisites for building QubesOS
2. Clone qubes-builder
3. Copy example-configs/qubes-os-master.conf as builder.conf
4. Set DISTS_VM to archlinux and add builder-archlinux to COMPONENTS and BUILDER_PLUGINS
5. Run make get-sources, make qubes-vm, make template

Expected behavior:

Build the archlinux packages for the qubes components and the dom0 archlinux template package.

Actual behavior:

Some packages fail: core-agent-linux, linux-utils, vmm-xen

General notes:

This is just an issue to track all the changes across the different repos that fix the archlinux template for QubesOS 4.0. In a few minutes I will submit pull requests to core-agent-linux, linux-utils and vmm-xen that fix the build and produce a somewhat working archlinux template. I tested the resulting template a bit in a fresh fully-updated (including the current-testing repo) 4.0 RC1 install and it worked. There were some peculiarities with VM startup and shutdown which I'll probably need help to track down.

---

Related issues:

None that I could find

[0spinboson]

building this using your instructions worked for me as well (fc26, incidentally), and it even boots, so I'm good for now. :)

[0spinboson]

building this using your instructions worked for me as well (fc26, incidentally), and it even boots, so I'm good for now. :)

[mannp]

Is this something thats in any early beta repos, or is it only build yourself for the moment?

[mannp]

Is this something thats in any early beta repos, or is it only build yourself for the moment?

[0spinboson]

For now, home brewing only, I'm afraid. :)

…

On Oct 19, 2017 16:00, "mannp" ***@***.***> wrote: Is this something thats in any early beta repos, or is it only build yourself for the moment? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3185 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AUGeHGqESV3rMDA-Zce-Sna7qqXeedfZks5st1X3gaJpZM4P90RU> .

[0spinboson]

For now, home brewing only, I'm afraid. :)

…

On Oct 19, 2017 16:00, "mannp" ***@***.***> wrote: Is this something thats in any early beta repos, or is it only build yourself for the moment? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3185 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AUGeHGqESV3rMDA-Zce-Sna7qqXeedfZks5st1X3gaJpZM4P90RU> .

[mannp]

Ok thanks for the quick reply @0spinboson, I will have to add to my to do list for now :)

If only there was a docker with the build environment already in, will have to do some googling and see if such a thing exists.

Cheers

[mannp]

Ok thanks for the quick reply @0spinboson, I will have to add to my to do list for now :)

If only there was a docker with the build environment already in, will have to do some googling and see if such a thing exists.

Cheers

[na--]

When I launch an Archlinux AppVM, something strange happens. First, an initialization/BIOS screen appears for a few seconds:

then it disappears but a larger blank screen appears:

then it disappears as well and the window of the launched application is shown. I am not sure what the reason is, maybe a missed patch with vmm-xen. Anyone else having the same issue or have any idea why this happens?

Also, I noticed a few other minor issues:

• /dev/shm is smaller than expected and some applications crash
• qubes-usb-proxy is not installed by default in the template
• dom0 did not know any of the template applications on the first install, but updating the template populates the available applications list.

I think the first 2 are easy to track down and will fix them when I have the time. Does anyone else notice any other issues?

[na--]

When I launch an Archlinux AppVM, something strange happens. First, an initialization/BIOS screen appears for a few seconds:

then it disappears but a larger blank screen appears:

then it disappears as well and the window of the launched application is shown. I am not sure what the reason is, maybe a missed patch with vmm-xen. Anyone else having the same issue or have any idea why this happens?

Also, I noticed a few other minor issues:

• /dev/shm is smaller than expected and some applications crash
• qubes-usb-proxy is not installed by default in the template
• dom0 did not know any of the template applications on the first install, but updating the template populates the available applications list.

I think the first 2 are easy to track down and will fix them when I have the time. Does anyone else notice any other issues?

[marmarek]

dom0 did not know any of the template applications on the first install, but updating the template populates the available applications list.

This looks related to the "window issue". It means qubes.PostInstall service wasn't called at template installation. It should be done automatically as part of rpm installation.
You can do it manually and see what happens:

qvm-run -u root -p --service archlinux qubes.PostInstall

[marmarek]

dom0 did not know any of the template applications on the first install, but updating the template populates the available applications list.

This looks related to the "window issue". It means qubes.PostInstall service wasn't called at template installation. It should be done automatically as part of rpm installation.
You can do it manually and see what happens:

qvm-run -u root -p --service archlinux qubes.PostInstall

[ptitdoc]

Additionnal note: core-qubes-db supports python 2.7 and python 3 bindings, but archlinux PKGBUILD only builds the 2.7 bindings.

The following pull request build core-qubesdb python bindings for both versions:
QubesOS/qubes-core-qubesdb#6

[ptitdoc]

Additionnal note: core-qubes-db supports python 2.7 and python 3 bindings, but archlinux PKGBUILD only builds the 2.7 bindings.

The following pull request build core-qubesdb python bindings for both versions:
QubesOS/qubes-core-qubesdb#6

[ptitdoc]

Additionnal note: imgconverter in linux-utils should also be built both for python2 and python3. A created a Push Request which is concurrent to yours:
QubesOS/qubes-linux-utils#22

[ptitdoc]

Additionnal note: imgconverter in linux-utils should also be built both for python2 and python3. A created a Push Request which is concurrent to yours:
QubesOS/qubes-linux-utils#22

[ptitdoc]

Additionnal note: core-agent-linux changed the logic of calling qrexec from using su, to using a pam enabled qrexec agent.
I took your commits and added the required changes in my own pull request:
QubesOS/qubes-core-agent-linux#63

However, I'm not 100% sure that all su problems are fixed for archlinux (I only tested building but I'm not able to test the package on r4.0 yet).

More references to these su/bash/zsh problems are tracked in the following thread:
#2888

[ptitdoc]

Additionnal note: core-agent-linux changed the logic of calling qrexec from using su, to using a pam enabled qrexec agent.
I took your commits and added the required changes in my own pull request:
QubesOS/qubes-core-agent-linux#63

However, I'm not 100% sure that all su problems are fixed for archlinux (I only tested building but I'm not able to test the package on r4.0 yet).

More references to these su/bash/zsh problems are tracked in the following thread:
#2888

[ptitdoc]

Additionnal note: gui-agent-linux now use a separate pulseaudio and agent packages. Archlinux PKGBUILD has been updated acordingly:
QubesOS/qubes-gui-agent-linux#20

As a side note, I plan to separate the xorg module in order to deal more easily with new xorg versions.

[ptitdoc]

Additionnal note: gui-agent-linux now use a separate pulseaudio and agent packages. Archlinux PKGBUILD has been updated acordingly:
QubesOS/qubes-gui-agent-linux#20

As a side note, I plan to separate the xorg module in order to deal more easily with new xorg versions.

[ptitdoc]

I uploaded the binary packages for Qubes 4.0 in testing.

You can try them by changing current to testing in the repository URL.

[ptitdoc]

I uploaded the binary packages for Qubes 4.0 in testing.

You can try them by changing current to testing in the repository URL.

[ptitdoc]

I confirm the template with all the linked Pull Requests is properly starting and has basic support for:

• gui
• network
• sound

Other features have not been tested yet.

I also experience the qubes.PostInstall error when installing the template, but I have not been able to find related logs. This does not prevent the template or AppVMs to start properly.

[ptitdoc]

I confirm the template with all the linked Pull Requests is properly starting and has basic support for:

• gui
• network
• sound

Other features have not been tested yet.

I also experience the qubes.PostInstall error when installing the template, but I have not been able to find related logs. This does not prevent the template or AppVMs to start properly.

[na--]

Thanks! I will try to test everything tomorrow. If everything works and RC2 is officially released, I may event attempt to switch to 4.0 full-time for easier testing and development.

[na--]

Thanks! I will try to test everything tomorrow. If everything works and RC2 is officially released, I may event attempt to switch to 4.0 full-time for easier testing and development.

[ptitdoc]

The qubes.PostInstall bug is caused by broken sed commands in the PKGBUILD. I fixed it in the same pull request:
QubesOS/qubes-core-agent-linux#63

[ptitdoc]

The qubes.PostInstall bug is caused by broken sed commands in the PKGBUILD. I fixed it in the same pull request:
QubesOS/qubes-core-agent-linux#63

[ptitdoc]

I also noticed that there are still problems with bash not loading /etc/profile.

[ptitdoc]

I also noticed that there are still problems with bash not loading /etc/profile.

[na--]

Not sure about /etc/profile, but regarding the small size of /dev/shm: I think this is the commit that fixed the original issue, but it looks like /etc/fstab is removed in the archlinux package.

[na--]

Not sure about /etc/profile, but regarding the small size of /dev/shm: I think this is the commit that fixed the original issue, but it looks like /etc/fstab is removed in the archlinux package.

[marmarek]

tmp.mount dropin should also work, if installed there

[marmarek]

tmp.mount dropin should also work, if installed there

[na--]

@ptitdoc: do you think that the fstab file in core-agent-linux is suitable for archlinux? At first I thought that we could just add a line for a larger /dev/shm here, but I think that we are also missing the discard option for /rw in the arch template... So probably using the fstab file as-is or modifying it in place is better.

[na--]

@ptitdoc: do you think that the fstab file in core-agent-linux is suitable for archlinux? At first I thought that we could just add a line for a larger /dev/shm here, but I think that we are also missing the discard option for /rw in the arch template... So probably using the fstab file as-is or modifying it in place is better.

[ptitdoc]

/tmp and /dev/shm are following archlinux default value. I would not change it on behalf of the user.

But maybe the size is based on available RAM which is small when QubesVMs are starting.

If we need to change it, I would add it in template customization in archlinux-builder, maybe through a systemd .mount dropin as @marmarek suggests.

[ptitdoc]

/tmp and /dev/shm are following archlinux default value. I would not change it on behalf of the user.

But maybe the size is based on available RAM which is small when QubesVMs are starting.

If we need to change it, I would add it in template customization in archlinux-builder, maybe through a systemd .mount dropin as @marmarek suggests.

[na--]

Yeah, I think the small size is because it's based on the initially available RAM. I'm a big fan of the arch way, but this makes the system unusable (browser video in fullscreen is almost guaranteed to crash), so I think we have to increase it by default. I'm not sure how to do this via a systemd dropin, there does not seem to be a unit for /dev/shm, only for /tmp, we probably need a separate unit file.

[na--]

Yeah, I think the small size is because it's based on the initially available RAM. I'm a big fan of the arch way, but this makes the system unusable (browser video in fullscreen is almost guaranteed to crash), so I think we have to increase it by default. I'm not sure how to do this via a systemd dropin, there does not seem to be a unit for /dev/shm, only for /tmp, we probably need a separate unit file.

[marmarek]

Yeah, I think the small size is because it's based on the initially available RAM

Exactly, see this commit and issue linked from there.
As for dropin - see that commit - it already contain appropriate file. Just needs to be installed in Archlinux.

[marmarek]

Yeah, I think the small size is because it's based on the initially available RAM

Exactly, see this commit and issue linked from there.
As for dropin - see that commit - it already contain appropriate file. Just needs to be installed in Archlinux.

[ptitdoc]

I did additionnal testing.

There is still a bug because X11 session is not registered properly by loginctl. As a consequence, running systemctl --user will fail.
A temporary workaround is to copy /etc/pam.d/qrexec to /etc/pam.d/su and /etc/pam.d/su-l.

@marmarek Following issue #2903, you changed qrexec to use pam instead of calling su. Is it possible to do the same to call xinit instead of calling it via su ?

[ptitdoc]

I did additionnal testing.

There is still a bug because X11 session is not registered properly by loginctl. As a consequence, running systemctl --user will fail.
A temporary workaround is to copy /etc/pam.d/qrexec to /etc/pam.d/su and /etc/pam.d/su-l.

@marmarek Following issue #2903, you changed qrexec to use pam instead of calling su. Is it possible to do the same to call xinit instead of calling it via su ?

[marmarek]

Well, it should be possible (in fact, it should be implementing proper "display manager" in terms of session handling), but not sure how much work is it.

[marmarek]

Well, it should be possible (in fact, it should be implementing proper "display manager" in terms of session handling), but not sure how much work is it.

[na--]

I'm currently testing a freshly built archlinux 4.0 template after a new QubesOS 4.0 RC2 install. So far so good - the PostInstall problems are indeed fixed. I've only noticed one issue that hasn't been mentioned so far - for each archlinux-based AppVM started there is a networkmanager applet shown in the system tray.

@marmarek: I saw the dropin file in the commit, but that file is for enlarging the /tmp drive. It's also already present in the archlinux template, no issues there. The issue is with /dev/shm, which is a separate drive and right now is 145 MB in my case. In the commit you linked, that problem is solved not with a systemd unit or dropin file, but with direct manipulation of the /etc/fstab file. The issue is that fstab is packaged in the fedora package, but not in the archlinux one. There is no systemd unit or dropin file for /dev/shm in either.

Here are the modifications to the builder.conf file if anyone else wants to build:

DISTS_VM = archlinux
COMPONENTS += builder-archlinux
BUILDER_PLUGINS += builder-archlinux

BRANCH_core_agent_linux = archlinux-r4-template
GIT_URL_core_agent_linux = https://github.com/ptitdoc/qubes-core-agent-linux

BRANCH_builder_archlinux = master
GIT_URL_builder_archlinux = https://github.com/ptitdoc/qubes-builder-archlinux

BRANCH_vmm_xen = r4-archlinux-template
GIT_URL_vmm_xen = https://github.com/na--/qubes-vmm-xen

BRANCH_core_qubesdb = archpython3bindings
GIT_URL_core_qubesdb = https://github.com/ptitdoc/qubes-core-qubesdb

BRANCH_linux_utils = archpython2+3
GIT_URL_linux_utils = https://github.com/ptitdoc/qubes-linux-utils-1

BRANCH_gui_agent_linux = archlinux-r4-template
GIT_URL_gui_agent_linux = https://github.com/ptitdoc/qubes-gui-agent-linux-1

A bit of a mess, but hopefully most of the changes will be merged soon. All of the pull requests have signed git tags, but you have to trust mine and ptitdoc's GPG keys to successfully execute make get-sources

[na--]

I'm currently testing a freshly built archlinux 4.0 template after a new QubesOS 4.0 RC2 install. So far so good - the PostInstall problems are indeed fixed. I've only noticed one issue that hasn't been mentioned so far - for each archlinux-based AppVM started there is a networkmanager applet shown in the system tray.

@marmarek: I saw the dropin file in the commit, but that file is for enlarging the /tmp drive. It's also already present in the archlinux template, no issues there. The issue is with /dev/shm, which is a separate drive and right now is 145 MB in my case. In the commit you linked, that problem is solved not with a systemd unit or dropin file, but with direct manipulation of the /etc/fstab file. The issue is that fstab is packaged in the fedora package, but not in the archlinux one. There is no systemd unit or dropin file for /dev/shm in either.

Here are the modifications to the builder.conf file if anyone else wants to build:

DISTS_VM = archlinux
COMPONENTS += builder-archlinux
BUILDER_PLUGINS += builder-archlinux

BRANCH_core_agent_linux = archlinux-r4-template
GIT_URL_core_agent_linux = https://github.com/ptitdoc/qubes-core-agent-linux

BRANCH_builder_archlinux = master
GIT_URL_builder_archlinux = https://github.com/ptitdoc/qubes-builder-archlinux

BRANCH_vmm_xen = r4-archlinux-template
GIT_URL_vmm_xen = https://github.com/na--/qubes-vmm-xen

BRANCH_core_qubesdb = archpython3bindings
GIT_URL_core_qubesdb = https://github.com/ptitdoc/qubes-core-qubesdb

BRANCH_linux_utils = archpython2+3
GIT_URL_linux_utils = https://github.com/ptitdoc/qubes-linux-utils-1

BRANCH_gui_agent_linux = archlinux-r4-template
GIT_URL_gui_agent_linux = https://github.com/ptitdoc/qubes-gui-agent-linux-1

A bit of a mess, but hopefully most of the changes will be merged soon. All of the pull requests have signed git tags, but you have to trust mine and ptitdoc's GPG keys to successfully execute make get-sources

[ptitdoc]

@na-- : I also experienced the applet issue. I also noticed old scripts that probably need to be cleaned-up:
In /etc/xdg/autostart/00-qubes-show-hide-nm-applet.desktop, /usr/lib/qubes/show-hide-nm-applet.sh is called. which in turn calls qsvc network-manager which does not exists on the system. Is it normal ?

@marmarek: In fact the following lines in qubes-gui (vmside.c) are from where xinit is called:

do_execute(NULL, "/usr/bin/qubes-run-xorg.sh");

in do_execute:
            if (user)
                execl("/bin/su", "su", "-", user, "-c", cmd, NULL);
            else
                execl("/bin/bash", "bash", "-c", cmd, NULL);

in qubes-run-xorg.sh:
exec su -l user -c "/usr/bin/xinit $XSESSION -- $XORG :0 -nolisten tcp vt07 -wr -config xorg-qubes.conf > ~/.xsession-errors 2>&1"

xinit is not called from dom0 like qrexec so I guess qrexec can not be used as it is.

Instead I have the following option:

• starting qubes-gui directly as user user in order to avoid calling su-l. This can be easily tested by modifying the .service file but I guess several things in gui-agent need to be run as root.
• using pam directly as in the commit marmarek/old-qubes-core-agent-linux@3af55c5, but reading the details, it does not worth the effort...
• continuing calling su-l and reverting changes to pam.d/su and pam.d/su-l in archlinux so that the user login session is properly registered.

[ptitdoc]

@na-- : I also experienced the applet issue. I also noticed old scripts that probably need to be cleaned-up:
In /etc/xdg/autostart/00-qubes-show-hide-nm-applet.desktop, /usr/lib/qubes/show-hide-nm-applet.sh is called. which in turn calls qsvc network-manager which does not exists on the system. Is it normal ?

@marmarek: In fact the following lines in qubes-gui (vmside.c) are from where xinit is called:

do_execute(NULL, "/usr/bin/qubes-run-xorg.sh");

in do_execute:
            if (user)
                execl("/bin/su", "su", "-", user, "-c", cmd, NULL);
            else
                execl("/bin/bash", "bash", "-c", cmd, NULL);

in qubes-run-xorg.sh:
exec su -l user -c "/usr/bin/xinit $XSESSION -- $XORG :0 -nolisten tcp vt07 -wr -config xorg-qubes.conf > ~/.xsession-errors 2>&1"

xinit is not called from dom0 like qrexec so I guess qrexec can not be used as it is.

Instead I have the following option:

• starting qubes-gui directly as user user in order to avoid calling su-l. This can be easily tested by modifying the .service file but I guess several things in gui-agent need to be run as root.
• using pam directly as in the commit marmarek/old-qubes-core-agent-linux@3af55c5, but reading the details, it does not worth the effort...
• continuing calling su-l and reverting changes to pam.d/su and pam.d/su-l in archlinux so that the user login session is properly registered.

[marmarek]

In the commit you linked, that problem is solved not with a systemd unit or dropin file, but with direct manipulation of the /etc/fstab

Ah, indeed.

In /etc/xdg/autostart/00-qubes-show-hide-nm-applet.desktop, /usr/lib/qubes/show-hide-nm-applet.sh is called. which in turn calls qsvc network-manager which does not exists on the system. Is it normal ?

qsvc is a function defined in /usr/lib/qubes/init/functions

starting qubes-gui directly as user user in order to avoid calling su-l. This can be easily tested by modifying the .service file but I guess several things in gui-agent need to be run as root.

Not that much, but some. Anyway, I'd avoid this solution, because we may need root there in the future (for example to access full info in /proc/self/pagemap, instead of using u2mfn kernel module - see #1654 (which is viable option on HVM, in contrast to PV)

using pam directly as in the commit marmarek/old-qubes-core-agent-linux@3af55c5, but reading the details, it does not worth the effort...

That was the thing I was thinking about writing about proper display manager handling. For starting graphical session that function would look slightly different. For example define XDG_SEAT etc.

continuing calling su-l and reverting changes to pam.d/su and pam.d/su-l in archlinux so that the user login session is properly registered.

IMO this is the easiest option.

[marmarek]

In the commit you linked, that problem is solved not with a systemd unit or dropin file, but with direct manipulation of the /etc/fstab

Ah, indeed.

In /etc/xdg/autostart/00-qubes-show-hide-nm-applet.desktop, /usr/lib/qubes/show-hide-nm-applet.sh is called. which in turn calls qsvc network-manager which does not exists on the system. Is it normal ?

qsvc is a function defined in /usr/lib/qubes/init/functions

starting qubes-gui directly as user user in order to avoid calling su-l. This can be easily tested by modifying the .service file but I guess several things in gui-agent need to be run as root.

Not that much, but some. Anyway, I'd avoid this solution, because we may need root there in the future (for example to access full info in /proc/self/pagemap, instead of using u2mfn kernel module - see #1654 (which is viable option on HVM, in contrast to PV)

using pam directly as in the commit marmarek/old-qubes-core-agent-linux@3af55c5, but reading the details, it does not worth the effort...

That was the thing I was thinking about writing about proper display manager handling. For starting graphical session that function would look slightly different. For example define XDG_SEAT etc.

continuing calling su-l and reverting changes to pam.d/su and pam.d/su-l in archlinux so that the user login session is properly registered.

IMO this is the easiest option.

[ptitdoc]

In archlinux we create fstab during template creation : https://github.com/QubesOS/qubes-builder-archlinux/blob/ea4eda3afeaffe793b5bbff83064ec6f346ea7a3/scripts/04_install_qubes.sh#L57

I'm not completely confident of changing fstab on behalf of the user from core-agent-vm. This would break user customization.
I will check if it is possible to setup mount point customization from systemd mount files. After all, most mount points are now handled by systemd and not in fstab anymore (eg: /proc /sys /tmp in archlinux)

[ptitdoc]

In archlinux we create fstab during template creation : https://github.com/QubesOS/qubes-builder-archlinux/blob/ea4eda3afeaffe793b5bbff83064ec6f346ea7a3/scripts/04_install_qubes.sh#L57

I'm not completely confident of changing fstab on behalf of the user from core-agent-vm. This would break user customization.
I will check if it is possible to setup mount point customization from systemd mount files. After all, most mount points are now handled by systemd and not in fstab anymore (eg: /proc /sys /tmp in archlinux)

[ptitdoc]

Sorry I removed by previous comment as I was wrong.

The systemd API file systems are discussed here and include /dev/shm:
https://www.freedesktop.org/wiki/Software/systemd/APIFileSystems/

Systemd will refuse running a mount unit based on one of these filesystem:
https://github.com/systemd/systemd/blob/5cfde7ad2949387f636d05765a0a1c5820aa21cd/src/core/mount.c#L538

There are several exception however such as /tmp which is documented as an API filesystem, but the documentation is apparently wrong as it is not present in the systemd mount table :
https://github.com/systemd/systemd/blob/4aa1d31c89c8fb74e70eed5849c780c4678829a3/src/core/mount-setup.c#L73

Consequently, your can change the existing systemd mount file for /tmp using a drop-in, but there is no mount file for /dev/shm, and consequently no possibility to create a dropin. It can only be changed in fstab, which systemd-fs-remount server will load to read /dev/shm mount options.

[ptitdoc]

Sorry I removed by previous comment as I was wrong.

The systemd API file systems are discussed here and include /dev/shm:
https://www.freedesktop.org/wiki/Software/systemd/APIFileSystems/

Systemd will refuse running a mount unit based on one of these filesystem:
https://github.com/systemd/systemd/blob/5cfde7ad2949387f636d05765a0a1c5820aa21cd/src/core/mount.c#L538

There are several exception however such as /tmp which is documented as an API filesystem, but the documentation is apparently wrong as it is not present in the systemd mount table :
https://github.com/systemd/systemd/blob/4aa1d31c89c8fb74e70eed5849c780c4678829a3/src/core/mount-setup.c#L73

Consequently, your can change the existing systemd mount file for /tmp using a drop-in, but there is no mount file for /dev/shm, and consequently no possibility to create a dropin. It can only be changed in fstab, which systemd-fs-remount server will load to read /dev/shm mount options.

[na--]

@ptitdoc: thanks! I just rebuilt a fresh archlinux template on a new install of RC2 (my previous install was FUBAR due to a series of unfortunate events...) - so far everything looks perfect! /dev/shm is properly sized and the networkmanager applets have disappeared.

[na--]

@ptitdoc: thanks! I just rebuilt a fresh archlinux template on a new install of RC2 (my previous install was FUBAR due to a series of unfortunate events...) - so far everything looks perfect! /dev/shm is properly sized and the networkmanager applets have disappeared.

[mannp]

@na-- Thanks for the modifications to the builder.conf above.

Its my first template build, so hopefully not really silly questions that I am about to ask :/

I have added your changes to the bottom of the builder.conf file and ran a build.

The build failed with the xen-shared-loop-losetup.patch which was not found and I wondered if I had added the modifications to the builder.conf correctly.

Is it possible for someone to post the full config please, so I can make sure I am no doing things incorrectly.

I have also followed the archlinux template building howto on the qubes wiki and still get the build error.

Thanks in advance

==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
-> Found xen-4.8.2.tar.gz
-> Found series-vm.conf
-> Found apply-patches
==> WARNING: Skipping all source file integrity checks.
==> Extracting sources...
-> Extracting xen-4.8.2.tar.gz with bsdtar
bsdtar: Failed to set default locale
==> Starting build()...

• patch -s -F0 -E -p1 --no-backup-if-mismatch -i ./patches.qubes/xen-shared-loop-losetup.patch
  patch: **** Can't open patch file ./patches.qubes/xen-shared-loop-losetup.patch : No such file or directory
  ++ echo '*** patch ./patches.qubes/xen-shared-loop-losetup.patch failed **'
  *** patch ./patches.qubes/xen-shared-loop-losetup.patch failed ***
  ==> ERROR: A failure occurred in build().
  Aborting...
  /home/user/qubes-builder/qubes-src/builder-archlinux/Makefile.archlinux:120: recipe for target 'dist-package' failed
  make[2]: *** [dist-package] Error 2
  Makefile.generic:156: recipe for target 'packages' failed
  make[1]: *** [packages] Error 1
  Makefile:212: recipe for target 'vmm-xen-vm' failed
  make: *** [vmm-xen-vm] Error 1
  bash-4.3$ make template
  mkdir -p /home/user/qubes-builder/qubes-src/linux-template-builder/pkgs-for-template/archlinux/pkgs
  for arch_build_dir in archlinux; do
  pkgnames=cat qubes-src/vmm-xen/$arch_build_dir/PKGBUILD | grep pkgname | cut -d "=" -f 2 | tr -d '()"';
  for pkgname in $pkgnames; do
  ln -f qubes-src/vmm-xen/pkgs/$pkgname-.pkg.tar.xz /home/user/qubes-builder/qubes-src/linux-template-builder/pkgs-for-template/archlinux/pkgs/;
  done;
  done;\

ln: failed to access 'qubes-src/vmm-xen/pkgs/qubes-vm-xen-*.pkg.tar.xz': No such file or directory
/home/user/qubes-builder/qubes-src/builder-archlinux/Makefile.archlinux:156: recipe for target 'update-repo' failed
make[1]: *** [update-repo] Error 1
Makefile:297: recipe for target 'template-local-archlinux' failed
make: *** [template-local-archlinux] Error 1

[mannp]

@na-- Thanks for the modifications to the builder.conf above.

Its my first template build, so hopefully not really silly questions that I am about to ask :/

I have added your changes to the bottom of the builder.conf file and ran a build.

The build failed with the xen-shared-loop-losetup.patch which was not found and I wondered if I had added the modifications to the builder.conf correctly.

Is it possible for someone to post the full config please, so I can make sure I am no doing things incorrectly.

I have also followed the archlinux template building howto on the qubes wiki and still get the build error.

Thanks in advance

==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
-> Found xen-4.8.2.tar.gz
-> Found series-vm.conf
-> Found apply-patches
==> WARNING: Skipping all source file integrity checks.
==> Extracting sources...
-> Extracting xen-4.8.2.tar.gz with bsdtar
bsdtar: Failed to set default locale
==> Starting build()...

• patch -s -F0 -E -p1 --no-backup-if-mismatch -i ./patches.qubes/xen-shared-loop-losetup.patch
  patch: **** Can't open patch file ./patches.qubes/xen-shared-loop-losetup.patch : No such file or directory
  ++ echo '*** patch ./patches.qubes/xen-shared-loop-losetup.patch failed **'
  *** patch ./patches.qubes/xen-shared-loop-losetup.patch failed ***
  ==> ERROR: A failure occurred in build().
  Aborting...
  /home/user/qubes-builder/qubes-src/builder-archlinux/Makefile.archlinux:120: recipe for target 'dist-package' failed
  make[2]: *** [dist-package] Error 2
  Makefile.generic:156: recipe for target 'packages' failed
  make[1]: *** [packages] Error 1
  Makefile:212: recipe for target 'vmm-xen-vm' failed
  make: *** [vmm-xen-vm] Error 1
  bash-4.3$ make template
  mkdir -p /home/user/qubes-builder/qubes-src/linux-template-builder/pkgs-for-template/archlinux/pkgs
  for arch_build_dir in archlinux; do
  pkgnames=cat qubes-src/vmm-xen/$arch_build_dir/PKGBUILD | grep pkgname | cut -d "=" -f 2 | tr -d '()"';
  for pkgname in $pkgnames; do
  ln -f qubes-src/vmm-xen/pkgs/$pkgname-.pkg.tar.xz /home/user/qubes-builder/qubes-src/linux-template-builder/pkgs-for-template/archlinux/pkgs/;
  done;
  done;\

ln: failed to access 'qubes-src/vmm-xen/pkgs/qubes-vm-xen-*.pkg.tar.xz': No such file or directory
/home/user/qubes-builder/qubes-src/builder-archlinux/Makefile.archlinux:156: recipe for target 'update-repo' failed
make[1]: *** [update-repo] Error 1
Makefile:297: recipe for target 'template-local-archlinux' failed
make: *** [template-local-archlinux] Error 1

[na--]

It looks like you haven't picked up my modifications to vmm-xen.

Here is the builder.conf file I successfully used yesterday to build the full template. All of the changes from example-configs/qubes-os-master.conf are in the bottom of the file, after the three rows of #######.

Build this in a separate fedora-based VM because it will import some keys into your gnupg keyring due to KEYRING_DIR_GIT = and you have to trust mine ang ptitdoc's keys for the patches. Steps to build the full archlinux template:

1. Ensure that the prerequisite packages are installed: sudo dnf install gpg git createrepo rpm-build make wget rpmdevtools python-sh dialog rpm-sign dpkg-dev debootstrap PyYAML
2. Import the QubesOS master signing key and trust it as shown here.
3. Import and trust my own gpg key (AAA4DA6AAC8D0566AF6268FAB18CC631F0907355) and ptitdoc's (D85EE12F967851CCF433515A2043E7ACC1833B9C) as well. This and the KEYRING_DIR_GIT = configuration won't be necessary after the patches are merged, but for now beat the alternative (as long as you use a separate VM for building the template).
4. Clone the qubes-builder and copy my builder.conf inside.
5. Run make get-sources
6. Run make qubes-vm
7. Run make template

[na--]

It looks like you haven't picked up my modifications to vmm-xen.

Here is the builder.conf file I successfully used yesterday to build the full template. All of the changes from example-configs/qubes-os-master.conf are in the bottom of the file, after the three rows of #######.

Build this in a separate fedora-based VM because it will import some keys into your gnupg keyring due to KEYRING_DIR_GIT = and you have to trust mine ang ptitdoc's keys for the patches. Steps to build the full archlinux template:

1. Ensure that the prerequisite packages are installed: sudo dnf install gpg git createrepo rpm-build make wget rpmdevtools python-sh dialog rpm-sign dpkg-dev debootstrap PyYAML
2. Import the QubesOS master signing key and trust it as shown here.
3. Import and trust my own gpg key (AAA4DA6AAC8D0566AF6268FAB18CC631F0907355) and ptitdoc's (D85EE12F967851CCF433515A2043E7ACC1833B9C) as well. This and the KEYRING_DIR_GIT = configuration won't be necessary after the patches are merged, but for now beat the alternative (as long as you use a separate VM for building the template).
4. Clone the qubes-builder and copy my builder.conf inside.
5. Run make get-sources
6. Run make qubes-vm
7. Run make template

[mannp]

@ptitdoc wow, you've been busy :) thanks very much for the fast turnaround!

[mannp]

@ptitdoc wow, you've been busy :) thanks very much for the fast turnaround!

[mannp]

@ptitdoc no errors on install this time, thanks.

Having tried --debug and changing my mirrors I am still getting errors.

Could this vm be trying to get to qubes repos that it is unable to connect too perhaps?

I am posting it as it seems to be related to signatures and I wondered if it was a noob error and I should go read some more, or its related to the gpg signtures still.

debug: running command: http_proxy=http://127.0.0.1:8082/ /usr/bin/curl -C - -f http://mirror.rackspace.com/archlinux/core/os/x86_64/core.db.sig > /var/lib/pacman/sync/core.db.sig.part
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
curl: (22) The requested URL returned error: 404 Not Found

debug: running command: http_proxy=http://127.0.0.1:8082/ /usr/bin/curl -C - -f http://mirror.rackspace.com/archlinux/extra/os/x86_64/extra.db.sig > /var/lib/pacman/sync/extra.db.sig.part
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
curl: (22) The requested URL returned error: 404 Not Found

debug: running command: http_proxy=http://127.0.0.1:8082/ /usr/bin/curl -C - -f http://mirror.rackspace.com/archlinux/community/os/x86_64/community.db.sig > /var/lib/pacman/sync/community.db.sig.part
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
curl: (22) The requested URL returned error: 404 Not Found

[mannp]

@ptitdoc no errors on install this time, thanks.

Having tried --debug and changing my mirrors I am still getting errors.

Could this vm be trying to get to qubes repos that it is unable to connect too perhaps?

I am posting it as it seems to be related to signatures and I wondered if it was a noob error and I should go read some more, or its related to the gpg signtures still.

debug: running command: http_proxy=http://127.0.0.1:8082/ /usr/bin/curl -C - -f http://mirror.rackspace.com/archlinux/core/os/x86_64/core.db.sig > /var/lib/pacman/sync/core.db.sig.part
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
curl: (22) The requested URL returned error: 404 Not Found

debug: running command: http_proxy=http://127.0.0.1:8082/ /usr/bin/curl -C - -f http://mirror.rackspace.com/archlinux/extra/os/x86_64/extra.db.sig > /var/lib/pacman/sync/extra.db.sig.part
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
curl: (22) The requested URL returned error: 404 Not Found

debug: running command: http_proxy=http://127.0.0.1:8082/ /usr/bin/curl -C - -f http://mirror.rackspace.com/archlinux/community/os/x86_64/community.db.sig > /var/lib/pacman/sync/community.db.sig.part
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
curl: (22) The requested URL returned error: 404 Not Found

[mannp]

Seems this core.db.sig.part issue is related to the db signing and changing the SigLevel works, but is it recommended for Qubes?

SigLevel = Required DatabaseOptional
LocalFileSigLevel = Optional

to

SigLevel = Required DatabaseNever
LocalFileSigLevel = Optional

[mannp]

Seems this core.db.sig.part issue is related to the db signing and changing the SigLevel works, but is it recommended for Qubes?

SigLevel = Required DatabaseOptional
LocalFileSigLevel = Optional

to

SigLevel = Required DatabaseNever
LocalFileSigLevel = Optional

[ptitdoc]

It is because the core and extra repositories are not signed. But you should not worry too much about that. The packages themselves are signed anyway.

You are right about gentoo > archlinux. I came from gentoo too. But it probably changed a lot since I last used it.

[ptitdoc]

It is because the core and extra repositories are not signed. But you should not worry too much about that. The packages themselves are signed anyway.

You are right about gentoo > archlinux. I came from gentoo too. But it probably changed a lot since I last used it.

[mannp]

Ok thanks for that; the change works and I have now changed all my fedora-26 vm's over to arch.

Interesting you came from gentoo too :)

[mannp]

Ok thanks for that; the change works and I have now changed all my fedora-26 vm's over to arch.

Interesting you came from gentoo too :)

[mannp]

So I have gotten rather carried away by pacaur and now have a few more packages in my template than I thought :)

Is there a possibility of archlinux-minimal for me to use for all my net, usb, firewall, gpg-vault etc?

Or should I create another archlinux normal template and use that?

[mannp]

So I have gotten rather carried away by pacaur and now have a few more packages in my template than I thought :)

Is there a possibility of archlinux-minimal for me to use for all my net, usb, firewall, gpg-vault etc?

Or should I create another archlinux normal template and use that?

[mannp]

Easy answer, don't do it without a recent backup as the new template will wipe out the current on transfer :( blah

[mannp]

Easy answer, don't do it without a recent backup as the new template will wipe out the current on transfer :( blah

[na--]

You can use qvm-clone to clone the archlinux template with an archlinux-minimal name - the one template you fatten-up with all the packages your heart desires, the other one you trim down to what you need for the service VMs. Take a look at this for removing webkit2gtk from the minimal template.

If you already have a fat archlinux template, you can build a fresh one from scratch with a different name. Take a look at the TEMPLATE_LABEL and TEMPLATE_ALIAS options in qubes-builder's builder.conf. I think that if you set TEMPLATE_LABEL += archlinux:archlinux-minimal in the builder.conf with the other archlinux-specific options above, make template will produce a .rpm that won't conflict or overwrite the existing archlinux template.

[na--]

You can use qvm-clone to clone the archlinux template with an archlinux-minimal name - the one template you fatten-up with all the packages your heart desires, the other one you trim down to what you need for the service VMs. Take a look at this for removing webkit2gtk from the minimal template.

If you already have a fat archlinux template, you can build a fresh one from scratch with a different name. Take a look at the TEMPLATE_LABEL and TEMPLATE_ALIAS options in qubes-builder's builder.conf. I think that if you set TEMPLATE_LABEL += archlinux:archlinux-minimal in the builder.conf with the other archlinux-specific options above, make template will produce a .rpm that won't conflict or overwrite the existing archlinux template.

[mannp]

Excellent @na-- that worked a treat, now have my recovered vm from a week old backup and archlinux-minimal ready for some downsizing (if I can).

Many thanks.

[mannp]

Excellent @na-- that worked a treat, now have my recovered vm from a week old backup and archlinux-minimal ready for some downsizing (if I can).

Many thanks.

[ptitdoc]

@marmarek merged most of the changes. The template currently build properly with the following override.conf file:

BRANCH_core_agent_linux = archlinux-keyring
GIT_URL_core_agent_linux = https://github.com/ptitdoc/qubes-core-agent-linux

BRANCH_builder_archlinux = master
GIT_URL_builder_archlinux = https://github.com/ptitdoc/qubes-builder-archlinux

BRANCH_app_linux_split_gpg = archfix2
GIT_URL_app_linux_split_gpg = https://github.com/ptitdoc/qubes-app-linux-split-gpg

[ptitdoc]

@marmarek merged most of the changes. The template currently build properly with the following override.conf file:

BRANCH_core_agent_linux = archlinux-keyring
GIT_URL_core_agent_linux = https://github.com/ptitdoc/qubes-core-agent-linux

BRANCH_builder_archlinux = master
GIT_URL_builder_archlinux = https://github.com/ptitdoc/qubes-builder-archlinux

BRANCH_app_linux_split_gpg = archfix2
GIT_URL_app_linux_split_gpg = https://github.com/ptitdoc/qubes-app-linux-split-gpg

[zander]

@ptitdoc

I uploaded the binary packages for Qubes 4.0 in testing.
You can try them by changing current to testing in the repository URL.

What is the policy for pushing stuff up to current from testing?
As there isn't any package in current for this, having even partially working packages is better than nothing.

I asked this on the mailinglist too; https://groups.google.com/forum/#!msg/qubes-users/PNBPHUyrfnk/50TrVJiMAAAJ

[zander]

@ptitdoc

I uploaded the binary packages for Qubes 4.0 in testing.
You can try them by changing current to testing in the repository URL.

What is the policy for pushing stuff up to current from testing?
As there isn't any package in current for this, having even partially working packages is better than nothing.

I asked this on the mailinglist too; https://groups.google.com/forum/#!msg/qubes-users/PNBPHUyrfnk/50TrVJiMAAAJ

[zander]

Doing the 'make template' part causes a significant amount of downloads from the arch servers.
The pacman mirrors only uses one server, the rackspace com one. This not only caused a slow download for me in Europe, but after some time my IP got a temporary block from them. So downloads started timing out.

It may be useful to use 'rankmirrors' (see their wiki) before doing all the downloads. This should already be done immediately after the initial template download.

Sorry, I really don't understand the build system or I would be able to help.

[zander]

Doing the 'make template' part causes a significant amount of downloads from the arch servers.
The pacman mirrors only uses one server, the rackspace com one. This not only caused a slow download for me in Europe, but after some time my IP got a temporary block from them. So downloads started timing out.

It may be useful to use 'rankmirrors' (see their wiki) before doing all the downloads. This should already be done immediately after the initial template download.

Sorry, I really don't understand the build system or I would be able to help.

[zander]

Seems like a change was made that causes a regression in the creation of this template.
Building of the gui-agent fails. See the make output attached here;

output.log

[zander]

Seems like a change was made that causes a regression in the creation of this template.
Building of the gui-agent fails. See the make output attached here;

output.log

[marmarek]

That include line is there since 2010... Probably some change in X server headers. What X server version currently live in Arch?

[marmarek]

That include line is there since 2010... Probably some change in X server headers. What X server version currently live in Arch?

[zander]

On my laptop;

$pacman -Qo /usr/include/X11/Intrinsic.h
/usr/include/X11/Intrinsic.h is owned by libxt 1.1.5-1

And generic; xorg-server 1.19.5-1

[zander]

On my laptop;

$pacman -Qo /usr/include/X11/Intrinsic.h
/usr/include/X11/Intrinsic.h is owned by libxt 1.1.5-1

And generic; xorg-server 1.19.5-1

[marmarek]

Maybe just missing build dependency?

[marmarek]

Maybe just missing build dependency?

[zander]

Thanks for the hint, it was indeed due to an upstream archlinux change.

Fix in QubesOS/qubes-gui-agent-linux#29

[zander]

Thanks for the hint, it was indeed due to an upstream archlinux change.

Fix in QubesOS/qubes-gui-agent-linux#29

[zander]

Using this task to register some more issues;

• the template doesn't have a proper locale. See ArchLinux Installation guide, the /etc/locale.conf should have content like; LANG=en_US.UTF-8, in the template the file is just missing.

• while sudo works fine, just plain su doesn't give you password-less root.

• any templateVM or appVM based on the archlinux template fails to have the standard setup for networking. Specifically: the iptables is empty.

[zander]

Using this task to register some more issues;

• the template doesn't have a proper locale. See ArchLinux Installation guide, the /etc/locale.conf should have content like; LANG=en_US.UTF-8, in the template the file is just missing.

• while sudo works fine, just plain su doesn't give you password-less root.

• any templateVM or appVM based on the archlinux template fails to have the standard setup for networking. Specifically: the iptables is empty.

[viq]

Amusingly enough this currently fails for me on installing libbluray :P

[viq]

Amusingly enough this currently fails for me on installing libbluray :P

[viq]

Ah, that was me not knowing how to apply override.conf properly. Now with upstream core_agent_linux it builds, haven't tried installing yet though.

[viq]

Ah, that was me not knowing how to apply override.conf properly. Now with upstream core_agent_linux it builds, haven't tried installing yet though.

[arjan-s]

The binary repository in my templates from a few months back has stopped working due to a PGP error. Should I be using a new repo, or build my own packages?
What are the chances of an official Arch Linux template for QubesOS 4.0?

[arjan-s]

The binary repository in my templates from a few months back has stopped working due to a PGP error. Should I be using a new repo, or build my own packages?
What are the chances of an official Arch Linux template for QubesOS 4.0?

[fosslinux]

@na-- @mannp Is there a binary Arch Linux template available yet in Qubes 4.0 or is DYI?

[fosslinux]

@na-- @mannp Is there a binary Arch Linux template available yet in Qubes 4.0 or is DYI?

[na--]

I don't think so, sorry, Arch is not one of the officially supported distros. But I had no issues the last few times I tried to build the template (see "Steps to reproduce the behavior"), so I should probably close this issue... I think a few of the minor problems mentioned here still remain, but they would probably be better off in separate issues rather than in this huge one. @marmarek, @andrewdavidwong ?

[na--]

I don't think so, sorry, Arch is not one of the officially supported distros. But I had no issues the last few times I tried to build the template (see "Steps to reproduce the behavior"), so I should probably close this issue... I think a few of the minor problems mentioned here still remain, but they would probably be better off in separate issues rather than in this huge one. @marmarek, @andrewdavidwong ?

[andrewdavidwong]

But I had no issues the last few times I tried to build the template (see "Steps to reproduce the behavior"), so I should probably close this issue... I think a few of the minor problems mentioned here still remain, but they would probably be better off in separate issues rather than in this huge one.

Correct. Please file separate issues for them.

[andrewdavidwong]

But I had no issues the last few times I tried to build the template (see "Steps to reproduce the behavior"), so I should probably close this issue... I think a few of the minor problems mentioned here still remain, but they would probably be better off in separate issues rather than in this huge one.

Correct. Please file separate issues for them.

[JohnDoe02]

While building up to date qubes arch packages (make get-sources; make qubes-vm) used to work for me in the past, it fails since a week or so with a compilation error in building vmm-xen:

dsdt_pvh.c:3494:25: error: 'dsdt_pvh' undeclared here (not in a function); did you mean 'dsdt_pvh_len'?
 int dsdt_pvh_len=sizeof(dsdt_pvh);

Starting again from scratch (i.e., from a fresh qubes-builder clone) does not fix this. Anyone, for whom building the template is working at the moment?

[JohnDoe02]

While building up to date qubes arch packages (make get-sources; make qubes-vm) used to work for me in the past, it fails since a week or so with a compilation error in building vmm-xen:

dsdt_pvh.c:3494:25: error: 'dsdt_pvh' undeclared here (not in a function); did you mean 'dsdt_pvh_len'?
 int dsdt_pvh_len=sizeof(dsdt_pvh);

Starting again from scratch (i.e., from a fresh qubes-builder clone) does not fix this. Anyone, for whom building the template is working at the moment?

[arjan-s]

@JohnDoe02 I have the exact same issue and not been able to find a solution yet

[arjan-s]

@JohnDoe02 I have the exact same issue and not been able to find a solution yet

[JohnDoe02]

@arjan-s So I am not the only one. I filed an issue.

[JohnDoe02]

@arjan-s So I am not the only one. I filed an issue.

[arjan-s]

I created two PRs currently needed to be able to build this template again:
QubesOS/qubes-vmm-xen#42
QubesOS/qubes-gui-agent-linux#44

[arjan-s]

I created two PRs currently needed to be able to build this template again:
QubesOS/qubes-vmm-xen#42
QubesOS/qubes-gui-agent-linux#44

[na--]

Closing this huge issue, if someone wants to report anything else, please open a separate dedicated issue 😄

[na--]

Closing this huge issue, if someone wants to report anything else, please open a separate dedicated issue 😄