From 6f9a1d73430f3e2bf70acedd755069828e030cc1 Mon Sep 17 00:00:00 2001 From: qubedmaiska Date: Sun, 9 Mar 2025 15:57:38 -0400 Subject: [PATCH] formatting, valid url --- user/advanced-topics/salt.md | 6 +++--- user/templates/windows/windows-qubes-4-1.md | 11 ++++++++--- 2 files changed, 11 insertions(+), 6 deletions(-) diff --git a/user/advanced-topics/salt.md b/user/advanced-topics/salt.md index 0b5633de..1b0767f7 100644 --- a/user/advanced-topics/salt.md +++ b/user/advanced-topics/salt.md @@ -67,9 +67,9 @@ The lowest level is a single state function, called like this `state.single pkg.installed name=firefox-esr` When the system compiles data from sls formulas, it generates *chunks* - low chunks are at the bottom of the compiler . You can call them with -`state.low` +`state.low`. Next up is the *lowstate* level - this is the list of all low chunks in -order. - To see them you have `state.show_lowstate`, and use `state.lowstate` to apply them. +order. To see them you have `state.show_lowstate`, and use `state.lowstate` to apply them. At the top level is *highstate* - this is an interpretation of **all** the data represented in YAML in sls files. You can view it with `state.show_highstate`. @@ -219,7 +219,7 @@ Instead, to get this behavior, you would use a `do` statement. So you should take a look at the [Jinja API documentation](https://jinja.palletsprojects.com/templates/). Documentation about using Jinja to directly call Salt functions and get data about your system can be found in the official -[Salt documentation](https://docs.saltproject.io/en/getstarted/config/jinja.html#get-data-using-salt). +[Salt documentation](https://docs.saltproject.io/salt/user-guide/en/latest/topics/jinja.html). ## Salt Configuration, QubesOS layout diff --git a/user/templates/windows/windows-qubes-4-1.md b/user/templates/windows/windows-qubes-4-1.md index 09f13e5e..f2928a42 100644 --- a/user/templates/windows/windows-qubes-4-1.md +++ b/user/templates/windows/windows-qubes-4-1.md @@ -34,7 +34,7 @@ For better integration, a set of drivers and services, called Qubes Windows Tool ## Importing a Windows VM from an earlier version of Qubes -- Importing from R3.2 or earlier will not work, because Qubes R3.2 has the old stubdomain by default and this is preserved over backup and restore (as Windows otherwise won't boot. +- Importing from R3.2 or earlier will not work, because Qubes R3.2 has the old stubdomain by default and this is preserved over backup and restore (as Windows otherwise won't boot). - Importing from R4.0 should work, see [Migrate backups of Windows VMs created under Qubes R4.0 to R4.1](/doc/templates/windows/migrate-to-4-1). @@ -127,7 +127,12 @@ These parameters are set for the following reasons: - Disable direct boot so that the VM will go through the standard cdrom/HDD boot sequence. This is done by setting the qube's kernel to an empty value. - After creating the new qube, increase the VM's `qrexec_timeout`: in case you happen to get a BSOD or a similar crash in the VM, utilities like `chkdsk` won't complete on restart before `qrexec_timeout` automatically halts the VM. That can really put the VM in a totally unrecoverable state, whereas with higher `qrexec_timeout`, `chkdsk` or the appropriate utility has plenty of time to fix the VM. Note that Qubes Windows Tools also require a larger timeout to move the user profiles to the private volume the first time the VM reboots after the tools' installation. So set the parameter via the following CLI command from a dom0 terminal, because the Qube manager does not support this setting: + + ~~~ + qvm-prefs WindowsNew qrexec_timeout 7200 + ~~~ + **Start Windows VM** - The VM is now ready to be started; the best practice is to use an installation ISO [located in a VM](/doc/standalones-and-hvms/#installing-an-os-in-an-hvm). Now boot the newly created qube from the Windows installation media. In the Qubes Manager: @@ -164,7 +169,7 @@ These parameters are set for the following reasons: @@ -259,7 +264,7 @@ On starting the AppVM, sometimes a message is displayed that the Xen PV Network **Caution:** These AppVMs must not be started while the corresponding TemplateVM is running, because they share the TemplateVM's license data. Even if this could work sometimes, it would be a violation of the license terms. -Furthermore, if manual IP setup was used for the template, the IP address selected for the template will also be used for the AppVM, as it inherits this address from the template. Qubes, however, will have assigned a different address to the AppVM, which will have to changed to that of the template (e.g. 10.137.0.x) so that the AppVM can access the network, vis the CLI command in a dom0 terminal: +Furthermore, if manual IP setup was used for the template, the IP address selected for the template will also be used for the AppVM, as it inherits this address from the template. Qubes, however, will have assigned a different address to the AppVM, which will have to be changed to that of the template (e.g. 10.137.0.x) so that the AppVM can access the network, via the CLI command in a dom0 terminal: ~~~ qvm-prefs WindowsNew ip 10.137.0.x