Git-Mirrors/qubes-doc
1
0
Fork 0
mirror of https://github.com/QubesOS/qubes-doc.git synced 2025-08-02 03:26:38 -04:00
Code Issues Projects Releases Packages Wiki Activity

pre-final fixes

Browse source
This commit is contained in:
qubedmaiska 2025-06-03 13:51:29 -04:00
parent 78654bf052
commit 524928b022
No known key found for this signature in database
GPG key ID: 204BCE0FD52C0501
20 changed files with 45 additions and 45 deletions
Download patch file Download diff file Expand all files Collapse all files

8
user/downloading-installing-upgrading/upgrade/2.md
View file

@ -34,7 +34,7 @@ Note that dom0 in R2 is based on Fedora 20, in contrast to Fedora 18 in previous
1. Open terminal in Dom0. E.g. Start-\>System Settings-\>Konsole.
1. Install all the updates for Dom0:
2. Install all the updates for Dom0:
~~~
sudo qubes-dom0-update
@ -42,7 +42,7 @@ Note that dom0 in R2 is based on Fedora 20, in contrast to Fedora 18 in previous
After this step you should have `qubes-release-2-5` in your Dom0. Important: if you happen to have `qubes-release-2-6*` then you should downgrade to `qubes-release-2-5`! The `qubes-release-2-6*` packages have been uploaded to the testing repos and were kept there for a few hours, until we realized they bring incorrect repo definitions and so we removed them and also have changed the update procedure a bit (simplifying it).
1. Upgrade dom0 to R2:
3. Upgrade dom0 to R2:
Note: be sure that the VM used as a update-downloading-vm (by default its the firewallvm based on the default template) has been updated to the latest Qubes packages, specifically `qubes-core-vm-2.1.33` or later. This doesn't imply that the VM must already be upgraded to fc20 -- for Dom0 upgrade we could still use an fc18-based VM (updatevm) it is only important to install the latest Qubes packages there.
@ -51,7 +51,7 @@ sudo qubes-dom0-update qubes-dom0-dist-upgrade
sudo qubes-dom0-update
~~~
1. If above step completed successfully you should have `qubes-release-2-9` or later. If not, repeat above step with additional `--clean` option.
4. If above step completed successfully you should have `qubes-release-2-9` or later. If not, repeat above step with additional `--clean` option.
4a. If you chose not to upgrade your fc18 templates, but instead to download our new fc20-based template you should now be able to do that by simply typing:
@ -59,6 +59,6 @@ sudo qubes-dom0-update
sudo qubes-dom0-update qubes-template-fedora-20-x64
~~~
1. Reboot the system.
5. Reboot the system.
Please note that if you use Anti Evil Maid, then it won't be able to unseal the passphrase this time, because the Xen, kernel, and initramfs binaries have changed. Once the system boots up again, you could reseal your Anti Evil Maid's passphrase to the new configuration. Please consult Anti Evil Maid documentation for explanation on how to do that.

4
user/downloading-installing-upgrading/upgrade/2b1.md
View file

@ -13,7 +13,7 @@ title: Upgrading to R2B1
**Note: Qubes R2 Beta 1 is no longer supported! Please install or upgrade to a newer Qubes R2.**
**Note: This page is kept for historical reasons only! Do not follow the instructions below'''**
**Note: This page is kept for historical reasons only! Do not follow the instructions below**
Existing users of Qubes R1 (but not R1 betas!) can upgrade their systems to the latest R2 beta release by following the procedure below. As usual, it is advisable to backup the system before proceeding with the upgrade
@ -51,7 +51,7 @@ By default, in Qubes R1, there is only one template, however users are free to c
- via a legitimate RPM package previously installed (in our case it was the `qubes-upgrade-vm` RPM). Such an RPM must have been signed by one of the keys you decided to trust previously, by default this would be either via the Qubes R1 signing key, or Fedora 17 signing key.
- via system compromise or via some illegal RPM package (e.g. Fedora released package pretending to bring new Firefox). In that case, however, your VM is already compromised, and it careful checking of the new R2 key would not change this situation to any better one. The game is lost for this VM anyway (and all VMs based on this template).
1. Shut down the VM.
4. Shut down the VM.
Upgrade Dom0
------------

2
user/downloading-installing-upgrading/upgrade/2b2.md
View file

@ -49,7 +49,7 @@ By default, in Qubes R1, there is only one template, however users are free to c
- via a legitimate RPM package previously installed (in our case it was the `qubes-upgrade-vm` RPM). Such an RPM must have been signed by one of the keys you decided to trust previously, by default this would be either via the Qubes R1 signing key, or Fedora 17 signing key.
- via system compromise or via some illegal RPM package (e.g. Fedora released package pretending to bring new Firefox). In that case, however, your VM is already compromised, and it careful checking of the new R2 key would not change this situation to any better one. The game is lost for this VM anyway (and all VMs based on this template).
1. Shut down the VM.
4. Shut down the VM.
Installing new template
-----------------------

2
user/downloading-installing-upgrading/upgrade/3_0.md
View file

@ -101,7 +101,7 @@ Be sure to do steps described in this section after *all* your template and stan
6. Reboot the system.
It may happen that the system hang during the reboot. Hard reset the system in such case, all the filesystems are unmounted at this stage.
- It may happen that the system hang during the reboot. Hard reset the system in such case, all the filesystems are unmounted at this stage.
Please note that if you use Anti Evil Maid, then it won't be able to unseal the passphrase this time, because the Xen, kernel, and initramfs binaries have changed. Once the system boots up again, you could reseal your Anti Evil Maid's passphrase to the new configuration. Please consult Anti Evil Maid documentation for explanation on how to do that.

10
user/downloading-installing-upgrading/upgrade/3_2.md
View file

@ -29,13 +29,13 @@ by following the procedure below.
sudo qubes-dom0-update --releasever=3.2 qubes-release
```
If you made any manual changes to repository definitions, new definitions
- If you made any manual changes to repository definitions, new definitions
will be installed as `/etc/yum.repos.d/qubes-dom0.repo.rpmnew` (you'll see
a message about it during package installation). In such a case, you need
to manually apply the changes to `/etc/yum.repos.d/qubes-dom0.repo` or
simply replace it with .rpmnew file.
If you are using Debian-based VM as UpdateVM (`sys-firewall` by default),
- If you are using Debian-based VM as UpdateVM (`sys-firewall` by default),
you need to download few more packages manually, but **do not install
them** yet:
@ -60,7 +60,7 @@ by following the procedure below.
sudo qubes-dom0-update
```
You may wish to disable the screensaver "Lock screen" feature for this step, as
- You may wish to disable the screensaver "Lock screen" feature for this step, as
during the update XScreensaver may encounter an "Authentication failed" issue,
requiring a hard reboot. Alternatively, you may simply move the mouse regularly.
@ -70,7 +70,7 @@ by following the procedure below.
6. Update configuration files.
Some of configuration files were saved with `.rpmnew` extension as the
- Some of configuration files were saved with `.rpmnew` extension as the
actual files were modified. During upgrade, you'll see information about
such cases, like:
@ -78,7 +78,7 @@ by following the procedure below.
warning: /etc/salt/minion.d/f_defaults.conf created as /etc/salt/minion.d/f_defaults.conf.rpmnew
```
This will happen for every configuration you have modified manually and for
- This will happen for every configuration you have modified manually and for
a few that has been modified by Qubes scripts. If you are not sure what to
do about them, below is a list of commands to deal with few common cases
(either keep the old one, or replace with the new one):