[qubes-template-kali] Installation fails with 'disk quota exceeded' error

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!

Dom0’s disk usage looks like this:

$ df -h
Filesystem                   Size  Used Avail Use% Mounted on
devtmpfs                     1.9G     0  1.9G   0% /dev
tmpfs                        2.0G     0  2.0G   0% /dev/shm
tmpfs                        2.0G  3.2M  2.0G   1% /run
/dev/mapper/qubes_dom0-root   20G  7.1G   12G  39% /
tmpfs                        2.0G  8.0K  2.0G   1% /tmp
xenstore                     2.0G  688K  2.0G   1% /var/lib/xenstored
/dev/nvme0n1p2               976M  219M  691M  25% /boot
/dev/nvme0n1p1               599M  6.5M  593M   2% /boot/efi
tmpfs                        391M   24K  391M   1% /run/user/1000

The UpdateVM’s disk usage looks like this:

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda3      9.6G  4.9G  4.3G  54% /
none            9.6G  4.9G  4.3G  54% /usr/lib/modules
devtmpfs        1.9G     0  1.9G   0% /dev
tmpfs           1.0G  4.0K  1.0G   1% /dev/shm
tmpfs           197M   21M  177M  11% /run
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           197M     0  197M   0% /sys/fs/cgroup
/dev/xvdb       2.0G   21M  1.9G   2% /rw
none             10M   20K   10M   1% /run/msgcollector
tmpfs            40M     0   40M   0% /run/user/1000

The rpm itself appears to be 2.66 GiB in size and was successfully downloaded into the UpdateVM.

Did anyone else run into this? Has anyone any ideas which of those partitions is lacking (how much) disk space?

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
 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.

1 Like

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 would ask: Which user group does this serve?

The standard template is for everyone.

The minimal template is for advanced users who want to tweak things.

Who is “core” for?

If “core” is also for everyone, why not make it standard (i.e., adjust the packages in the standard template to match what “core” would be)?

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.

It sounds like you’re thinking of this:

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.

@wind.gmbh: I’ve pushed newer flavors https://github.com/fepitre/qubes-template-kali/commit/43bb8afd98c84f22fb1a4f19883c01988d70518f

1 Like

Thanks a lot for the quick changes @fepitre

I have to hint that the default template root size will be exceeded by kali-linux-everything.

Template disk useage (compared to core)
kali-linux-core ± 0,0 GiB
kali-linux-default + 5,54 GiB
kali-linux-everything + 16,7 GiB

Something like

ifeq ($(TEMPLATE_FLAVOR), kali+everything)

could be necessary. (I do not think that many reasonable people use the everything installation; but in case there are any, this may be changed.)

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?

Unfortunately there’s no official build of the qubes-template-kali-core flavour. If you need it, you will have to build it yourself.

I will see to include it in the repo. Does anyone can create an issue on qubes-issues and link this thread please?

Hi fepitre,
I submitted an issue as requested