Git-Mirrors/qubes-doc
1
0
Fork 0
mirror of https://github.com/QubesOS/qubes-doc.git synced 2025-07-30 10:09:23 -04:00
Code Issues Projects Releases Packages Wiki Activity

update from upstream

Browse source
This commit is contained in:
qubedmaiska 2025-05-25 06:03:22 -04:00
commit f487cd4261
No known key found for this signature in database
GPG key ID: 204BCE0FD52C0501
11 changed files with 126 additions and 47 deletions
Download patch file Download diff file Expand all files Collapse all files

6
user/troubleshooting/app-menu-shortcut-troubleshooting.md
View file

@ -30,20 +30,20 @@ After that, use the directional buttons (`>`, `>>`, `<` or `<<`) to customize wh
To update the list of available applications, use the `qvm-sync-appmenus` command in dom0, replacing `<QUBE_NAME>` by the qube name:
```console
```
$ qvm-sync-appmenus <QUBE_NAME>
```
When using the *Refresh Applications* button in a qube's settings, the command `qvm-sync-appmenus` is used at least one time. When refreshing an AppVM application, it is also run against the template. So the console equivalent of clicking the *Refresh button* is the following (always in dom0):
```console
```
$ qvm-sync-appmenus <APPVM_NAME>
$ qvm-sync-appmenus <TEMPLATE_NAME>
```
In dom0, the `qvm-appmenus` tool allows the user to see the list of available applications (unstable feature), the whitelist of currently show application (unstable feature) and to change this list:
```console
```
$ qvm-appmenus --set-whitelist <FILE_PATH> <QUBE_NAME>
```

6
user/troubleshooting/disk-troubleshooting.md
View file

@ -32,9 +32,9 @@ As you can see, the `sudo lvs | head` command includes additional important colu
If your system is able to boot, but cannot load a desktop environment, it is possible to login to dom0 terminal with Alt + Ctrl + F2.
If this does not work, check the size of /var/lib/qubes/qubes.xml.
If it is zero, you'll need to use one of the file backup (stored in /var/lib/qubes/backup), hopefully you have the current data there.
Find the most recent one and place in /var/lib/qubes/qubes.xml instead of the empty file.
If this does not work, check the size of `/var/lib/qubes/qubes.xml`.
If it is zero, you'll need to use one of the file backup (stored in `/var/lib/qubes/backup`), hopefully you have the current data there.
Find the most recent one and place in `/var/lib/qubes/qubes.xml` instead of the empty file.
In any case you'll need some disk space to start the VM. Check `df -h` output if you have some.
If not, here are some hints how to free some disk space:

4
user/troubleshooting/uefi-troubleshooting.md
View file

@ -134,7 +134,7 @@ Some laptops cannot read from an external boot device larger than 8GB. If you en
## Installation completes successfully but then boot loops or hangs on black screen
There is a [common bug in UEFI implementation](https://xen.markmail.org/message/f6lx2ab4o2fch35r) affecting mostly Lenovo systems, but probably some others too.
There is a [common bug in UEFI implementation](https://web.archive.org/web/20170815084755/https://xen.markmail.org/message/f6lx2ab4o2fch35r) affecting mostly Lenovo systems, but probably some others too.
While some systems need `mapbs` and/or `noexitboot` disabled to boot, others require them enabled at all times.
Although these are enabled by default in the installer, they are disabled after the first stage of a successful install.
You can re-enable them either as part of the install process:
@ -178,7 +178,7 @@ Or if you have already rebooted after the first stage install and have encounter
## Installation completes successfully but then system crash/restarts on next boot
Some Dell systems and probably others have [another bug in UEFI firmware](https://markmail.org/message/amw5336otwhdxi76).
Some Dell systems and probably others have [another bug in UEFI firmware](https://web.archive.org/web/20170901231026/https://markmail.org/message/amw5336otwhdxi76).
These systems need `efi=attr=uc` enabled at all times.
Although this is enabled by default in the installer, it is disabled after the first stage of a successful install.
You can re-enable it either as part of the install process:

2
user/troubleshooting/usb-troubleshooting.md
View file

@ -19,7 +19,7 @@ For guidance setting up a USB qube, see the [USB documentation](/doc/how-to-use-
Currently (until issue [1082](https://github.com/QubesOS/qubes-issues/issues/1082) gets implemented), if you remove the device before detaching it from the qube, Qubes OS (more precisely, `libvirtd`) will think that the device is still attached to the qube and will not allow attaching further devices under the same name.
This may be characterized by VM manager crashes and the error message: `Houston, we have a problem`.
The easiest way to recover from such a situation is to reboot the qube to which the device was attached.
If this isn't an option, you can manually recover from the situation by following the instructions at the [Block Devices documentation](/doc/how-to-use-block-storage-devices/#what-if-i-removed-the-device-before-detaching-it-from-the-vm)
If this isn't an option, you can manually recover from the situation by following the instructions at the [Block Devices documentation](/doc/how-to-use-block-storage-devices/#what-if-i-removed-the-device-before-detaching-it-from-the-vm).
## "Device attach failed" error

1
user/troubleshooting/vpn-troubleshooting.md
View file

@ -46,5 +46,6 @@ sudo notify-send "$(hostname): Test notify-send OK" --icon=network-idle
You should see the `info` message appear on the top of your screen.
If that is the case then `notify-send` is not the issue.
If it is not, and you have an error of some sort you can:
1. Remove all calls to `notify-send` from scripts you are using to start VPN
2. Use another template qube that has a working `notify-send` or find proper guide and make your current template run `notify-send` work properly.