It’s around 300 MiB.
1 Like
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
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?
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
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.
You can manage your system qubes through qvm-console-dispvm. Then xterm is running in a disposable, not in the service qube.
1 Like
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.
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.
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.
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.
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
I do not think this can have been confirmed because it is not true.
passwordless-root is not a requirement
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).
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
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.
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.
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.
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.
(Not sure if wiki edits are tracked by email).
I put this line, after the qvm-prefs part:
In this case,
qvm-runwill need to be run with the--no-guioption.
I was trying to run qvm-run without success and just found about this. I didn’t test what command is producing this exactly, it’s just a suspicion.
Yes, I noticed that too. Somehow I have missed to mention it. Thanks for the addition.
Another thing is that without guivm, qvm-copy/move from the qube won’t work without an allow policy in dom0. There is always “Request refused”, probably because no dialog can be displayed.
(Not sure if wiki edits are tracked by email).
AFAICS, they are not.