mirror of
https://github.com/QubesOS/qubes-doc.git
synced 2024-12-20 21:24:39 -05:00
175 lines
5.6 KiB
ReStructuredText
175 lines
5.6 KiB
ReStructuredText
=================
|
||
Upgrading to R2B2
|
||
=================
|
||
|
||
|
||
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. While it is possible to upgrade the system **it is strongly recommended to reinstall it**. You will preserve all your data and
|
||
settings thanks to :doc:`backup and restore tools </user/how-to-guides/how-to-back-up-restore-and-migrate>`.
|
||
|
||
Upgrade all Template and Standalone VM(s)
|
||
-----------------------------------------
|
||
|
||
|
||
**If you have already R2 Beta1 installed, follow standard template update procedure (e.g. “Update VM” button in Qubes Manager) and skip the rest of this section**
|
||
|
||
By default, in Qubes R1, there is only one template, however users are
|
||
free to create more templates for special purposes, as well as
|
||
Standalone VMs. More information on using multiple templates, as well as
|
||
Standalone VMs, can be found :doc:`here </user/templates/templates>` and
|
||
:doc:`here </user/advanced-topics/standalones-and-hvms>`. The steps described in this section
|
||
should be repeated in *all* user’s Template and Standalone VMs.
|
||
|
||
1. Open terminal in the template (or standalone VM). E.g. use the Qubes
|
||
Manager’s right-click menu and choose Run Command in VM and type
|
||
``gnome-terminal`` there.
|
||
|
||
2. Install ``qubes-upgrade-vm`` package (this package brings in R2 repo
|
||
definitions and R2 keys)
|
||
|
||
.. code:: bash
|
||
|
||
sudo yum install qubes-upgrade-vm
|
||
|
||
|
||
|
||
3. Proceed with normal update in the template (this should bring in also
|
||
the R2 packages for the VMs):
|
||
|
||
.. code:: bash
|
||
|
||
sudo yum update
|
||
|
||
|
||
The installer (yum) will prompt to accept the new Qubes R2 signing
|
||
key:
|
||
|
||
.. code:: bash
|
||
|
||
Importing GPG key 0x0A40E458:
|
||
Userid : "Qubes OS Release 2 Signing Key"
|
||
Fingerprint: 3f01 def4 9719 158e f862 66f8 0c73 b9d4 0a40 e458
|
||
Package : qubes-upgrade-vm-1.0-1.fc17.x86_64 (@qubes-vm-current)
|
||
From : /etc/pki/rpm-gpg/RPM-GPG-KEY-upgrade-qubes-2-primary
|
||
Is this ok [y/N]:
|
||
|
||
|
||
If you see (as is the case on the “screenshot” above) that the new
|
||
key was imported from a local filesystem (``/etc/pki/rpm-gpg/...``)
|
||
you can safely accept the key, without checking its fingerprint. This
|
||
is because there were only two ways for such a key to make it to your
|
||
template’s filesystem:
|
||
|
||
|
||
|
||
- 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.
|
||
|
||
|
||
|
||
Installing new template
|
||
-----------------------
|
||
|
||
|
||
Qubes R2 Beta2 brings new fedora-18-x64 template (based on Fedora 18).
|
||
You can install it from Qubes installation DVD. Insert installation DVD
|
||
into your drive and issue following commands:
|
||
|
||
.. code:: bash
|
||
|
||
$ sudo -s
|
||
# mkdir -p /mnt/cdrom
|
||
# mount /dev/cdrom /mnt/cdrom # you can also use ISO image instead of /dev/cdrom; then add -o loop option
|
||
# yum install /mnt/cdrom/Packages/q/qubes-template-fedora-18-x64*rpm
|
||
# umount /mnt/cdrom
|
||
|
||
|
||
|
||
If you already have fedora-17-x64, you can also upgrade it to
|
||
fedora-18-x64 following `standard Fedora upgrade procedure <https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum>`__
|
||
(only “yum” method will work in Qubes VM).
|
||
|
||
Upgrade Dom0
|
||
------------
|
||
|
||
|
||
Be sure to do steps described in this section after *all* your template
|
||
and standalone VMs got updated as described in the section above.
|
||
|
||
1. Open terminal in Dom0. E.g. Start->System Settings->Konsole.
|
||
|
||
2. Upgrade the ``qubes-release`` package to the latest version which
|
||
brings in new repo definitions and R2 signing keys:
|
||
|
||
.. code:: bash
|
||
|
||
sudo qubes-dom0-update qubes-release
|
||
|
||
|
||
This should install ``qubes-release-1-6`` in your Dom0.
|
||
|
||
3. Install R2 upgrade package:
|
||
|
||
.. code:: bash
|
||
|
||
sudo qubes-dom0-update --releasever=1 qubes-dist-upgrade
|
||
|
||
|
||
|
||
4. Start upgrade process:
|
||
|
||
.. code:: bash
|
||
|
||
sudo qubes-dist-upgrade
|
||
|
||
|
||
|
||
5. Follow instructions on screen, first stage of upgrade should end up
|
||
with reboot request.
|
||
|
||
6. Reboot your system, ensure that you choose “Qubes Upgrade” boot
|
||
option.
|
||
|
||
7. When system starts up, login and start start
|
||
|
||
.. code:: bash
|
||
|
||
sudo qubes-dist-upgrade
|
||
|
||
|
||
again. This will start second stage of upgrade, here most packages
|
||
will be upgraded, so this will take a while.
|
||
|
||
8. You will be prompted to install new bootloader. If you haven’t
|
||
changed anything in this matter from initial installation, just
|
||
accept the default.
|
||
|
||
9. Reboot your system. System shutdown may hung because some running
|
||
system components no longer match that installed on disk; just wait
|
||
a few minutes and hard reset the system in such case.
|
||
|
||
10. This is end of upgrade process, you should now have Qubes R2 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.
|