Automate debian-minimal based template creation

Scroll down the Q appmenu until you reach the Template (disp) section. That’ll open the dvm template. However it is not recommended to open the browser in the template because that may lead to profile fingerprinting. If you’ve already done so and wish to remove existing profiles run the following in the dvm-template:

[user@deb-11-firefox-dvm ~] rm -r /home/user/.mozilla

You should instead consider using Firefox’s autoconfig (as mentioned in the guide above: [Guide] Automatically install extensions and configure new (dispvm) Firefox profiles with arkenfox user.js and policies) and/or Firefox policies. I wrote a brief explanation here:
How to install addons's or arkenfox profile in template vm so it is there in disposable vm? - #14 by BEBF738VD

update: the linked guide now contains a full explanations of policies as well.

For this issue specifically, add the following to the policies.json file mentioned in the guide:

    "FirefoxHome": {
      "Search": true,
      "TopSites": false,
      "SponsoredTopSites": false,
      "Highlights": false,
      "Pocket": false,
      "SponsoredPocket": false,
      "Snippets": false,
      "Locked": false
    "Homepage": {
      "URL": "about:home",
      "Locked": false,
      "StartPage": "homepage"

This will disable everything unnecessary and will leave you with a plain homepage with a search-bar.

1 Like

Yep, this solved it.

I don’t know what was the deal with my machine not showing up in the upper menu even though I set that feature flag. But when I renamed it, it did show up. So now I had a perfectly good disposable template with firefox set up the way I wanted…but with a profile to track. There may be a bug here. Anyhow, I simply re-ran the script to create the thing (thanks to sven for the inspiration for that), then went through the procedure referenced above, and now I have a good disposable template without the profile.

Just creating a set of minimal templates… I am facing one issue with this:


# WARNING: Never run any code that you don’t trust. And the only way to
# truly trust code is to understand what it does.
# Therefore, read carefully the following documents before you run this script:
# source:
# source:
# official:
# To run this script command the following in a dom0 Terminal:
# Prerequisite: SOURCE_TEMPLATE=deb-11-m (debian-xx-minimal)
# 1. copy *.sh to dom0: qvm-run --pass-io SOURCE_APPVM 'cat ...' > DOM0_TARGET
# 2. set execute permission: chmod +x ./
# 3. run script: ./

# define and clone templates
# AppVM attributes and AppVM creation (optionally)
read -p "Do you want to create an AppVM afterwards? (y/n) :  " appvm_prompt

# install all but only necessary packages
qvm-run --pass-io -u root $FLATPAK_TEMPLATE "apt install qubes-core-agent-networking -y"
qvm-run --pass-io -u root $FLATPAK_TEMPLATE "apt install qubes-core-agent-network-manager -y"
qvm-run --pass-io -u root $FLATPAK_TEMPLATE "apt install pulseaudio-qubes -y"
qvm-run --pass-io -u root $FLATPAK_TEMPLATE "apt install qubes-usb-proxy -y"
qvm-run --pass-io -u root $FLATPAK_TEMPLATE "apt install qubes-core-agent-nautilus -y"
qvm-run --pass-io -u root $FLATPAK_TEMPLATE "apt install nautilus -y"
qvm-run --pass-io -u root $FLATPAK_TEMPLATE "apt install zenity -y"
# required for flatpak app
qvm-run --pass-io -u root $FLATPAK_TEMPLATE "apt install python3-setuptools -y"
qvm-run --pass-io -u root $FLATPAK_TEMPLATE "apt install python3-stdeb -y"
qvm-run --pass-io -u root $FLATPAK_TEMPLATE "apt install dh-python -y"
qvm-run --pass-io -u root $FLATPAK_TEMPLATE "apt install flatpak -y"
qvm-run --pass-io -u root $FLATPAK_TEMPLATE "apt install python3-pyside2.qtcore -y"
qvm-run --pass-io -u root $FLATPAK_TEMPLATE "apt install python3-pyside2.qtgui -y"
qvm-run --pass-io -u root $FLATPAK_TEMPLATE "apt install python3-pyside2.qtwidgets -y"
# required only for the build process
qvm-run --pass-io -u root $FLATPAK_TEMPLATE "apt install git -y"
qvm-run --pass-io -u root $FLATPAK_TEMPLATE "apt install fakeroot -y"
qvm-run --pass-io -u root $FLATPAK_TEMPLATE "apt install build-essential -y"

# create a temporary AppVM to download git repository and build script
qvm-create temporary-appvm -t $FLATPAK_TEMPLATE --label red

# clone micahflee's git repository and run the script
qvm-run --pass-io -u root temporary-appvm "git clone"
qvm-run --pass-io -u root temporary-appvm "cd qube-apps && ./"

# move deb package to flatpak template and purge setup
qvm-run --pass-io -u root temporary-appvm "qvm-move-to-vm $FLATPAK_TEMPLATE deb_dist/*.deb"
qvm-shutdown --wait temporary-appvm
qvm-remove temporary-appvm -f
qvm-run --pass-io -u root $FLATPAK_TEMPLATE "apt remove git -y"
qvm-run --pass-io -u root $FLATPAK_TEMPLATE "apt remove fakeroot -y"
qvm-run --pass-io -u root $FLATPAK_TEMPLATE "apt remove build-essential -y"

qvm-run --pass-io -u root $FLATPAK_TEMPLATE "dpkg -i QubesIncoming/temporary-appvm/*.deb -y && poweroff"

echo -e "\nYou have installed the Qube-Apps Flatpak Installer & Updater by @micahflee, please read Micah Lee’s blog post about ‘Qube-Apps’.\n\nSOURCE: \nIMPORTANT: You should increase the private storage on your Flatpak-AppVM.\nREMARK: This is special use-case of a minimal template and it is not and can never be tested with all possible Flatpaks. Consequently, there could be special configurations and additional packages required to run a flatpak. \n"

if [ $appvm_prompt = 'y' ]; then
	echo "INFO: AppVM < $APPVM_NAME > has been created."

I see one error in the build process:

dpkg-builpackage: erro: gain-root-command 'fakeroot' not found

I am not sure if it is an issue related to the fakeroot or something within micahflee’s script?

OK, so I tried to automate all this profile and settings stuff. Fortunately, I changed the name of the qubes I was generating.

The new disposable qube simply shut down immediately when I started firefox in it.

I removed the new stuff, figuring I’d made some bonehead error copying text.

This qube now contains nothing but a straight network-and-firefox-esr installation, and still when I start it, it simply shuts down immediately without displaying firefox esr. (Xterm works fine).

Journal CTL displays no error message. The qube starts, it shuts down, as if that’s what I had somehow configured it to do.

So I must be making some bonehead mistake somewhere. What could it be?

In dom0 qvm-run QUBE xterm
When the terminal opens, run firefox-esr and check for error messages.

You can also check for relevant information in /var/log/qubes/guid.<name>.log (change <name> with the qube’s name).

OK (and thank you for a fast response!)

I didn’t think to run it from within Xterm. OK, to clarify, the old disposable VM, which doesn’t do this, is named MidInternet, its template is deb11a-internet-dvm. This is the one which works (almost) perfectly [It has one issue I haven’t mentioned yet, and won’t mention now to keep the thread from branching ridiculously]. I had manually added all of the arkenfox stuff to it.

The new one is MidInternetX, and its template is deb11a-internet-dvmX. This one if I run firefox, terminates immediately and I never see firefox open. This started out as my attempt to automate the Arkenfox stuff from a script; when it behaved like this I stripped out the Arkenfox stuff and (in desperation) even other apps I was installing.

When I run an Xterm on MidInternetX, and run firefox, firefox actually starts, with of course the two tabs I wanted to get rid of. That’s more than happens from the menu. The only outputs are:

  1. The invariable complaints about my “locale” not being supported. Aside from generating annoying error messages, this is never an actual damn issue.

  2. “[GFX1-]: glxtest: libpci missing.”

However, I tried this with MidInternet as well (the one that works), and got exactly the same output.

I also tried scrolling to the bottom of the menu and starting Firefox in MidInternetX there (as I understand it from earlier, this opens it in the DVM template without making it disposable), and it works fine there (two extra tabs, becuase the Arkenfox stuff is not done in MidInternetX’s template).

So there’s somehow something bodged up with the disposable-ness of the thing, but I’ll be dipped if I can figure out what that is. Like I said this is probably a stupid, forehead-smacker of an error but it’s been driving me nuts for two days.



Apparently it does this if the templateVM is running.

And of course I was leaving it running so it would be more convenient to check that it’s moving the files around.

The errors are not too bad, you should be able to fix the second one by installing libpci3 and libpciaccess0 in the template.

Strongly discouraged for the reasons I mentioned before, you should remove the .mozilla folder.

You’re supposed to install the policies.json and autoconfig.js files in the template, not in the dvm. So it shouldn’t matter what dvm you’re using (as it does NOT require any kind of extra configuration), as long as they’re using the same template.

I suggest that you create a new dvm-template and do not touch that at all, and delete the old one.

I do that as part of the script.

I ONLY did that this time to see whether it would do something different. That one, in fact, is already gone.

To clarify, all installations (including arkenfox stuff, when enabled) happen ONLY to deb11a-internet-dvmX. At the very end of that script, I create MidInternetX from deb11a-internet-dvmX


In it’s current form the ‘note’ is about template creation, not qube creation (disposable templates). That’s of course something I also automate, especially for the disposable sys-qubes.

Thank you for the feedback, I’ll add a clarification and later a second ‘note’ on how to automate the creation of some common qubes.

@whoami as a rule of thumb: do it first manually in the actual cloned template, step-by-step and find/solve all issues this way. Then when you have a sequence that works, write the dom0-based shell script that reflects it.

If there is an issue with this specific debian-minimal based flatpack install thingy… make a separate thread for it please.

Yea, I did it like this, step-by-step. Wasn’t easy for me as ‘low-code-developer’ :face_holding_back_tears:

Anyways, I have made a template for the templates …

With this I am building up my scripts based on your explanations. I will publish it on Gitea and share the link in the coming days…

1 Like

Looking forward to seeing that.

I just browsed through the . Wow, I do see no reason to continue my work when I see that we already have such a well structured and coded work.

I will pause my work on building my mini-templates. Instead, I will spend my time in reviewing the liteqube code and if I feel confident with the code I will work on the customization section.

If someone is interested in my current state of my mini-script just drop me a direct message.


I also studied Liteqube, I ran my eyes over the code and due to my limited understanding it did not confuse me.
I plan to install Kicksecure security patches over Liteqube, I’ll be sure to make a report.
But, I ran into problems during the installation phase, I tried to solve them, but I lack the understanding to read the scripts.

I’m waiting for your conclusions on code analysis :slight_smile:

I agree, LiteQube looks really good. Will be checking it out.

I was partway through developing my own set of minimal scripts–actually most of the way–and I have about a zillion templates out there now (Inspired by sven, and I was trending towards pushing a script onto a qube template and letting it initialize itself rather than making a zillion calls to qvm-run). I don’t know how much I’ll be able to use this for AppVMs (though it looks like it may either solve some problems with my workflow or get me started learning what to do), but I can at least slim down the sys qubes!

Most of my other tweaks to the system have been in defaults and the Menu’s list of apps–I can write a script for the latter with what I know today (and this mostly affects AppVMs, not templates).

I tested Liteqube on my test machine, in my opinion it is still raw for an amateur like me, many small problems that had to be solved, also there was a problem when I decided to make 1 template on 1 vms, it worked but no-gui terminal did not want to run with templates that are not named “debian-core”. In addition I didn’t have enough knowledge to read the code, so I won’t risk to install it on my main machine.
The interesting thing about Liteqube is that it somehow transfers Xorg to another cube although I haven’t seen it start when I ran the tests, is there any way I can disable Xorg on my minimal templates?

I decided to finish my scripts following Sven’s instructions, but I have a desire to make debian-11-minimal even smaller like Liteqube does, from his posts on Reddit I learned that he additionally clears the minimal template, but going into the scripts I can’t find how exactly this is done. I will be glad if someone can tell me commands or packages which can be safely removed. :slight_smile:

Thanks for reading :slight_smile:

1 Like

I would appreciate if you someone could review my template for minimal templates. Do not expect high-quality coding since my C++ course is more than 10 years ago…

Up to now, I did not use any helper scripts or functions. As proposed by Sven it would make sense to add a lib with some functions like feature-audio, feature-file-manager etc. or some “shortcuts”-functions like Liteqube to improve the code.

To use my template for minimal templates you basically just need to modify two code sections. The rest of the code is feedback, if and while loops to ensure proper settings and the possibility to do the customization via a terminal dialog. Personally, I also found it pretty useful for testing.

The template is here: template for minimal templates -

For a quick preview that actually does nothing (no cloning, no installation) I made this: minimal template example -

My goal would be to create a git with some fundamental VMs (net, firewall, vault, usb…)
A second group with commonly used VMs (office, printer, ssh, …)
And a third group with some special VMs (Monero wallet, git, syncthing, …)

I also wonder if it is possible to make a script for a minimal VPN template… Anyways, all this makes only sense if some community members would like to support this and fill in their minimal templates.

As @Sven already described, it could be used to help mini-templates-newbies to get started or use it as quick rebuild of a personal Qubes setup.

What do you think:
(as already stated several times) minimal templates != for Qubes newbies ?

Would it be beneficial to start with a git archive to collect, improve and maintain minimal templates?

1 Like

@whoami I don’t think it’s a good idea to make these scripts available for several reasons:

  • It trains/enables users to download and run bash scripts they do not read or understand – in dom0!

  • Instead of teaching users how to build their own minimal templates and how to solve dependency problems, you’ll end up with lots of unskilled users being frustrated and blaming Qubes OS for being “not ready” / “too hard” when things don’t work immediately as they expected.

  • These scripts will become stale quickly and need to be maintained.

  • People will start complaining that you don’t provide a script for their favorite use case / application and “Qubes OS sucks!” etc.

It’s the good old “if you give a man a fish, you have fed him for a day, but if you teach him to fish, you have fed him for a lifetime” thing. :wink:

1 Like