Minifying debian-12-minimal

Community Guides
1

Hi,

Recently, I found a way to reduce debian-12-minimal template even more, so I thought I should share the info for those who may consider it useful. Here is how to do it.

Packages

It is possible to remove the following non-essential packages (apt-get autopurge them):

aptitude
cpio
cron
cron-daemon-common
debconf-i18n
eatmydata
fdisk
gnupg
gpgv
haveged
ifupdown
iproute2
iputils-ping
isc-dhcp-client
isc-dhcp-common
less
libbpf1
libcap2-bin
libglib2.0-bin
libglib2.0-data
libjansson4
libmnl0
libnewt0.52
libnftables1
libnftnl11
libregexp-ipv6-perl
libtext-charwidth-perl
libxtables12
logrotate
mawk
nano
netbase
nftables
perl
perl-modules-5.36
tasksel
vim-common
vim-tiny
whiptail
xterm

After that, the administrative tasks, e.g. installing software, can be done through qvm-console-dispvm.

It is important to note that if the template will be used for networking AppVMs, netbase must be installed (qubes-core-agent-networking will not work without it). It is not required in the template itself (for package installation).

Reduce RAM usage

For non-networked qubes, it is also possible to deactivate unnecessary network services:

root@debian-12-mini: systemctl mask systemd-networkd.service
root@debian-12-mini: systemctl mask systemd-networkd.socket
root@debian-12-mini: systemctl mask systemd-networkd-wait-online.service

For headless service VMs, which don’t need audio or graphics stuff, disable audiovm and guivm:

user@dom0: qvm-prefs <your-qube> audiovm ''
user@dom0: qvm-prefs <your-qube> guivm ''

In this case, qvm-run will need to be run with the --no-gui option.

Additionally, you can even disable unused kernel modules, e.g. sound-related:

root@debian-12-mini: cat << EOF | tee /etc/modprobe.d/blacklist.conf
blacklist snd
blacklist snd_pcm
blacklist snd_timer
blacklist soundcore
blacklist pcspkr
blacklist snd_pcsp
EOF

The result

After rebooting the template, its RAM usage is 144 MiB only.
The AppVMs use about 100 MiB more.

9 Likes
2

Do you have the RAM usage of the stock debian-12-minimal template?

Is this the RAM usage for the non-network version?

3

It’s around 300 MiB.

1 Like
4

Do you have the RAM usage of the stock debian-12-minimal template?

232 MiB.

Is this the RAM usage for the non-network version?

Yes.

According to top, xorg eats the most RAM, so removing the guivm is the most significant RAM reduction.

1 Like
5

I tried this on a minimal template I use to manage external disks. I think I only kept fdisk.

With the original template free -h shows 265Mi used memory and with the cloned one: 202Mi. Seems quite good to me! Thanks!

Just curious, how did you select those packages?

6

Just curious, how did you select those packages?

I ran a loop to check the dependencies of each installed package. After that, I tested the effect of removing each package which was not a reverse dependency to qubes/xen packages. After removing each group, I rebooted the template qube and checked journalctl -b. The ones in the list are those whose removal don’t seem to break anything.

I also checked ReduceDebian - Debian Wiki

5 Likes
7

I’m thinking this could be useful for what I call “system” qubes as opposed to “app” qubes. (I’m not sure anyone else makes that distinction, at least not in the same way.) System qubes basically do the low level gruntwork and include things like sys-usb, sys-net-wifi, etc. and I rarely have occasion to do anything other than start them up and let them do their thing. App qubes, on the other hand, have a slightly higher role or I will do actual end-user work on.

For my purposes here the distinction is that system qubes don’t have a file manager on them, while app qubes do. Although I build all of them (except for Windows) on debian-12-minimal (either directly or indirectly), obviously app qubes will have more stuff on them.

I am going to put “playing with this” for system qubes on my to do list. As long as this stripped down list will still support an xterm window in seamless mode, it should be good.

8

You can manage your system qubes through qvm-console-dispvm. Then xterm is running in a disposable, not in the service qube.

1 Like
9

I’ve never been able to figure out how that’s supposed to be of any use.

It fires up a totally new disposable, so it’s NOT running in the qube in question.

It never prompts me for a command and it doesn’t respond to anything I type.

I guess it’s an improvement over the old one, which would demand a password.

10

There’s something up here - you should see the console messages for the
target qube, and be able to log in as root.
I’d suggest you open a separate thread for the issue, giving some
information about what template you are using for the default
disposable, so we can get to the bottom of your issue. If it’s a bug we
can then fix it.

11

The next problem is (from back when it worked as you described) it wouldn’t let me do anything without a password.

I don’t recall ever setting one and passwordless sudo means that if I ever did do so it’s long since forgotten.

As for the rest, most of my qubes don’t have default dispvms set (what’s the point of being able to open a file in a disposable, in a qube which will never do so?). Even on ones where such a template is set, it’s not the one that gets used, instead it’s going to the disposable template for the manager qube (the one that manages updates). That in turn is based on a template, that is based on debian-12-minimal.

12

I just cloned debian-12-minimal to experiment. I can’t even delete the files, because I have no freaking idea what root’s password is (passwordless sudo is not installed on debian-12-minimal by default).

I hope you saw my prior response (it doesn’t show as a reply to you on the page, though I am pretty sure I did so). Just in case you didn’t I’ll quote it.

13

@SteveC

If you disable the guivm, you cannot run xterm (or anything X related) in that qube, so there is no need for xterm at all. Hence the suggestion to use qvm-console-dispvm.

qvm-console-dispvm runs xterm in a DispVM based on management_dispvm (default-mgmt-dvm), i.e. not on default_dispvm (which you have set to none).

It has been confirmed that default-mgmt-dvm (its template, to be precise) must have passwordless root installed, i.e. qubes-core-agent-passwordless-root package.

Is it possible that your default-mgmt-dvm’s template does not have passwordless root, which probably results in what you described?

1 Like
14

I do not think this can have been confirmed because it is not true.
passwordless-root is not a requirement

15

I do not think this can have been confirmed because it is not true.

It was confirmed in the post I linked to and in the documentation too. That’s all I know.

passwordless-root is not a requirement

Then the documentation needs correction. I hope you can clarify this matter in the other thread (as it is the reason it was started).

16

Considering the goal of minimal templates, it seems a good idea to disable non-DFSG-compliant software by default for security reasons:

https://www.debian.org/security/faq#contrib

This leaves only main component:

sed -ri 's/(^deb(-src)?\s+https:\S+\s+\S+)(.*)/\1 main/g' /etc/apt/sources.list
17

OK that may or may not explain a few things.

First off, qubes-core-agent-passwordless-root gets installed in my “sys-base” template, which is cloned from debian-12-minimal, and everything else (other than windows) derives from it. So, default-mgmt-dvm (actually deb12m-disp-mgmt in my case) has it. In fact, that salt script references it again. (I guess I can remove that; it’s redundant.) [Yes, I built my management dvm off a minimal template instead of continuing to base it on debian-12-xfce.]

My difficulty in the present case, of course, could be explained by the fact that in order to experiment, I started with a fresh, untouched clone of debian-12-minimal (which I named debian-12-reduced) and attempted to uninstall everything in your list. debian-12-reduced, of course, won’t have qubes-core-agent-passwordless-root on it, so of course I couldn’t install anything without a password…whatever that password might be. [OR: I could write a salt state to do the removal.]

Of course I’m still dealing with a broken console, and not just on this qube, but others, ones where I know qubes-core-agent-passwordless-root is installed.

I’m not terribly motivated to care about the broken console, because it has in my experience always been broken/useless one way or another (either demanding a password or just being a dead window as described above), so I’ve learned to live without it, and just use xterms.

18

You have reported other strange dysfunctional things, specific to your system, in other threads, so I don’t really know how to help you. In such situations, it might be a good idea to recreate your whole setup from scratch and see if the particular issues persist. If they do - there may be a problem with the set up procedure. Logs are your friend.

19

passwordless-root is a requirement for the management disposable when
used for salt, and otherwise as intended.
It is not a requirement for use of qvm-console-dispvm .

So, if, as was the aim in that thread, users dispense with salt and are
effectively only using the disposable for qvm-console-dispvm,
passwordless root is not required.

20

Thanks for clarifying!

It would be good if we had this in the docs as well. There is practically zero user documentation about the management disposable.