mirror of
https://github.com/QubesOS/qubes-doc.git
synced 2024-12-25 15:29:29 -05:00
more minor typo/grammar fixes
This commit is contained in:
Miguel Jacq
parent
db13ef5a33
commit
2f369c1309
@ -419,7 +419,7 @@ Remember to also import gpg public key using `rpm --import`.
|
||||
|
||||
### Deb packages - Apt repo
|
||||
|
||||
Steps are mostly the same as in case of yum repo. Only details differs:
|
||||
Steps are mostly the same as in the case of yum repo. The only details that differ:
|
||||
|
||||
- use [linux-deb] instead of [linux-yum] as a base - both in source and target VM
|
||||
- use different `update_repo.sh` script in source VM (below)
|
||||
|
||||
@ -33,8 +33,8 @@ Variables for Windows build:
|
||||
- `WIN_SIGN_CMD` Command used to sign resulting binaries. Note that default value is *sign.bat*. If you don't want to sign binaries, specify some placeholder here (eg. *true*). Check existing components (eg. vmm-xen-windows-pvdrivers) for example scripts. This command will be run with certain environment variables:
|
||||
- `CERT_FILENAME` Path to key file (pfx format)
|
||||
- `CERT_PASSWORD` Key password
|
||||
- `CERT_PUBLIC_FILENAME` Certificate path in case of self-signed cert
|
||||
- `CERT_CROSS_CERT_FILENAME` Certificate path in case of correct autheticode cert
|
||||
- `CERT_PUBLIC_FILENAME` Certificate path in the case of self-signed cert
|
||||
- `CERT_CROSS_CERT_FILENAME` Certificate path in the case of correct autheticode cert
|
||||
- `SIGNTOOL` Path to signtool
|
||||
- `WIN_PACKAGE_CMD` Command used to produce installation package (msi or msm). Default value is *wix.bat*, similar to above - use *true* if you don't want this command.
|
||||
- `WIN_OUTPUT_HEADERS` Directory (relative to `WIN_SOURCE_SUBDIRS` element) with public headers of the package - for use in other components.
|
||||
|
||||
@ -33,7 +33,7 @@ What about applications in DispVMs?
|
||||
Behind the scenes
|
||||
-----------------
|
||||
|
||||
The list of installed applications for each AppVM is stored in dom0's `/var/lib/qubes/vm-templates/templatename/apps.templates` (or in case of StandaloneVM: `/var/lib/qubes/appvms/vmname/apps.templates`). Each menu entry is a file that follows the [.desktop file format](https://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html) with some wildcards (*%VMNAME%*, *%VMDIR%*). Applications selected to appear in the menu are stored in `/var/lib/qubes/appvms/vmname/apps`.
|
||||
The list of installed applications for each AppVM is stored in dom0's `/var/lib/qubes/vm-templates/templatename/apps.templates` (or in the case of StandaloneVM: `/var/lib/qubes/appvms/vmname/apps.templates`). Each menu entry is a file that follows the [.desktop file format](https://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html) with some wildcards (*%VMNAME%*, *%VMDIR%*). Applications selected to appear in the menu are stored in `/var/lib/qubes/appvms/vmname/apps`.
|
||||
|
||||
Actual command lines for the menu shortcuts involve `qvm-run` command which starts a process in another domain. Examples: `qvm-run -q --tray -a w7s 'cmd.exe /c "C:\\ProgramData\\Microsoft\\Windows\\Start Menu\\Programs\\Accessories\\Calculator.lnk"'` or `qvm-run -q --tray -a untrusted 'firefox %u'`
|
||||
Note that you can create a shortcut that points to a .desktop file in your AppVM with e.g. `qvm-run -q --tray -a personal -- 'qubes-desktop-run /home/user/application.desktop'`
|
||||
|
||||
@ -204,7 +204,7 @@ Note on treating AppVM's root filesystem non-persistency as a security feature
|
||||
|
||||
As explained above, any AppVM that is based on a Template VM (i.e. which is not a Standalone VM) has its root filesystem non-persistent across the VM reboots. In other words whatever changes the VM makes (or the malware running in this AppVM makes) to its root filesystem, are automatically discarded whenever one restarts the AppVM. This might seem like an excellent anti-malware mechanism to be used inside the AppVM...
|
||||
|
||||
However, one should be careful with treating this property as a reliable way to keep the AppVM malware-free. This is because the non-persistency, in case of normal AppVMs, applies only to the root filesystem and not to the user filesystem (on which the `/home`, `/rw`, and `/usr/local` are stored) for obvious reasons. It is possible that malware, especially malware that could be specifically written to target a Qubes-based AppVMs, could install its hooks inside the user home directory files only. Examples of obvious places for such hooks could be: `.bashrc`, the Firefox profile directory which contains the extensions, or some PDF or DOC documents that are expected to be opened by the user frequently (assuming the malware found an exploitable bug in the PDF or DOC reader), and surely many others places, all in the user's home directory.
|
||||
However, one should be careful with treating this property as a reliable way to keep the AppVM malware-free. This is because the non-persistency, in the case of normal AppVMs, applies only to the root filesystem and not to the user filesystem (on which the `/home`, `/rw`, and `/usr/local` are stored) for obvious reasons. It is possible that malware, especially malware that could be specifically written to target a Qubes-based AppVMs, could install its hooks inside the user home directory files only. Examples of obvious places for such hooks could be: `.bashrc`, the Firefox profile directory which contains the extensions, or some PDF or DOC documents that are expected to be opened by the user frequently (assuming the malware found an exploitable bug in the PDF or DOC reader), and surely many others places, all in the user's home directory.
|
||||
|
||||
One advantage of the non-persistent rootfs though, is that the malware is still inactive before the user's filesystem gets mounted and "processed" by system/applications, which might theoretically allow for some scanning programs (or a skilled user) to reliably scan for signs of infections of the AppVM. But, of course, the problem of finding malware hooks in general is hard, so this would work likely only for some special cases (e.g. an AppVM which doesn't use Firefox, as otherwise it would be hard to scan the Firefox profile directory reliably to find malware hooks there). Also note that the user filesystem's metadata might got maliciously modified by malware in order to exploit a hypothetical bug in the AppVM kernel whenever it mounts the malformed filesystem. However, these exploits will automatically stop working (and so the infection might be cleared automatically) after the hypothetical bug got patched and the update applied (via template update), which is an exceptional feature of Qubes OS.
|
||||
|
||||
|
||||
@ -307,7 +307,7 @@ steps:
|
||||
brackets by `qvm-block` command
|
||||
* `phy:/dev/sda` - physical path at which device appears in source qube
|
||||
(just after source qube name in `qvm-block` output)
|
||||
* `backend=sys-usb` - name of source qube, can be omitted in case of dom0
|
||||
* `backend=sys-usb` - name of source qube, can be omitted in the case of dom0
|
||||
* `xvdi` - "frontend" device name (listed at the end of line in `qvm-block`
|
||||
output)
|
||||
|
||||
|
||||
@ -144,7 +144,7 @@ possible to use VM kernel, which is not packaged by Qubes team. This includes:
|
||||
|
||||
To prepare such VM kernel, you need to install `qubes-kernel-vm-support`
|
||||
package in dom0 and also have matching kernel headers installed (`kernel-devel`
|
||||
package in case of Fedora kernel package). You can install required stuff using `qubes-dom0-update`:
|
||||
package in the case of Fedora kernel package). You can install required stuff using `qubes-dom0-update`:
|
||||
|
||||
~~~
|
||||
[user@dom0 ~]$ sudo qubes-dom0-update qubes-kernel-vm-support kernel-devel
|
||||
@ -326,7 +326,7 @@ When starting the VM you can safely ignore any warnings about a missing module '
|
||||
|
||||
### Troubleshooting
|
||||
|
||||
In case of problems, you can access VM console (using `sudo xl console VMNAME` in dom0) to access
|
||||
In the event of a problem, you can access VM console (using `sudo xl console VMNAME` in dom0) to access
|
||||
GRUB menu. You need to call it just after starting VM (until `GRUB_TIMEOUT`
|
||||
expires) - for example in separate dom0 terminal window.
|
||||
|
||||
|
||||
@ -8,7 +8,7 @@ redirect_from:
|
||||
|
||||
# How to make any file in a TemplateBasedVM persistent using bind-dirs #
|
||||
|
||||
## What is bind-dirs? ##
|
||||
## What are bind-dirs? ##
|
||||
|
||||
With [bind-dirs](https://github.com/QubesOS/qubes-core-agent-linux/blob/master/vm-systemd/bind-dirs.sh)
|
||||
any arbitrary files or folders can be made persistent in TemplateBasedVMs.
|
||||
@ -49,7 +49,7 @@ Multiple entries are possible, each on a separate line.
|
||||
|
||||
6. Done.
|
||||
|
||||
If you added for example folder `/var/lib/tor` to the `binds` variable, from now any files within that folder would persist reboots. If you added for example file `/etc/tor/torrc` to the `binds` variable, from now any modifications to that file would persist reboots.
|
||||
If you added for example folder `/var/lib/tor` to the `binds` variable, from now on any files within that folder will persist reboots. If you added for example file `/etc/tor/torrc` to the `binds` variable, from now on any modifications to that file will persist reboots.
|
||||
|
||||
## Other Configuration Folders ##
|
||||
|
||||
@ -89,7 +89,7 @@ For example, if you wanted to make `/var/lib/tor` non-persistant in `sys-whonix`
|
||||
binds=( "${binds[@]/'/var/lib/tor'}" )
|
||||
~~~
|
||||
|
||||
(Editing `/usr/lib/qubes-bind-dirs.d/40_qubes-whonix.conf` directly is recommended against, since such changes get lost when that file is changed in the package on upgrades.)
|
||||
(Editing `/usr/lib/qubes-bind-dirs.d/40_qubes-whonix.conf` directly is not recommended, since such changes get lost when that file is changed in the package on upgrades.)
|
||||
|
||||
## Discussion ##
|
||||
|
||||
|
||||
@ -70,7 +70,7 @@ This is the result after applying the steps described here.
|
||||
|
||||
|
||||
|
||||
**Note:** Chaning the `Window Decorations` from `Plastik for Qubes` will remove the border color and the VM name. The problem with `Plastik for Qubes` is, that it does not overwrite the background and text color for Minimize, Maximize and Close buttons. The three button are therefor hard to read.
|
||||
**Note:** Changing the `Window Decorations` from `Plastik for Qubes` will remove the border color and the VM name. The problem with `Plastik for Qubes` is, that it does not overwrite the background and text color for Minimize, Maximize and Close buttons. The three button are therefore hard to read.
|
||||
|
||||
Dark XCFE in Dom0
|
||||
-----------------
|
||||
@ -109,7 +109,7 @@ This is the result after applying the steps described here.
|
||||
Dark App VM, Template VM, Standalone VM, HVM (Linux Gnome)
|
||||
==========================================================
|
||||
|
||||
Almost all Qubes VM's are based on the Gnome desktop. Therefor the description below is focused on the Gnome Desktop Environment.
|
||||
Almost all Qubes VM's are based on the Gnome desktop. Therefore the description below is focused on the Gnome Desktop Environment.
|
||||
|
||||
Using "Gnome-Tweak-Tool"
|
||||
------------------------
|
||||
@ -120,7 +120,7 @@ The advantage of creating a dark themed Template VM is, that each AppVM which is
|
||||
|
||||
1. Start VM
|
||||
|
||||
**Note:** In case of App VM start the Template on which the AppVM is based on.
|
||||
**Note:** In the case of App VM start the Template on which the AppVM is based on.
|
||||
|
||||
2. Install `Gnome-Tweak-Tool`
|
||||
|
||||
@ -174,7 +174,7 @@ Manually works for Debian, Fedora and Archlinux.
|
||||
|
||||
1. Start VM
|
||||
|
||||
**Note:** In case of App VM start the Template on which the AppVM is based on.
|
||||
**Note:** In the case of App VM start the Template on which the AppVM is based on.
|
||||
|
||||
2. Enable `Global Dark Theme`
|
||||
|
||||
|
||||
@ -49,7 +49,7 @@ It is possible to change the settings of each new Disposable VM (DispVM). This c
|
||||
2. Change the VM's settings and/or applications, as desired. Note that currently Qubes supports exactly one DispVM template, so any changes you make here will affect all DispVMs. Some examples of changes you may want to make include:
|
||||
- Changing Firefox's default startup settings and homepage.
|
||||
- Changing Nautilus' default file preview settings.
|
||||
- Changing the DispVM's default NetVM. For example, you may wish to set the NetVM to "none." Then, whenever you start a new DispVM, you can choose your desired ProxyVM manually (by changing the newly-started DipsVMs settings). This is useful if you sometimes wish to use a DispVM with a TorVM, for example. It is also useful if you sometimes wish to open untrusted files in a network-disconnected DispVM.
|
||||
- Changing the DispVM's default NetVM. For example, you may wish to set the NetVM to "none." Then, whenever you start a new DispVM, you can choose your desired ProxyVM manually (by changing the newly-started DispVMs settings). This is useful if you sometimes wish to use a DispVM with a TorVM, for example. It is also useful if you sometimes wish to open untrusted files in a network-disconnected DispVM.
|
||||
|
||||
3. Create an empty `/home/user/.qubes-dispvm-customized` file in the VM (not in dom0):
|
||||
|
||||
|
||||
@ -17,7 +17,7 @@ Template installation
|
||||
|
||||
*Note*: the template may not start in Qubes R3 when using kernel 3.19 (unstable). In this case, switch the AppVM or TemplateVM to the kernel 3.18.
|
||||
|
||||
*Note*: If you have doubts about a set of tool or package you want to install, start installing and testing it in an AppVM. You can then reproduce it later in your TemplateVM if you are satisfied. That the (QubesOS?) template philosophy.
|
||||
*Note*: If you have doubts about a set of tools or package you want to install, start installing and testing it in an AppVM. You can then reproduce it later in your TemplateVM if you are satisfied. That is the (QubesOS?) template philosophy.
|
||||
|
||||
Standard tools installation
|
||||
================
|
||||
@ -27,9 +27,9 @@ Administration (documented)
|
||||
|
||||
sudo pciutils vim-minimal less tcpdump telnet psmisc nmap nmap-ncat usbutils
|
||||
|
||||
*Notes*: nmap can be used to discover a network (nmap -sP [network]), especially if you are inside a Microsoft network, because your AppVM will be protected/NATted behind Qubes firewall (microsoft / home network are heavily using autodiscovery technologies which require to be in the same local network (no firewall/no NAT), eg: your printer.
|
||||
*Notes*: nmap can be used to discover a network (nmap -sP [network]), especially if you are inside a Microsoft network, because your AppVM will be protected/NATted behind Qubes firewall (Microsoft / home network are heavily using autodiscovery technologies which require to be in the same local network (no firewall/no NAT), eg: your printer).
|
||||
|
||||
Some recommendation here: check your current network using the Network manager applet (eg: 192.168.1.65). Then run nmap in your current AppVM/TemplateVM to search for the selected printer/equipement: nmap -sP 192.168.1.-. Don't forget to allow temporarily the Qubes Firewall if you are inside a TemplateVM.
|
||||
Some recommendation here: check your current network using the Network manager applet (eg: 192.168.1.65). Then run nmap in your current AppVM/TemplateVM to search for the selected printer/equipment: nmap -sP 192.168.1.-. Don't forget to temporarily allow traffic via the Qubes Firewall if you are inside a TemplateVM.
|
||||
|
||||
Administration (undocumented)
|
||||
-------------------------------------------------
|
||||
@ -77,7 +77,7 @@ Search for a VPN package for your particular vpn solution
|
||||
|
||||
OR
|
||||
|
||||
For manual handling of VPN (and because NetworkManager is not available in proxyVMs, check the Qubes-users mail threads on google group
|
||||
For manual handling of VPN (and because NetworkManager is not available in proxyVMs, check the Qubes-users mail threads on google group)
|
||||
|
||||
(cprise started a good one on openvpn: [OPENVPNSETUP] "[qubes-users] OpenVPN Setup, Revisited Again!")
|
||||
|
||||
@ -95,11 +95,11 @@ Manual operations
|
||||
|
||||
- Don't forget to restart your TemplateVM or only the cups service when you installed cups (systemctl start cups)
|
||||
|
||||
- First you need to search for your printer. If you don't know its name or IP, search for it using nmap: check your current network using the Network manager applet (eg: 192.168.1.65). Then run nmap in your current AppVM/TemplateVM to search for the selected printer/equipement: nmap -sP 192.168.1.-. Don't forget to allow temporarily the Qubes Firewall if you are inside a TemplateVM.
|
||||
- First you need to search for your printer. If you don't know its name or IP, search for it using nmap: check your current network using the Network manager applet (eg: 192.168.1.65). Then run nmap in your current AppVM/TemplateVM to search for the selected printer/equipement: nmap -sP 192.168.1.-. Don't forget to temporarily allow traffic via the Qubes Firewall if you are inside a TemplateVM.
|
||||
|
||||
- Once you identified your printer, run system-config-printer GUI to install your printer
|
||||
|
||||
- You man need to cancel the operation to install more adapted printer drivers (eg: if the driver cannot be found automatically). Use yum search printername to find potential drivers (eg yum search photosmart)
|
||||
- You may need to cancel the operation to install more adapted printer drivers (eg: if the driver cannot be found automatically). Use yum search printername to find potential drivers (eg yum search photosmart)
|
||||
|
||||
GUI recommendations
|
||||
=============
|
||||
@ -135,13 +135,13 @@ Miscellaneous packages
|
||||
GUI themes
|
||||
-----------------
|
||||
|
||||
Managing GUI theme / appearance is often complex because when you do not want to depends on a specific desktop system.
|
||||
Managing GUI theme / appearance is often complex because when you do not want to depend on a specific desktop system.
|
||||
|
||||
For this reason, we need to customize themes for each GUI framework that our application depends on.
|
||||
|
||||
This often includes GTK2, GTK3 (which us a different configuration/themes than GTK2), Qt.
|
||||
|
||||
The apparance of Windows can only be changed in dom0, however, the appearance of all buttons, menus, icons, widgets are specific to each AppVM.
|
||||
The appearance of Windows can only be changed in dom0, however, the appearance of all buttons, menus, icons, widgets are specific to each AppVM.
|
||||
|
||||
### Packages
|
||||
|
||||
@ -155,7 +155,7 @@ You can check your currently installed theme packages (to eventually remove them
|
||||
|
||||
### Tweaking theme and appearance
|
||||
|
||||
First you can get an insight of installed Gtk theme and see how it will appears using lxappearance.
|
||||
First you can get an insight of installed Gtk theme and see how it will appear using lxappearance.
|
||||
|
||||
I recommend not applying settings using lxappearance (do not click on apply) because it will create multiple configuration files.
|
||||
|
||||
@ -176,12 +176,12 @@ Cleaning the whole dconf settings is also possible by removing the following fil
|
||||
rm ~/.config/dconf/user
|
||||
~~~
|
||||
|
||||
*Note*: lxappearance only have effect on gtk3 theme so it won't work to change gtk2 themes (used by Firefox, Thunderbird ...).
|
||||
*Note*: lxappearance only has an effect on gtk3 theme so it won't work to change gtk2 themes (used by Firefox, Thunderbird ...).
|
||||
However, it is very lightweight and can be used to identify the name and look of themes you are interested in.
|
||||
Once you have the name, you can apply it using gsetting command line or gconf-editor.
|
||||
|
||||
*Note*: if you really want a GUI theme editor, you can install gnome-tweak-tools, but this tool have a lot
|
||||
of gnome dependencies (~150MB of dependencies). Eventually install it and uninstall it as soon as you changed your theme.
|
||||
*Note*: if you really want a GUI theme editor, you can install gnome-tweak-tools, but this tool has a lot
|
||||
of gnome dependencies (~150MB of dependencies). You can install it and uninstall it as soon as you change your theme.
|
||||
|
||||
#### Testing notes
|
||||
|
||||
@ -258,7 +258,7 @@ Getting an uniform look for Qt & GTK is not achieved yet. A good source is on th
|
||||
Two case:
|
||||
|
||||
1. You installed packages of the theme you selected both for Qt, GTK2 and GTK3.
|
||||
(eg: Adwaita which is the default theme. I did not found another cross framework theme on fedora default packages).
|
||||
(eg: Adwaita which is the default theme. I have not found another cross framework theme on fedora default packages).
|
||||
|
||||
2. You want to use the GTK theme you selected for Qt but there is no qt package.
|
||||
In this case QGtkStyle will take precedence and convert the style automatically.
|
||||
|
||||
@ -18,7 +18,7 @@ How to set up pinyin input in Qubes
|
||||
|
||||
2. Close and shut down the TemplateVM.
|
||||
|
||||
3. Restart an AppVM which based on the template you installed `ibus-pinyin` and open a terminal.
|
||||
3. Restart an AppVM which is based on the template you installed `ibus-pinyin` in, and open a terminal.
|
||||
|
||||
4. Run `ibus-setup`
|
||||
|
||||
|
||||
@ -25,14 +25,14 @@ Only keep:
|
||||
|
||||
*Note*: Windows search is recommended because it is a nightmare to find something in menus if it is not enabled (it removes the search bar from the start menu, from the explorer, and from the control panel).
|
||||
|
||||
*Note*: Unselecting windows media, .Net and Internet Explorer will uninstall these components. on a new install it is generally old versions anyway and it will be quicker to install directly the new versions later.
|
||||
*Note*: Unselecting windows media, .Net and Internet Explorer will uninstall these components. On a new install they are generally old versions anyway and it will be quicker to install directly the new versions later.
|
||||
|
||||
Windows services
|
||||
---------------------------
|
||||
|
||||
Disable the following services that are not required or have no sense in a VM context:
|
||||
|
||||
* Base Filtering Engine (only required if your want to use Microsoft IPSEC)
|
||||
* Base Filtering Engine (only required if you want to use Microsoft IPSEC)
|
||||
* DHCP Client
|
||||
* Function Discovery Provider Host
|
||||
|
||||
@ -53,7 +53,7 @@ Disable the following services that are not required or have no sense in a VM co
|
||||
Windows update
|
||||
--------------------------
|
||||
|
||||
I recommend disabling windows update (Never Check for Update) because checking for updates will start every time you start an AppVM if you don't started your template after some days.
|
||||
I recommend disabling windows update (Never Check for Update) because checking for updates will start every time you start an AppVM if you haven't started your template in a while.
|
||||
|
||||
Running windows update is also apparently IO hungry.
|
||||
|
||||
@ -64,8 +64,8 @@ System properties
|
||||
|
||||
Right click on computer and go to Properties > Advanced > Performances:
|
||||
|
||||
* If your don't care about visual effect, in Visual Effect select "Adjust for best performance"
|
||||
* I personally tweak the page file size to win some place on my root.
|
||||
* If you don't care about visual effect, in Visual Effect select "Adjust for best performance"
|
||||
* I personally tweak the page file size to win some space on my root.
|
||||
|
||||
In Advanced>Performances>Advanced tab, change Virtual memory:
|
||||
|
||||
@ -75,16 +75,16 @@ Right click on computer and go to Properties > Advanced > Performances:
|
||||
4. click on set
|
||||
5. click on drive d:
|
||||
6. select customer size
|
||||
7. use an initial size of 500 and a max size of 1000. If the page file is too small, you will notify a low memory pop up when working on windows. In this case, it often means that you should extend your AppVM RAM.
|
||||
7. use an initial size of 500 and a max size of 1000. If the page file is too small, you will notice a low memory pop up when working on windows. In this case, it often means that you should extend your AppVM RAM.
|
||||
|
||||
* System Protection
|
||||
|
||||
Here you can disable Shadow Folder because it has little sense in case of Qubes because
|
||||
Here you can disable Shadow Folder because it has little sense in the case of Qubes because
|
||||
|
||||
* we do backup regularly of AppVMs/TemplateVMs;
|
||||
* we do regular backups of AppVMs/TemplateVMs;
|
||||
* we can revert at least one template change if we break something.
|
||||
|
||||
Select drives where system protection is enabled and click Configure. "Turn of system protection" "Delete all restore points"
|
||||
Select drives where system protection is enabled and click Configure. "Turn off system protection" "Delete all restore points"
|
||||
|
||||
* Remote
|
||||
|
||||
@ -157,7 +157,7 @@ Manual tasks that can/should be started in the template
|
||||
|
||||
> mv root.img.clean root.img
|
||||
|
||||
* If don't managed to fill the free space with zeros, you can follow the following *unsafe* undocumented procedure
|
||||
* If it doesn't manage to fill the free space with zeros, you can follow the following *unsafe* undocumented procedure
|
||||
|
||||
1. from dom0, go to /var/lib/templates-vm/yourtemplate
|
||||
2. check the partitioning to identify the filesystem offset of root.img
|
||||
|
||||
@ -175,7 +175,7 @@ Other Qrexec services installed by default:
|
||||
`tar2qfile` utility to do the conversion
|
||||
- `qubes.SelectDirectory`, `qubes.SelectFile` - services which should show
|
||||
file/directory selection dialog and return (to stdout) a single line
|
||||
containing selected path, or nothing in case of cancellation
|
||||
containing selected path, or nothing in the case of cancellation
|
||||
- `qubes.SuspendPre` - service called in every VM with PCI device attached just
|
||||
before system suspend
|
||||
- `qubes.SuspendPost` - service called in every VM with PCI device attached just
|
||||
|
||||
@ -100,7 +100,7 @@ Now, when you have dom0 upgraded, you can install new templates from Qubes R3.0
|
||||
Upgrading template on already upgraded dom0
|
||||
-------------------------------------------
|
||||
|
||||
If for some reason you did not upgrade all the templates and standalone VMs before upgrading dom0, you can still do this, but it will be somewhat more complicated. This can be a case when you restore backup done on Qubes R2.
|
||||
If for some reason you did not upgrade all the templates and standalone VMs before upgrading dom0, you can still do this, but it will be somewhat more complicated. This can be the case when you restore backup done on Qubes R2.
|
||||
|
||||
When you start R2 template/standalone VM on R3.0, there will be some limitations:
|
||||
|
||||
|
||||
@ -102,7 +102,7 @@ Also, the inter-VM services work as usual -- e.g. to request opening a document
|
||||
[user@work ~]$ qvm-open-in-vm work-win7 https://invisiblethingslab.com
|
||||
~~~
|
||||
|
||||
... just like in case of Linux AppVMs. Of course all those operations are governed by central policy engine running in Dom0 -- if the policy doesn't contain explicit rules for the source and/or target AppVM, the user will be asked for decision whether to allow or deny the operation.
|
||||
... just like in the case of Linux AppVMs. Of course all those operations are governed by central policy engine running in Dom0 -- if the policy doesn't contain explicit rules for the source and/or target AppVM, the user will be asked for decision whether to allow or deny the operation.
|
||||
|
||||
Inter-VM file copy and clipboard works for Windows AppVMs the same way as for Linux AppVM (except that we don't provide a command line wrapper, `qvm-copy-to-vm` in Windows VMs) -- to copy files from Windows AppVMs just right-click on the file in Explorer, and choose: Send To-\> Other AppVM.
|
||||
|
||||
|
||||
@ -43,7 +43,7 @@ Run command in a VM as a specified user
|
||||
Use tray notifications instead of stdout
|
||||
|
||||
--all
|
||||
Run command on all currently running VMs (or all paused, in case of --unpause)
|
||||
Run command on all currently running VMs (or all paused, in the case of --unpause)
|
||||
|
||||
--exclude=EXCLUDE\_LIST
|
||||
When --all is used: exclude this VM name (might be repeated)
|
||||
|
||||
@ -32,7 +32,7 @@ A user-friendly term for a [VM](#vm) in Qubes OS.
|
||||
|
||||
* "Qube" is an informal term intended to make it easier for less technical users to understand Qubes OS and learn how to use it. In technical discussions, the other, more precise terms defined on this page are to be preferred.
|
||||
|
||||
* The term "qube" should be lowercase unless it is the first word in a sentence. Note that starting a sentence with the plural of "qube" (i.e., "Qubes...") can be ambiguous, since it may not be clear whether the referent is a collection of qubes or [Qubes OS](#qubes-os).
|
||||
* The term "qube" should be lowercase unless it is the first word in a sentence. Note that starting a sentence with the plural of "qube" (i.e., "Qubes...") can be ambiguous, since it may not be clear whether the reference is a collection of qubes or [Qubes OS](#qubes-os).
|
||||
|
||||
Domain
|
||||
------
|
||||
|
||||
@ -32,7 +32,7 @@ Known issues
|
||||
|
||||
* Some icons in the Qubes Manager application might not be drawn correctly when using the Xfce4 environment in Dom0. If this bothers you, please use the KDE environment instead.
|
||||
|
||||
* USB mouse (in case of USB VM) does not work at first system startup (just after completing firstboot). Workaround: restart the system.
|
||||
* USB mouse (in the case of USB VM) does not work at first system startup (just after completing firstboot). Workaround: restart the system.
|
||||
|
||||
* For other known issues take a look at [our tickets](https://github.com/QubesOS/qubes-issues/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22Release+3.1%22+label%3Abug)
|
||||
|
||||
|
||||
@ -105,7 +105,7 @@ the ability to lock the screen to your USB VM, and then adding udev hook to
|
||||
actually call that service.
|
||||
|
||||
1. First configure the qrexec service. Create `/etc/qubes-rpc/custom.LockScreen` (in dom0)
|
||||
with a simple command to lock the screen. In case of xscreensaver (used in Xfce)
|
||||
with a simple command to lock the screen. In the case of xscreensaver (used in Xfce)
|
||||
it would be:
|
||||
|
||||
DISPLAY=:0 xscreensaver-command -lock
|
||||
@ -131,7 +131,7 @@ persistent across VM restarts. For example name the file
|
||||
|
||||
If you use KDE, the command(s) in first step would be different:
|
||||
|
||||
# In case of USB VM being autostarted, it will not have direct access to D-Bus
|
||||
# In the case of USB VM being autostarted, it will not have direct access to D-Bus
|
||||
# session bus, so find its address manually:
|
||||
kde_pid=`pidof kdeinit4`
|
||||
export `cat /proc/$kde_pid/environ|grep -ao 'DBUS_SESSION_BUS_ADDRESS=[[:graph:]]*'`
|
||||
|
||||
@ -127,7 +127,7 @@ Whenever a RPC request for service named "XYZ" is received, the first line
|
||||
in `/etc/qubes-rpc/policy/XYZ` that matches the actual `srcvm`/`destvm` is
|
||||
consulted to determine whether to allow RPC, what user account the program
|
||||
should run in target VM under, and what VM to redirect the execution to. If
|
||||
the policy file does not exits, user is prompted to create one *manually*;
|
||||
the policy file does not exist, user is prompted to create one *manually*;
|
||||
if still there is no policy file after prompting, the action is denied.
|
||||
|
||||
On the target VM, the `/etc/qubes-rpc/XYZ` must exist, containing the file
|
||||
|
||||
@ -140,7 +140,7 @@ whether to allow rpc, what user account the program should run in target VM
|
||||
under, and what VM to redirect the execution to. Note that if the request is
|
||||
redirected (`target=` parameter), policy action remains the same - even if
|
||||
there is another rule which would otherwise deny such request. If the policy
|
||||
file does not exits, user is prompted to create one; if still there is no
|
||||
file does not exist, user is prompted to create one; if still there is no
|
||||
policy file after prompting, the action is denied.
|
||||
|
||||
In the target VM, the `/etc/qubes-rpc/RPC_ACTION_NAME` must exist, containing
|
||||
@ -152,7 +152,7 @@ In the src VM, one should invoke the client via:
|
||||
/usr/lib/qubes/qrexec-client-vm target_vm_name RPC_ACTION_NAME rpc_client_path client arguments
|
||||
|
||||
Note that only stdin/stdout is passed between rpc server and client --
|
||||
notably, no command line argument are passed. Source VM name is specified by
|
||||
notably, no command line arguments are passed. Source VM name is specified by
|
||||
`QREXEC_REMOTE_DOMAIN` environment variable. By default, stderr of client
|
||||
and server is logged to respective `/var/log/qubes/qrexec.XID` files.
|
||||
It is also possible to call service without specific client program - in which
|
||||
@ -162,17 +162,17 @@ case server stdin/out will be connected with the terminal:
|
||||
|
||||
Be very careful when coding and adding a new rpc service. Unless the
|
||||
offered functionality equals full control over the target (it is the case
|
||||
with e.g. `qubes.VMShell` action), any vulnerability in a rpc server can
|
||||
with e.g. `qubes.VMShell` action), any vulnerability in an rpc server can
|
||||
be fatal to Qubes security. On the other hand, this mechanism allows to
|
||||
delegate processing of untrusted input to less privileged (or disposable)
|
||||
AppVMs, thus wise usage of it increases security.
|
||||
|
||||
### Extra keywords available in Qubes 4.0 and later
|
||||
|
||||
**This section is about not yet released version, some details may change**
|
||||
**This section is about a not-yet-released version, some details may change**
|
||||
|
||||
In Qubes 4.0, target VM can be specified also as `$dispvm:DISP_VM`, which is
|
||||
very similar to `$dispvm` but force using particular VM (`DISP_VM`) as a base
|
||||
very similar to `$dispvm` but forces using a particular VM (`DISP_VM`) as a base
|
||||
VM to be started as Disposable VM. For example:
|
||||
|
||||
anon-whonix $dispvm:anon-whonix-dvm allow
|
||||
@ -180,7 +180,7 @@ VM to be started as Disposable VM. For example:
|
||||
Adding such policy itself will not force usage of this particular `DISP_VM` -
|
||||
it will only allow it when specified by the caller. But `$dispvm:DISP_VM` can
|
||||
also be used as target in request redirection, so _it is possible_ to force
|
||||
particular `DISP_VM` usage, when caller didn't specified it:
|
||||
particular `DISP_VM` usage, when caller didn't specify it:
|
||||
|
||||
anon-whonix $dispvm allow,target=$dispvm:anon-whonix-dvm
|
||||
|
||||
@ -189,52 +189,52 @@ VM (`default_dispvm` VM property, which itself defaults to global
|
||||
`default_dispvm` property).
|
||||
Also note that the request will be allowed (`allow` action) even if there is no
|
||||
second rule allowing calls to `$dispvm:anon-whonix-dvm`, or even if
|
||||
there is a rule explicitly denying it. This is because the redirection happen
|
||||
there is a rule explicitly denying it. This is because the redirection happens
|
||||
_after_ considering the action.
|
||||
|
||||
### Service argument in policy
|
||||
|
||||
Sometimes just service name isn't enough to make reasonable qrexec policy. One
|
||||
example of such situation is [qrexec-based USB
|
||||
example of such a situation is [qrexec-based USB
|
||||
passthrough](https://github.com/qubesos/qubes-issues/issues/531) - using just
|
||||
service name it isn't possible to express policy "allow access to device X and
|
||||
deny to others". It isn't also feasible to create separate service for every
|
||||
service name isn't possible to express the policy "allow access to device X and
|
||||
deny to others". It also isn't feasible to create a separate service for every
|
||||
device...
|
||||
|
||||
For this reason, starting with Qubes 3.2, it is possible to specify service
|
||||
argument, which will be subject to policy. Besides above example of USB
|
||||
passthrough, service argument can make many service policies more fine-grained
|
||||
For this reason, starting with Qubes 3.2, it is possible to specify a service
|
||||
argument, which will be subject to policy. Besides the above example of USB
|
||||
passthrough, a service argument can make many service policies more fine-grained
|
||||
and easier to write precise policy with "allow" and "deny" actions, instead of
|
||||
"ask" (offloading additional decisions to the user). And generally the less
|
||||
choices user must make, the lower chance to make a mistake.
|
||||
choices the user must make, the lower the chance to make a mistake.
|
||||
|
||||
The syntax is simple: when calling service, add an argument to the service name
|
||||
The syntax is simple: when calling a service, add an argument to the service name
|
||||
separated with `+` sign, for example:
|
||||
|
||||
/usr/lib/qubes/qrexec-client-vm target_vm_name RPC_ACTION_NAME+ARGUMENT
|
||||
|
||||
Then create policy as usual, including argument
|
||||
(`/etc/qubes-rpc/policy/RPC_ACTION_NAME+ARGUMENT`). If policy for specific
|
||||
argument is not set (file does not exist), then default policy for this service
|
||||
Then create a policy as usual, including the argument
|
||||
(`/etc/qubes-rpc/policy/RPC_ACTION_NAME+ARGUMENT`). If the policy for the specific
|
||||
argument is not set (file does not exist), then the default policy for this service
|
||||
is loaded (`/etc/qubes-rpc/policy/RPC_ACTION_NAME`).
|
||||
|
||||
In target VM (when the call is allowed) service file will searched as:
|
||||
In target VM (when the call is allowed) the service file will searched as:
|
||||
|
||||
- `/etc/qubes-rpc/RPC_ACTION_NAME+ARGUMENT`
|
||||
- `/etc/qubes-rpc/RPC_ACTION_NAME`
|
||||
|
||||
In any case, the script will receive `ARGUMENT` as its argument and additionally as
|
||||
`QREXEC_SERVICE_ARGUMENT` environment variable. This means it is also possible
|
||||
to install different script for particular service argument.
|
||||
to install a different script for a particular service argument.
|
||||
|
||||
See below for example service using argument.
|
||||
See below for an example service using an argument.
|
||||
|
||||
### Revoking "Yes to All" authorization ###
|
||||
|
||||
Qubes RPC policy supports "ask" action. This will prompt the user whether given
|
||||
RPC call should be allowed. That prompt window has also "Yes to All" option,
|
||||
which will allow the action and add new entry to the policy file, which will
|
||||
unconditionally allow further calls for given service-srcVM-dstVM tuple.
|
||||
RPC call should be allowed. That prompt window also has a "Yes to All" option,
|
||||
which will allow the action and add a new entry to the policy file, which will
|
||||
unconditionally allow further calls for the given service-srcVM-dstVM tuple.
|
||||
|
||||
In order to remove such authorization, issue this command from a dom0 terminal
|
||||
(for `qubes.Filecopy` service):
|
||||
@ -247,7 +247,7 @@ the "Yes to All" results.
|
||||
|
||||
### Qubes RPC example ###
|
||||
|
||||
We will show the necessary files to create rpc call that adds two integers
|
||||
We will show the necessary files to create an rpc call that adds two integers
|
||||
on the target and returns back the result to the invoker.
|
||||
|
||||
* rpc client code (`/usr/bin/our_test_add_client`):
|
||||
@ -281,11 +281,11 @@ and we should get "3" as answer, after dom0 allows it.
|
||||
|
||||
### Qubes RPC example - with argument usage ###
|
||||
|
||||
We will show the necessary files to create rpc call that reads specific file
|
||||
from predefined directory on the target. Besides really naive storage, it may
|
||||
be very simple password manager.
|
||||
Additionally in this example simplified workflow will be used - server code
|
||||
placed directly in service definition file (in `/etc/qubes-rpc` directory). And
|
||||
We will show the necessary files to create an rpc call that reads a specific file
|
||||
from a predefined directory on the target. Besides really naive storage, it may
|
||||
be a very simple password manager.
|
||||
Additionally, in this example a simplified workflow will be used - server code
|
||||
placed directly in the service definition file (in `/etc/qubes-rpc` directory). And
|
||||
no separate client script will be used.
|
||||
|
||||
* rpc server code (*/etc/qubes-rpc/test.File*)
|
||||
@ -297,7 +297,7 @@ no separate client script will be used.
|
||||
exit 1
|
||||
fi
|
||||
# service argument is already sanitized by qrexec framework and it is
|
||||
# quaranted to not contain any space or /, so no need for additional path
|
||||
# guaranteed to not contain any space or /, so no need for additional path
|
||||
# sanitization
|
||||
cat "/home/user/rpc-file-storage/$argument"
|
||||
|
||||
|
||||
@ -43,7 +43,7 @@ Window content updates implementation
|
||||
|
||||
Typical remote desktop applications, like *vnc*, pass information on all changed window content in-band (say, over tcp).
|
||||
As that channel has limited throughput, this impacts video performance.
|
||||
In case of Qubes, *qubes_gui* does not transfer all changed pixels via vchan. Instead, for each window, upon its creation or size change, *qubes_gui*
|
||||
In the case of Qubes, *qubes_gui* does not transfer all changed pixels via vchan. Instead, for each window, upon its creation or size change, *qubes_gui*
|
||||
|
||||
- asks *qubes_drv* driver for the list of physical memory frames that hold the composition buffer of a window
|
||||
- passes this information via `MFNDUMP` message to *qubes_guid* in dom0
|
||||
|
||||
@ -18,9 +18,9 @@ Proprietary (NVIDIA/AMD) drivers are known to be sometimes highly problematic, o
|
||||
Radeon driver support is prebaked in the Qubes kernel (v4.4.14-11) but only versions 4000-9000 give or take.
|
||||
Support for newer cards is limited until AMDGPU support in the 4.5+ kernel, which isn't released yet for Qubes.
|
||||
|
||||
Built in Intel graphics, Radeon graphics (between that 4000-9000 range), and perhaps some prebaked NVIDIA card support that i don't know about. Those are your best bet for great Qubes support.
|
||||
Built in Intel graphics, Radeon graphics (between that 4000-9000 range), and perhaps some prebaked NVIDIA card support that I don't know about. Those are your best bet for great Qubes support.
|
||||
|
||||
If you do happen to get proprietary drivers working on your Qubes system (via installing them). Please take the time to go to the
|
||||
If you do happen to get proprietary drivers working on your Qubes system (via installing them), please take the time to go to the
|
||||
[Hardware Compatibility List (HCL)](https://www.qubes-os.org/doc/hcl/#generating-and-submitting-new-reports )
|
||||
Add your computer, graphics card, and installation steps you did to get everything working.
|
||||
|
||||
@ -39,14 +39,14 @@ yumdownloader --source nvidia-kmod
|
||||
|
||||
### Build kernel package
|
||||
|
||||
You will need at least kernel-devel (matching your Qubes dom0 kernel), rpmbuild tool and kmodtool, and then you can use it to build package:
|
||||
You will need at least kernel-devel (matching your Qubes dom0 kernel), rpmbuild tool and kmodtool, and then you can use it to build the package:
|
||||
|
||||
~~~
|
||||
yum install kernel-devel rpm-build kmodtool
|
||||
rpmbuild --nodeps -D "kernels `uname -r`" --rebuild nvidia-kmod-260.19.36-1.fc13.3.src.rpm
|
||||
~~~
|
||||
|
||||
In above command replace `uname -r` with kernel version from your Qubes dom0. If everything went right, you have now complete packages with nvidia drivers for Qubes system. Transfer them to dom0 (e.g. using a USB stick) and install (using standard "yum install /path/to/file").
|
||||
In the above command, replace `uname -r` with kernel version from your Qubes dom0. If everything went right, you have now complete packages with nvidia drivers for the Qubes system. Transfer them to dom0 (e.g. using a USB stick) and install (using standard "yum install /path/to/file").
|
||||
|
||||
Then you need to disable nouveau (normally it is done by install scripts from nvidia package, but unfortunately it isn't compatible with Qubes...):
|
||||
|
||||
@ -92,13 +92,13 @@ You will need:
|
||||
- kernel-devel package installed
|
||||
- gcc, make, etc
|
||||
|
||||
This installation must be done manually, because nvidia-installer refused to install it on Xen kernel. Firstly ensure that kernel-devel package installed all needed files. This should consists of:
|
||||
This installation must be done manually, because nvidia-installer refused to install it on Xen kernel. Firstly ensure that kernel-devel package installed all needed files. This should consist of:
|
||||
|
||||
- */usr/src/kernels/2.6.34.1-12.xenlinux.qubes.x86\_64*
|
||||
- */lib/modules/2.6.34.1-12.xenlinux.qubes.x86\_64/build* symlinked to the above directory
|
||||
- */usr/src/kernels/2.6.34.1-12.xenlinux.qubes.x86\_64/arch/x64/include/mach-xen* should be present (if not - take it from kernel sources)
|
||||
|
||||
If all the files are not there correct the errors manually. To build kernel module, enter *NVIDIA-Linux-x86\_64-260.19.44/kernel* directory and execute:
|
||||
If all the files are not there correct the errors manually. To build the kernel module, enter *NVIDIA-Linux-x86\_64-260.19.44/kernel* directory and execute:
|
||||
|
||||
~~~
|
||||
make
|
||||
@ -120,7 +120,7 @@ Add *rdblacklist=nouveau* option to /boot/grub/menu.lst (at the end of line cont
|
||||
|
||||
### Configure Xorg
|
||||
|
||||
After all, you should configure Xorg to use nvidia driver. You can use *nvidia-xconfig* or do it manually:
|
||||
Finally, you should configure Xorg to use nvidia driver. You can use *nvidia-xconfig* or do it manually:
|
||||
|
||||
~~~
|
||||
X -configure
|
||||
@ -143,7 +143,7 @@ Specifically, the notes below are aimed to help when the GRUB menu shows up fine
|
||||
* Using the anaconda installer interface, switch to the "shell" TTY (ALT-F2), and use `ip a` command to display the IP addresses.
|
||||
3. Using the Connect to the IP (remember the :1) using a VNC viewer.
|
||||
4. Follow the installation UI.
|
||||
* Since this won't be a usable install, skipping LUKS encryption is an option which will simplify this troubelshooting process.
|
||||
* Since this won't be a usable install, skipping LUKS encryption is an option which will simplify this troubleshooting process.
|
||||
* Do *not* reboot at the end of the installation.
|
||||
5. Once the installation completes, use the local VGA console switch to TTY2 via ALT-F2
|
||||
* Switch to the chroot of the newly-installed system via `chroot /mnt/sysinstall`
|
||||
@ -152,7 +152,7 @@ Specifically, the notes below are aimed to help when the GRUB menu shows up fine
|
||||
* Exit out of the chroot environment (`exit` or CTRL-D)
|
||||
6. Reboot
|
||||
|
||||
*Note* If the kernel parameters do *not* include `quiet` and `rhgb`, the kernel messages can easily obscure the LUKS passphrase prompt. Additionally, each character entered will cause the LUKS passphrase prompt to repeat onto next line. Both of these are cosmetic. The trade-off between kernel messages and the easy-to-spot LUKS passphrase prompt is left as excercise to the user.
|
||||
*Note* If the kernel parameters do *not* include `quiet` and `rhgb`, the kernel messages can easily obscure the LUKS passphrase prompt. Additionally, each character entered will cause the LUKS passphrase prompt to repeat onto next line. Both of these are cosmetic. The trade-off between kernel messages and the easy-to-spot LUKS passphrase prompt is left as exercise to the user.
|
||||
|
||||
## Gather initial `dmesg` output
|
||||
If all is well, the newly-installed Qubes OS instance should allow for user root to log in.
|
||||
@ -166,7 +166,7 @@ Run `dmesg > dmesg.nomodeset.out` to gather an initial dmesg output.
|
||||
4. Blindly log in as user root
|
||||
5. Blindly run `dmesg > dmesg.out`
|
||||
6. Blindly run `reboot` (this will also serve to confirm that logging in as root, and running commands blindly is possible rather than, say, the kernel having hung or some such).
|
||||
* Should this step fail, perhaps by the time step #3 was underaken, the OS hasn't finished coming up yet. Please retry, possibly with a different TTY (say, 3 or 4 - so CTRL-ALT-F3?)
|
||||
* Should this step fail, perhaps by the time step #3 was undertaken, the OS hasn't finished coming up yet. Please retry, possibly with a different TTY (say, 3 or 4 - so CTRL-ALT-F3?)
|
||||
|
||||
## Exfiltrate the dmesg outputs
|
||||
Allow the system to boot normally, log in as user root, and sneakernet the files off the system for analysis, review, bug logging, et cetera.
|
||||
|
||||
@ -118,7 +118,7 @@ Results:
|
||||
* SD card access: OK (tested at dom0)
|
||||
* Lid-close suspend: OK
|
||||
* Wifi: +10%-20% ICMP packet loss when comparing with OSX (have similar rates
|
||||
with tails Linux, more tests are required)
|
||||
with Tails Linux, more tests are required)
|
||||
|
||||
### References
|
||||
|
||||
@ -151,7 +151,7 @@ Bad news: still some minor issue to investigate.
|
||||
For the time being, my setup is just for testing purposes and help to bypass some blocking issues: do not use it in production or on machine where security is a concern!
|
||||
I hope to improve it as soon as possible.
|
||||
|
||||
During my nigths trying to get Qubes OS working, I faced tow main and blocking issues:
|
||||
During my nights trying to get Qubes OS working, I faced two main and blocking issues:
|
||||
* no boot, due to empty xen.cfg file
|
||||
* system freeze, due to Broadcom BCM43602 wifi card
|
||||
|
||||
@ -180,29 +180,29 @@ For security reasons, you should install Qubes using the whole disk. I preferred
|
||||
Download and prepare a USB with Qubes 3.2
|
||||
|
||||
You can install Qubes using BIOS or UEFI:
|
||||
* BIOS/CSM/Legacy: I have not been able to install using legagy, but I did not spent a lot of time on it.
|
||||
* UEFI plain: grub menu appears, but any gave me a quick flash and returned the main menu. I can boot it manually fixing the grub.cfg file, adding commands linuexefi and initrdefi, pointing proper files in /efi/boot. After boot, I end up with not root file system.
|
||||
* BIOS/CSM/Legacy: I have not been able to install using legagy, but I did not spend a lot of time on it.
|
||||
* UEFI plain: grub menu appears, but any gave me a quick flash and returned the main menu. I can boot it manually fixing the grub.cfg file, adding commands linuexefi and initrdefi, pointing proper files in /efi/boot. After boot, I end up with no root file system.
|
||||
* UEFI, using rEFInd: I have been successful, despite some issues to be fixed manually, after installation completion
|
||||
* download [rEFInd] refind-bin-0.10.4.zip: this file is not signed, so decide if you trust it or not. SHA1 sum is 3d69c23b7d338419e5559a93cd6ae3ec66323b1e
|
||||
* unzip it and run installer, which install rEFIind on the internal SSD
|
||||
* unzip it and run installer, which installs rEFIind on the internal SSD
|
||||
* if installation fails due to SIP, reboot in recovery mode, open a terminal and issue command
|
||||
~~~
|
||||
crsutil disable
|
||||
~~~
|
||||
* reboot and you will see some icons
|
||||
* choose Boot EFI\BOOT\xen.efi from ANACONDA
|
||||
* after a will the graphical installer is up and running, with keyboard and touchpad working
|
||||
* after a while the graphical installer is up and running, with keyboard and touchpad working
|
||||
|
||||
### 3. Installation
|
||||
|
||||
* As a general rule, keep the default values proposed during installation: you will change them later on
|
||||
* As a general rule, keep the default values proposed during installation: you can change them later on
|
||||
* Keep English, as language, locale
|
||||
* My macbook has a US keyboard, so I cannot say what happens if you change keyboard layout
|
||||
* DO NOT CHANGE the timezone, because it will trigger the wifi card, leading to a system freeze
|
||||
* Choose the "installation destination": do not change anything and press DONE button
|
||||
* Insert your password for Full Disk Encryption
|
||||
* If you do not already have free space on internal SSD disk, you will be prompted to reclaim some space:
|
||||
* If you shrunk OSX partition, disk utility left an empy partition: delete useless partition (eg: if you shrunk OSX parition, diskutil created an empty partition)
|
||||
* If you shrunk OSX partition, disk utility left an empy partition: delete useless partition (eg: if you shrunk OSX parition, diskutil created an empty partition)
|
||||
* Press on "reclaim space"
|
||||
* Press on "begin installation"
|
||||
* create your user and password
|
||||
@ -285,7 +285,7 @@ You can fix this issue, killing audio support with this quick workaround:
|
||||
|
||||
### 7. Fix system freezes due to Broadcom BCM43602
|
||||
|
||||
* If you experiences a system freeze, during VM setup, force a reboot and press OPTION key.
|
||||
* If you experience a system freeze, during VM setup, force a reboot and press OPTION key.
|
||||
* You will reach grub shell
|
||||
~~~
|
||||
configfile /EFI/qubes/grub.cfg
|
||||
@ -316,7 +316,7 @@ qvm-start sys-net
|
||||
xl pci-attach sys-net 04:00.0
|
||||
~~~
|
||||
|
||||
This latest steps are required to launch sys-net with wifi access. They can be automated in a custom systemd service
|
||||
These latest steps are required to launch sys-net with wifi access. They can be automated in a custom systemd service
|
||||
|
||||
|
||||
|
||||
|
||||
@ -95,7 +95,7 @@ nouveau E[ PGRAPH][0000:01:00.0] init failed, -16
|
||||
|
||||
Tip: In case you only have an external monitor it is advised to attach it directly to a connector of the motherboard if it is present, this should ensure that you're using the integrated graphics card instead of the nvidia graphics card.
|
||||
|
||||
If you're seeing this error than that means another graphics card (most likely an integrated one) acted as failsafe. Disabling nouveau has the consequences of disabling nvidia support all together.
|
||||
If you're seeing this error then that means another graphics card (most likely an integrated one) acted as failsafe. Disabling nouveau has the consequences of disabling nvidia support altogether.
|
||||
|
||||
1. Verify that that GRUB Boot Menu is displaying, you should be presented with two options and a progressbar/timer than goes rather fast.
|
||||
|
||||
@ -116,7 +116,7 @@ If you're seeing this error than that means another graphics card (most likely a
|
||||
|
||||
It is not an exact copy as it may differ from system to system.
|
||||
|
||||
Please note: chose the module that starts with `vmlinux`!
|
||||
Please note: choose the module that starts with `vmlinux`!
|
||||
|
||||
5. Press the left/right arrow keys to position the cursor at the end of kernel options line, after `rhgb quiet` in this case.
|
||||
|
||||
@ -126,7 +126,7 @@ If you're seeing this error than that means another graphics card (most likely a
|
||||
nouveau.modeset=0 rd.driver.blacklist=nouveau video=vesa:off
|
||||
~~~
|
||||
|
||||
This will tempororarily disable nouveau until boot.
|
||||
This will temporarily disable nouveau until next boot.
|
||||
|
||||
7. Press either the F10 key or Ctrl+X to start the boot process.
|
||||
|
||||
|
||||
@ -35,7 +35,7 @@ sudo yum clean all
|
||||
qvm-remove <VMname>
|
||||
~~~
|
||||
|
||||
With this method you lose one VM data, but it'll more securely work.
|
||||
With this method you lose the data of one VM, but it'll more reliably work.
|
||||
|
||||
1. Decrease filesystem safety margin (5% by default):
|
||||
|
||||
@ -43,5 +43,5 @@ With this method you lose one VM data, but it'll more securely work.
|
||||
sudo tune2fs -m 4 /dev/mapper/vg_dom0-lv_root
|
||||
~~~
|
||||
|
||||
1. Remove some unneeded files in dom0 home (if you have one, most likely no).
|
||||
1. Remove some unneeded files in dom0 home (if you have any, most likely no).
|
||||
|
||||
|
||||
@ -24,11 +24,11 @@ If you think you are ready to reflash you BIOS, here are the instructions that w
|
||||
|
||||
[http://forum.notebookreview.com/sony/473226-insyde-hacking-new-vaio-z-advanced-menu-bios.html](http://forum.notebookreview.com/sony/473226-insyde-hacking-new-vaio-z-advanced-menu-bios.html)
|
||||
|
||||
**WARNING**: We take absolutely no responsibility that the BIOS relflashing instructions given at the referenced forum are 1) valid, 2) non-malicious, and 3) work at all. Do this step on your own risk. Keep in mind that reflashing your BIOS might yield your system unusable. If you don't feel like taking this risk (which is a reasonable state of mind), look for a different notebook, or ask Sony Support to enable this option for you.
|
||||
**WARNING**: We take absolutely no responsibility that the BIOS relflashing instructions given at the referenced forum are 1) valid, 2) non-malicious, and 3) work at all. Do this step at your own risk. Keep in mind that reflashing your BIOS might yield your system unusable. If you don't feel like taking this risk (which is a reasonable state of mind), look for a different notebook, or ask Sony Support to enable this option for you.
|
||||
|
||||
In practice I have downloaded the BIOS-patching tools, run them in a VM on a BIOS image i extracted from my laptop, diffed the two versions, and concluded that it doesn't *seem* malicious, and then bravely applied tha patched image. If you don't know what are you doing, just get a different laptop, really!
|
||||
In practice I have downloaded the BIOS-patching tools, run them in a VM on a BIOS image I extracted from my laptop, diffed the two versions, and concluded that it doesn't *seem* malicious, and then bravely applied tha patched image. If you don't know what are you doing, just get a different laptop, really!
|
||||
|
||||
On a side note, we should notice that allowing anybody to reflash the BIOS is really a bad idea from the security point of view (Hello Evil Maids!). Shame on you, Sony!
|
||||
On a side note, we should note that allowing anybody to reflash the BIOS is really a bad idea from a security point of view (Hello Evil Maids!). Shame on you, Sony!
|
||||
|
||||
Getting the touchpad working during installation
|
||||
------------------------------------------------
|
||||
|
||||
@ -26,7 +26,7 @@ solved by adding `i915.enable_rc6=0` as a kernel parameter to
|
||||
## Instructions for getting your Lenovo Thinkpad X201 & X200 laptop working with Qubes/Linux ##
|
||||
|
||||
For being able to boot the installer from USB, you have to disable VT-d in the BIOS.
|
||||
Enter the BIOS by hitting F1, go to Config - CPU and then disable there VT-d.
|
||||
Enter the BIOS by hitting F1, go to Config - CPU and then disable VT-d there.
|
||||
|
||||
After the installation, you have to set a startup-parameter for Xen, to be able to activate VT-d again:
|
||||
|
||||
|
||||
@ -15,7 +15,7 @@ There is some [common bug in UEFI implementation](http://xen.markmail.org/messag
|
||||
|
||||
01. In GRUB menu<sup id="a1-1">[1](#f1)</sup>, select "Troubleshoot", then "Boot from device", then press `e`.
|
||||
02. At the end of `chainloader` line add `/mapbs /noexitboot`.
|
||||
03. Perform installation normally, but not reboot system at the end yet.
|
||||
03. Perform installation normally, but don't reboot the system at the end yet.
|
||||
04. Go to `tty2` (Ctrl-Alt-F2).
|
||||
05. Enable `/mapbs /noexitboot` on just installed system. This step differs between Qubes releases:
|
||||
|
||||
@ -36,7 +36,7 @@ There is some [common bug in UEFI implementation](http://xen.markmail.org/messag
|
||||
|
||||
Boot0001* Qubes HD(1,0,00000000...0,0x0,0x0)/File(\EFI\qubes\xen.efi)p.l.a.c.e.h.o.l.d.e.r. ./.m.a.p.b.s. ./.n.o.e.x.i.t.b.o.o.t.
|
||||
|
||||
then try passing `/dev/sda1` or `/dev/nvme0n1p1` or whatever is your EFI partition instead of `/dev/sda` and `-p 1`.
|
||||
then try passing `/dev/sda1` or `/dev/nvme0n1p1` or whatever your EFI partition is instead of `/dev/sda` and `-p 1`.
|
||||
|
||||
10. Now you can reboot the system by issuing `reboot` command.
|
||||
|
||||
@ -48,7 +48,7 @@ There is some [common bug in UEFI implementation](http://xen.markmail.org/messag
|
||||
noexitboot=1
|
||||
|
||||
**Note:** You must add these parameters on two separate new lines (one
|
||||
paramater on each line) at the end of each section that includes a kernel
|
||||
parameter on each line) at the end of each section that includes a kernel
|
||||
line (i.e., all sections except the first one, since it doesn't have a
|
||||
kernel line).
|
||||
|
||||
@ -63,7 +63,7 @@ Some Dell systems and probably others have [another bug in UEFI firmware](http:/
|
||||
|
||||
1. In GRUB menu<sup id="a1-2">[1](#f1)</sup> press `e`.
|
||||
2. At the end of `chainloader` line add `-- efi=attr=uc`.
|
||||
3. Perform installation normally, but not reboot system at the end yet.
|
||||
3. Perform installation normally, but don't reboot the system at the end yet.
|
||||
4. Go to `tty2` (Ctrl-Alt-F2).
|
||||
5. Execute:
|
||||
|
||||
@ -98,7 +98,7 @@ Qubes-specific EFI configuration. In such a case you need to finish those parts
|
||||
manually. You can do that just after installation (switch to `tty2` with
|
||||
Ctrl-Alt-F2), or booting from installation media in "Rescue a Qubes system" mode.
|
||||
|
||||
1. Examine `/boot/efi/EFI/qubes` (if using Qubes installation media, it's in `/mnt/sysimage/boot/efi/EFI/qubes`). You should see there 4 files:
|
||||
1. Examine `/boot/efi/EFI/qubes` (if using Qubes installation media, it's in `/mnt/sysimage/boot/efi/EFI/qubes`). You should see 4 files there:
|
||||
|
||||
- xen.cfg (empty, size 0)
|
||||
- xen-(xen-version).efi
|
||||
|
||||
Loading…
Reference in New Issue
Block a user