Alpine Linux Template (non-official) available for testing

I’m confused, you give traces from a fedora qube [1] [2] whereas you ask about your Linux template…

[1] fc37 is for fedora 37 :

[2] and yum is about a fedora or red-hat like linux distribution :

The @ayakael workaround should be done inside the Linux template. If the workaround doesn’t work you also could go back a previous template version (qvm-volume revert or from your backup).

Thank you for your support.

The workaround could not be implemented in the Linux template (Alpine), as this template VM could no longer be started. Also a qvm-volume revert did not help, because both “revert versions” were damaged by the last upgrade.

I had to completely reinstall and reconfigure the Alpine template VM.

Sorry about that, but that’s why you should do backups.

Qubes includes

  1. the very useful Backup Qubes tool
  2. the qvm-clone command or its GUI from Qubes Manager (Clone qube)

Weekly I do a complete backup with Backup Qubes, each 2-3 weeks or before a big/dangerous update I do a clone of my templates. So I can use 4-levels backup : qvm-volume revert, use a clone, use my external backup, use my out-of-site backup.

Upgrading to v3.22

With the release of Alpine v3.22, the template RPM is now out, and available here: qubes-template-alpine322 - Ayakael: My personal forge

For in-place upgrading from v3.21 to v3.22, you must apk upgrade to latest v3.21 packages before upgrading to v3.22, else you might break your template.

3 Likes

Very sorry about that. Indeed, backups should be a part of everyone’s pratice. Thank you ludovic for the options.

In the future, you can also sudo xl console name-of-vm from dom0 to access an unstartable VM, and attempt a fix.

In this case, it was a matter of getting the new version of qubes-libvhcan-xen on there and installed. Regardless, I’ve implemented a workaround where qubes-libvchan-xen will use any version of Xen shared objects, thus upgrades of Xen won’t cripple the template.

I upgraded v3.21 to v3.22 in-place without any issues. Works well.

I made a PR to add support for APK/Alpine for updates availability checks. After that is merged, a busybox cron scheduler could be added to periodically check for updates availability and notify dom0 if qubes-update-check service is enabled (similar to other templates).

I will also work on vmupdate library and add APK support. To allow users update their Alpine templates via qubes-vm-update and/or Updater GUI.

Please let me know if you would prefer development discussions on Forum or on Github.

1 Like

@ayakael
PR for vmupdate is done:

1 Like

Is the 4.2 repo discontinued?

No, it works, see my template:

pl-alpine-322:~$ sudo apk upgrade
fetch https://dl-cdn.alpinelinux.org/alpine/v3.22/main/x86_64/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/v3.22/community/x86_64/APKINDEX.tar.gz
fetch https://ayakael.net/api/packages/forge/alpine/v3.22/qubes-r4.2/x86_64/APKINDEX.tar.gz
OK: 1668 MiB in 664 packages
tpl-alpine-322:~$ cat /etc/apk/repositories
https://dl-cdn.alpinelinux.org/alpine/v3.22/main
https://dl-cdn.alpinelinux.org/alpine/v3.22/community
https://ayakael.net/api/packages/forge/alpine/v3.22/qubes-r4.2
tpl-alpine-322:~$ 

Upgrading to r4.3

With the first release candidate out for QubesOS r4.3, I’ve built a template RPM to test Alpine Linux on this new version. You can already upgrade to this release.

In-place upgrade

  1. Upgrade your QubesOS to r4.3
  2. From within template, change release of repo in /etc/apk/repositories from qubes-r4.2 to qubes-r4.3
  3. apk update
  4. apk upgrade -a

Note: the template should boot-up fine even without upgrading to r4.3 packages.

From scratch

You can reinstall from scratch by using the Alpine template RPM built for QubesOS r4.3.

First, we need to transfer to dom0 the template key. It is the same key as r4.2.

Within VM, download template key:

curl -JO https://ayakael.net/api/packages/forge/rpm/repository.key

On dom0, transfer and copy key to key store:

qvm-run -p <curl-vm> 'cat </path/to/downloaded/key ' > repository.key
sudo mv repository.key /etc/qubes/repo-templates/keys/RPM-GPG-KEY-ayakael-forge

For installation, you have two options.

Using qvm-template

1) Create repository definition

On dom0, create and/or edit /etc/qubes/repo-templates/ayakael-templates.repo to match the following (note change of r4.3 instead of r4.2 in baseurl if file already exists).

[ayakael-templates]
name=Ayakael templates
baseurl=https://ayakael.net/api/packages/forge/rpm/qubes/r4.3
enabled=1
gpgcheck=1
gpgkey = file:////etc/qubes/repo-templates/keys/RPM-GPG-KEY-ayakael-forge

2) Install template

qvm-template install alpine322

Manually

1) Download and transfer template RPM

On VM, download desired template RPM available in Packages section of the qubes-builder-alpine repo.

curl -JO https:<url/rpm>

On dom0, transfer RPM

qvm-run -p <curl-vm> 'cat </path/to/downloaded/rpm ' > qubes-template-alpine.rpm

2) Install template

qvm-template --keyring /etc/qubes/repo-templates/keys/RPM-GPG-KEY-forge-ayakael install $(pwd)/qubes-template-alpine.rpm
2 Likes

The r4.2 repo will continue until it is EOLed by QubesOS (usually 6 months after the new release).

The baseurl https://ayakael.net/api/packages/forge/rpm/qubes/r4.3 does not work for me. However, https://ayakael.net/api/packages/forge/rpm/qubes/r43 does.

The in-place upgrade worked fine for me, thanks a lot.

Hi i know this is not the right thread to post in but i didnt find any other way to contact you i tried to follow your guide on Using Qubes Builder v2 and i cant for the life of me reproduce what you did but with archlinux could guide me on how to create an archlinux template with qubes builder v2 or publish a detailed guide on how to do it thanks in advance looking forward to your answer

Hi i know this is not the right thread to post in but i didnt find any other way to contact you i tried to follow your guide on Using Qubes Builder v2 and i cant for the life of me reproduce what you did but with archlinux could guide me on how to create an archlinux template with qubes builder v2 or publish a detailed guide on how to do it thanks in advance looking forward to your answer

Upgrading to v3.23

With the release of Alpine v3.23, the template RPMs for Alpine v3.23 targeting r4.2 and r4.3 are now out, and available here: qubes-template-alpine323

For in-place upgrading from v3.22 to v3.23, it is recommended (although not required like in previous upgrade) to latest v3.22 packages before upgrading to v3.23.

(note that r4.2 is still supported for Alpine 3.22 and 3.23)

EDIT: There are some issues with the RPM template, I’ve removed them until I I have time to debug them. In-place upgrading is ready.

4 Likes

great success upgrading to qubes 4.3 and restoring my alpine template, and then upgrading to 3.23 (actually somehow it is running 3.24 beta, but seems to work well).

However it is not posible to to enable the “preload disposable” on it, receving the error: "ERROR: Advanced tab: Qubes does not support the RPC ‘qubes.WaitForRunningSystem’. Is this a simple script/service that can be installed in an Alpine VM to allow preloaded disposables, or is it an entire package which needs to be ported?

Thanks a million.

@cubit

I don’t know how Alpine was built, if it uses qubes-core-agent-linux or not, it it uses systemd or not, it uses Qrexec or not.

There are 3 files needed:

  1. qubes.WaitForRunningSystem
  2. qubes.WaitForSession (this is optional for now, but might be necessary in the future)
  3. qubes.WaitForNetworkUplink

All these Qrexec services uses systemd. You could request the Qubes Alpine contributors to PR to core-agent-linux to provide alternatives to the systemd commands (if Alpine is not using systemd), else, they just need to upload the latest version of core-agent-linux to the repos. If you contact them, please do it publicly so I can follow along and help if they need.

1 Like