I’m currently working on setting up my VMs. The only issues so far are a few errors in the logs, which I mentioned before. Unfortunately I can not determine if there is some critical problem amongst them. Maybe some kind of Rule It Out list of log errors with a short explanation what this might generally mean and why it therefore is not a big problem would be good addition for the docs. Sometimes Google does not have much to tell about them. I have seen a few threads with people having questions about errors and maintainers saying that logs were unrelated on GitHub. This could also be turned into a little command line tool to remove these lines from log files. Inspired by GreyNoise RIOT.
An additional error is qmemman reporting domain '(number)' still hold more memory than have assigned. I see very few things about this on GitHub. One report was related to issues starting a VM with a high amount of RAM assigned. I did it and I don’t have any problem I could pinpoint. Also I think qmemman is checking in on the RAM quite often if I am not mistaken and the error is being reported one single time once in a while (mostly on VM starts) and not spammed without end, so I would conclude this might not be a real issue. My fingers are crossed that I will not run into any real issues after setting up my remaining VMs and using them for a couple of weeks.
Maybe someone sees this thread looking for a particular error or word mentioned here, so I would like to document something that took more work than it needs to in my mind: Setting up the system without the initial setup GUI while not clicking ‘Quit’ and opening it again after booting. I don’t think I saw all the salts in the documentation to accomplish this.
Setting up default VMs with salt
The interesting files for this are:
The first file shows you which condition must be met for the tasks in the second file to be added to queue and run. I setup a system with only the templates being downloaded and the VM pool being created by the initial setup. While the above files are code, I think it is easy to follow along to setup your desired configuration.
After tasks = [], look for tasks being added to the list and the condition for this. In the other file, you will pretty much see the exact commands being executed.
The DefaultKernelTask is always being executed and I have my pool already, so I skipped these. Same for the templates. @Query this task is for you though: InstallTemplateTask. You can also just use the Qubes Template Manager GUI in 4.2 or read the documentation for this: Templates | Qubes OS
Skipping CleanTemplatePkgsTask and ConfigureDom0Task as these are always executed. If you fail at a very early stage though, you obviously would want to execute these too. It might make sense to just read through them all and verify the changes were made.
Execute command in SetDefaultTemplateTask, self-explaining again.
ConfigureDefaultQubesTask is slightly more complicated and depends on your desired outcome. Begin by running qubesctl saltutil.clear_cache and qubesctl saltutil.sync_all. Then (in the code) salt configurations will be added to the states list depending on the checkbox in the installer. I think the conditions are mostly self-explaining. There is a bit more code involved here now.
If qvm.sys-net is being added to the list, you would execute qubesctl top.enable qvm.sys-net. If the entry added to the states list is prefixed with pillar., you remove this and execute the command I just listed and append pillar=True to it. Let’s say you want a disposable sys-net VM and therefore see pillar.qvm.disposable-sys-firewall being added to the state list, the command would become qubesctl top.enable qvm.disposable-sys-firewall pillar=True. Afterwards, let salt configure all these enabled states by executing qubesctl --all state.highstate.
You then should disable all the states that you did not suffix with pillar=True again by executing qubesctl top.disable followed by the state.
After that, just follow along with the code and execute the commands. Now you have manually setup the default Qubes configuration. Again, I didn’t see quite a few of these anywhere in the docs. I think this is quite important as you can not setup Qubes with a problematic PCI device without this if I am not mistaken.
By the way, I think this check is incomplete: https://github.com/QubesOS/qubes-anaconda-addon/blob/4bdce79a6bcb28eff844601aebdb000dc8fc0019/org_qubes_os_initial_setup/service/tasks.py#L308C17-L308C33
If you don’t setup any default VM as I did, there is no default-dvm so this fails. The check should also include a condition making sure the first checkbox for default VMs including the default disposable VM is checked. While I think it doesn’t matter as the next steps are mostly related to the missing default Qubes, it is very irritating considering that users are looking for a bit of a peace of mind when using a security OS like this and ruling out errors displayed to you as sources for potential harm to that can take quite a bit of time if you have the technical means to do so at all.
@catacombs
No dual boot, I just have the old drive in the computer to copy over data from the previous installation from a different device once time has come.