diff --git a/installing/live-usb.md b/installing/live-usb.md index d341a1de..6ff73d63 100644 --- a/installing/live-usb.md +++ b/installing/live-usb.md @@ -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!