I recently found out that a ‘qubes-template-kali’ was added to the 4.1-Release’s repository and I thought I give it a try. Unfortunately I ran in some issues regarding disk space during installation:
$ sudo qubes-dom0-update --enablerepo=qubes-templates-community-testing qubes-template-kali
Using sys-whonix as UpdateVM to download updates for Dom0; this may take some time...
--> Running transaction check
---> Package qubes-template-kali.noarch 0:4.0.6-202011011421 will be installed
--> Finished Dependency Resolution
/var/lib/qubes/dom0-updates/packages/qubes-template-kali-4.0.6-202011011421.noarch.rpm already exists and appears to be complete
Successfully verified /var/lib/qubes/dom0-updates/packages/qubes-template-kali-4.0.6-202011011421.noarch.rpm
qfile-agent: Fatal error: File copy: Disk quota exceeded; Last file: qubes-template-kali-4.0.6-202011011421.noarch.rpm (error type: Disk quota exceeded)
'/usr/lib/qubes/qrexec-client-vm dom0 qubes.ReceiveUpdates /usr/lib/qubes/qfile-agent /var/lib/qubes/dom0-updates/packages/*.rpm' failed with exit code 1!
I decided to pass the successfully downloaded RPM to Dom0 and took the risk to dnf install qubes-template-kali-4.0.6-202011011421.noarch.rpm the package.
sudo dnf install Downloads/qubes-template-kali-4.0.6-202011011421.noarch.rpm
[...]
================================================================================
Package Arch Version Repository Size
================================================================================
Installing:
qubes-template-kali noarch 4.0.6-202011011421 @commandline 2.7 G
Transaction Summary
================================================================================
Install 1 Package
Total size: 2.7 G
Installed size: 9.6 G
[...]
Error: Transaction test error:
installing package qubes-template-kali-4.0.6-202011011421.noarch needs 1285MB on the / filesystem
Error Summary
-------------
Disk Requirements:
At least 1285MB more space needed on the / filesystem.
It appears to me that the qubes-template-kali installation needs a lot more of Dom0’s disk space than other usual templates. The default 20 GiB Dom0 root partition looks to be not sufficient in my case.
I don’t want to go any further and break things by trying to resize Dom0-partitioning, but suspect that this is an issue that could occur to other potential qubes-template-kali-users as well.
As far as I understand the template is built with the metapackage kali-linux-default. Maybe it would be less painful to use kali-linux-core instead. Of course, this would require users to install most packages themselves. But I suspect that anyone who is really going to use kali will know which (meta-)packages he requires.
Template is not going to be installed in dom0 (lvm thin pool of 20GB). It’s just for transferring from local RPM transaction to vm thin pool. Yes kali template is a little bit big but it’s the default. Currently your issue is that dom0 is not having enough place to extract the RPM…You can try to make some place, eventually clear the log: journalctl --vacuum-time=1d to gain this missing space on /. We are currently thinking on how to solve dom0 space (e.g. remove packages pulled by default with other default packages). This is new in 4.1 where we split dom0/VM thin pool in order to easily make dom0 snapshots.
Thanks for the explanation. That’s what I suspected.
I have just successfully built a qubes-template-kali based on the kali-linux-core metapackage. I just quickly replaced the default metapackage with the core metapackage in 04_install_qubes_post.sh.
The resulting RPM is just 1.1 GiB in size and Dom0’s dnf announces 4.5 GiB of ‘installed size’.
Maybe this is something that is worth adding as a template flavour until the RPM extraction in Dom0 is handled differently or to avoid that changes become necessary. Personally, I think that I prefer the kali-linux-core anyway and would adapt it to the specific use case from there.
An other solution could be to ship the template with kali-linux-core installed and fetch the kali-linux-default packages as part of the RPM’s scriptlets during installation.
Yes this is exactly the purpose of template flavor. I can add core flavor or any keyword meaning something in between minimal (already means strictly minimal even in terms of Qubes packages) and standard/default/vanilla distro. Ideally, I would love to have a keyword common to every templates. For example, there is currently common ones like minimal and xfce. I like the term core also here referencing to specific Kali meta package. That could be a general flavor for saying: standard Qubes packages + a set of minimal distro packages. @adw@marmarek@deeplow would you have eventually some opinion on this?
The normal way for doing this would be to use Salt. Doing network stuff in RPM transaction means ensure to have network available (that’s not always the case) and for sure, it will raise errors due to networks issues.
I don’t know if it’s true or if I remember having read something about standard template we deliver should match the underlying vanilla distribution. In this case, doing an exception would be weird for Kali. I would say that ideally core is a step in between having “minimal Qubes and distro packages” and a vanilla distro having all the standard Qubes packages.
Minimal templates are fine for tweaking as much as possible things but standard (vanilla) templates could be already too big like Kali (or even Fedora…).
Also, I would say that ideally it’s a step in between having minimal Qubes and distro packages and a vanilla distro having all the standard Qubes packages.
Unfortunately, usual distro like Fedora does not give us selected subset of packages for defining flavors up to minimal or desktops (e.g. famous spin iso), not something like “light” Fedora without too much recommended things. That would be us which would need to do this work.
As very few distro like Kali provide a way to customize multiple levels of what inside it, I would stick to flavor term not being general but related to distro. That’s also the case of what I imagine for Gentoo which provides multiple profiles. The term for flavor referring to those profiles would be Gentoo specific.
In that case, I don’t see how it ends up being different, in practice, from abandoning the above policy.
“Too big” is subjective and relative to the user’s disk size, isn’t it?
I’m a bit worried about the long-term maintenance burden if we take this on. Are we essentially committing ourselves to maintaining our own Fedora distro in perpetuity?
Mostly of what’s inside the template in terms of quantity of packages.
Yes that’s why having multiple flavors not defined by the underlying distro is not very helping and is not something I would like to go.
To summarize, I would say that it’s probably better to define flavor per distro giving us the opportunity to select easily what’s inside the template like Kali providing specific meta-packages to build the resulting distribution of Gentoo with its Portage profiles.
@wind.gmbh I’m fine to define Kali core flavor but not changing default Kali is not. Better stick to vanilla Kali using kali-linux-default. I’ll do it in the next days. Also, I’m having possibly few fixes in mind.
Hi guys I have been trying to follow this thread. I have just tried to download the Kali template on 4.1 but it says I need an extra 5585mb of space. I tried emptying the journal and still no luck. What’s the process to download the qubes-template-kali core? I tried qubes-template-kali-core but it can’t find it? Have I missed something here?
Thanks
H