Clean up Live USB page

This commit is contained in:
Axon 2015-12-13 01:51:22 +00:00
parent 1387751739
commit 4f76c47c7f
No known key found for this signature in database
GPG Key ID: 8CE137352A019A17

View File

@ -20,17 +20,15 @@ We have faced several challenges when making this Live USB edition of Qubes OS,
which traditional Linux distros don't have to bother with:
1. We needed to ensure Xen is properly started when booting the stick. In fact
we still don't support UEFI boot for the sitck for this reason, even though the
Fedora liveusb creator we used does support it. Only legacy boot for this
version, sorry.
we still don't support UEFI boot for the sitck for this reason, even though
the Fedora liveusb creator we used does support it. Only legacy boot for this
version, sorry.
2. We discovered that the Fedora liveusb-create does *not* verify signatures on
downloaded packages. We have temporarily fixed that by creating a local repo,
verifying the signatures manually (ok, with a script ;) and then building from
there. Sigh.
3. We had to solve the problem of Qubes too easily triggering an `Out Of Memory`
condition in Dom0 when running as Live OS.
downloaded packages. We have temporarily fixed that by creating a local repo,
verifying the signatures manually (ok, with a script ;) and then building
from there. Sigh.
3. We had to solve the problem of Qubes too easily triggering an Out Of Memory
condition in Dom0 when running as Live OS.
This last problem has been a result of Qubes using the copy-on-write backing for
the VMs' root filesystems, which is used to implement our cool
@ -52,55 +50,50 @@ Now, there are three directions in how we want to work further on this Qubes
Live USB variant:
1. Introduce an easy, clickable "install to disk" option, merging this with the
Qubes installation ISO. So, e.g. make it possible to first see if the given
hardware is compatible with Qubes (run the HCL reporting tool) and only then
install on the main disk. Also, ensure UEFI boot works well.
Qubes installation ISO. So, e.g. make it possible to first see if the given
hardware is compatible with Qubes (run the HCL reporting tool) and only then
install on the main disk. Also, ensure UEFI boot works well.
2. Introduce options for persistence while still running this out of a USB
stick. This would be achieved by allowing (select) VMs' private images to be
stored on the r/w partition (or on another stick).
stick. This would be achieved by allowing (select) VMs' private images to be
stored on the r/w partition (or on another stick).
2a. A nice variant of this persistence option, especially for frequent
travellers, I think, would be to augment our backup tools so that it was
possible to create a LiveUSB-hosted backups of select VMs. One could then pick a
few of their VMs, necessary for a specific travel, back them to a LiveUSB stick,
and take this stick when traveling to a hostile country (not risking taking
other, more sensitive ones for the travel). This should make life a bit simpler
[for some...](https://twitter.com/rootkovska/status/541980196849872896)
A nice variant of this persistence option, especially for frequent
travellers, would be to augment our backup tools so that it was
possible to create a LiveUSB-hosted backups of select VMs. One could then
pick a few of their VMs, necessary for a specific travel, back them to a
LiveUSB stick, and take this stick when traveling to a hostile country (not
risking taking other, more sensitive ones for the travel). This should make
life a bit simpler
[for some](https://twitter.com/rootkovska/status/541980196849872896).
3. Introduce more useful preconfigured VMs setup, especially including
Whonix/Tor VMs.
Whonix/Tor VMs.
Current limitations
-------------------
0. It's considered an alpha currently, so meter your expectations
accordingly...
(Remember that Qubes Live USB is currently in alpha, so please meter your
expectations accordingly.)
1. Currently just the 3 example VMs (untrusted, personal, work), plus the
default net and firewall VMs are created automatically.
default net and firewall VMs are created automatically.
2. The user has an option to manually (i.e. via command line) create an
additional partition, e.g. for storing GPG keyring, and then mounting it to a
select VMs. This is to add poor-man's persistence. We will be working on
improving/automating that, of course.
additional partition, e.g. for storing GPG keyring, and then mounting it to a
select VMs. This is to add poor-man's persistence. We will be working on
improving/automating that, of course.
3. Currently there is no option of "install to disk". We will be adding this
in the future.
in the future.
4. The amount of "disk" space is limited by the amount of RAM the laptop
has. This has a side effect of e.g. not being able to restore (even few) VMs
from a large Qubes backup blob.
has. This has a side effect of e.g. not being able to restore (even few) VMs
from a large Qubes backup blob.
5. It's easy to generate Out Of Memory (OOM) in Dom0 rather easily by creating
lots of VMs which are writing a lot into the VMs filesystem.
lots of VMs which are writing a lot into the VMs filesystem.
6. There is no DispVM savefile, so if one starts one the savefile must be
regenerated which takes about 1-2 minutes.
regenerated which takes about 1-2 minutes.
7. UEFI boot doesn't work, and if you try booting it via UEFI Xen will not be
started, rendering the whole experiment unusable.
started, rendering the whole experiment unusable.
Downloading and burning
@ -108,15 +101,14 @@ Downloading and burning
1. Download the ISO (and its signature for verification) from the
[downloads page](/downloads/#qubes-live-usb-alpha/).
2. "Burn" (copy) the ISO onto a USB drive (replace `/dev/sdX` with your USB
drive device):
$ sudo dd if=Qubes-R3.0-rc2-x86_64-LIVE.iso of=/dev/sdX
$ sudo dd if=Qubes-R3.0-rc2-x86_64-LIVE.iso of=/dev/sdX
Note that you should specify the whole device, (e.g. `/dev/sdc`, not a single
partition, e.g. `/dev/sdc1`).
Note that you should specify the whole device, (e.g. `/dev/sdc`, not a single
partition, e.g. `/dev/sdc1`).
**Caution:** It is very easy to misuse the `dd` command. If you mix up `if` and
`of` or specify an incorrect device, you could accidentally overwrite your
primary system drive. Please be careful!
**Caution:** It is very easy to misuse the `dd` command. If you mix up `if`
and `of` or specify an incorrect device, you could accidentally overwrite
your primary system drive. Please be careful!