mirror of
https://github.com/QubesOS/qubes-doc.git
synced 2024-10-01 01:25:40 -04:00
Clean up Live USB page
This commit is contained in:
parent
1387751739
commit
4f76c47c7f
@ -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!
|
||||
|
Loading…
Reference in New Issue
Block a user