Documentation Fails: Proper Support Desired for Qubes 3.1-rc2; Suggestions for Improvement

[HardenedArray]

Hi Joanna,

I love Qubes, I believe in your design, and I like your thinking behind the Qubes user work flow.

However, if we want to attract more users, we have to be able to tell them how to correctly operate their OS, as even experienced testers get very frustrated when they try to: RTFM, but the FM is: outdated, and/or incorrect. ;D

These observations and comments relate solely to Qubes 3.1-rc2.

One. Personally, I find it impossible to live a rich digital life without the packages available in the RPM Fusion repos.

However, when I read: https://www.qubes-os.org/doc/software-update-vm/

and then am told to:

If you would like to enable the RPM Fusion repository…

dom0 Start Menu -> Template:Fedora 21 -> Package Sources -> Enable RPMFusion

This already covers RPMFusion yum signing keys.

This is where, the problems, begin:

a. There is no such 'thing' as 'Package Sources' under Template:fedora-23.
b. There is: 'Package Updater' but, as expected, this is a just a GUI which checks for updates, and then, immediately, exits. Of course, running 'dnf upgrade' from a Fed 23 Template terminal is far more efficient.
c. There is also "Software' but I saw no way to add repos from there.
d. I searched for 'rpmfusion' on my system and found a bunch of rpmfusion repos at, root owned:

/var/lib/yum/repos/x86_64/23/

The problem is, all of those rpmfusion repos directories: are empty.

The only thing that worked for me was to manually edit the four most important rpmfusion-* (free and non-free) repo files residing in:

/etc/yum.d/repos/

and then, I needed to manually verify the (correct) RPM Fusion signing keys as packages were initially downloaded.

Potential Solution: either update the documentation, and/or write a correct script to automate (optional) RPM Fusion repo inclusion within the Fed 23 template.

Two. I am not particularly concerned about my current inability to update dom0, given Joanna's thoughts on this topic, but let's make sure we understand: why.

a. I have Whonix selected as the default network, per post-install initial VM setup. This, indeed, is a very good thing, and as a multi-year user of Whonix, I know all of my networking is working, correctly, and as expected.
b. Attempting to update dom0 from Qubes VM Manager just times out/reports No updates available ('c.' explains why).
c. Running sudo qubes-dom0-update, results in:

$ sudo qubes-dom0-update
Using sys-whonix as UpdateVM to download updates for Dom0; this may take some time...
Running command on VM: 'sys-whonix'...
Checking for dom0 updates...
No new updates available
file:///var/lib/qubes/updates/repodata/repomd.xml: [Errno 14] curl#37 - "Couldn't open file /var/lib/qubes/updates/repodata/repomd.xml"
Trying other mirror.

One of the configured repositories failed (Qubes OS Repository for Dom0),
and yum doesn't have enough cached data to continue. At this point the only
safe thing yum can do is fail. There are a few ways to work "fix" this:

 1. Contact the upstream for the repository and get them to fix the problem.

 2. Reconfigure the baseurl/etc. for the repository, to point to a working
    upstream. This is most often useful if you are using a newer
    distribution release than is supported by the repository (and the
    packages for the previous distribution release still work).

 3. Disable the repository, so yum won't use it by default. Yum will then
    just ignore the repository until you permanently enable it again or use
    --enablerepo for temporary usage:

        yum-config-manager --disable qubes-dom0-cached

 4. Configure the failing repository to be skipped, if it is unavailable.
    Note that yum will try to contact the repo. when it runs most commands,
    so will have to try and fail each time (and thus. yum will be be much
    slower). If it is a very temporary problem though, this is often a nice
    compromise:

        yum-config-manager --save --setopt=qubes-dom0-cached.skip_if_unavailable=true

failure: repodata/repomd.xml from qubes-dom0-cached: [Errno 256] No more mirrors to try.
file:///var/lib/qubes/updates/repodata/repomd.xml: [Errno 14] curl#37 - "Couldn't open file /var/lib/qubes/updates/repodata/repomd.xml"
No updates avaliable

Followed by trying to find the non-existant file:

[@dom0 ~]$ cat /var/lib/qubes/updates/repodata/repomd.xml
cat: /var/lib/qubes/updates/repodata/repomd.xml: No such file or directory
[@dom0 ~]$ cd /var/lib/qubes/updates/repodata/
bash: cd: /var/lib/qubes/updates/repodata/: No such file or directory
[@dom0 ~]$ cd /var/lib/qubes/updates/
[@dom0 updates]$ ls -al
total 8
drwxrwx--- 2 root qubes 4096 Dec 31 02:17 .
drwxrws--- 9 root qubes 4096 Feb 1 10:05 ..

I also know when you run:

cat /etc/yum.repos.d/qubes-dom0.repo

The first stanza shows: an enabled qubes-dom0.repo:

[qubes-dom0-current]
name = Qubes Dom0 Repository (updates)
baseurl = http://yum.qubes-os.org/r$releasever/current/dom0/fc20
enabled = 1
metadata_expire = 7d
gpgcheck = 1
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-$releasever-primary

However, checking: http://yum.qubes-os.org/r$releasever/current/dom0/fc20, 404's with:

Not Found

The requested URL /r$releasever/current/dom0/fc20 was not found on this server.

Potential Solution: either update the documentation, and/or disable this dom0-update functionality in all future releases (or maybe only optionally provide a command/script to enable dom0-updating for users 'in the know').

BTW, Joanna, thanks for sharing:

cat /path/to/file_in_dom0 | qvm-run --pass-io <dst_domain> 'cat > /path/to/file_name_in_appvm'

as there are 'some' determined users. ;D

Three. System Tools, File Manager 'shows' a proper Dolphin icon, yet that link does not launch a/any File Manager. System Tools, File Manager actually (only) launches:

[Dom0] File Manager Preferences

Potential Solution: Whether intended, or not, this broken launcher makes no intuitive sense. Fix it, or exclude it.

BTW: On a related note, Dolphin and Krusader are my file managers of choice on my native Fed 23 and Gentoo Hardened systems.

Dolphin, a superb twin panel file manager, with an integrated 'pwd' CLI available with 'f4' is a true 'thing' of visual beauty, and functionality, when installed and run on a native KDE system.

I have no idea if I need additional visual support packages, but literally, Dolphin as installed under the Qubes Fed 23 template is nothing short of a 'visual horror.' In fact, it is so bad, I completely refuse to use Dolphin within Qubes. Being forced to use the far less capable 'Files' still works, but this 'option' seriously interferes with, and impedes, my work flow.

Please fix Dolphin (on Qubes), or tell users they need a set of KDE packages to correctly display Dolphin.

Four. I have no idea while after performing a clean install of a Fed 23 system under Qubes 3.1 during installation, there are any CLI references to yum, and I do mean, for any reason. Yum is/has been deprecated since Fed 22.

As you probably know, dnf ('Dandified yum') first became available in the Fed 18 testing repos, and then became the standard/default package manager in Fed 22, following three years of testing.

DNF rocks, stably, period.

Potential Solution: Update the documentation, and scrub/replace all references to yum with dnf.

More generally, if Qubes does not have the time/bandwidth/resources to support all previous releases, after the documentation has been updated, perhaps you can consider telling new installers, and all current users, something like:

We strongly recommend installing our latest Qubes release, as only it provides the strongest, and most current, Qubes security features. Our documentation, and internet support, are only valid for the two (or latest, only) most recent releases of Qubes. You are welcome to install older releases, as long as you comfortable operating without support.

Hoping you find this input, helpful,

HardenedArray

[andrewdavidwong]

I just want to point out that the goal of the documentation is to be accurate for the stable version(s) of Qubes, not for release candidates.

[andrewdavidwong]

I just want to point out that the goal of the documentation is to be accurate for the stable version(s) of Qubes, not for release candidates.

[marmarek]

One. Personally, I find it impossible to live a rich digital life without the packages available in the RPM Fusion repos.

Thanks for the bugreport, copied here: #1716

Two. I am not particularly concerned about my current inability to update dom0, given Joanna's thoughts on this topic, but let's make sure we understand: why.
failure: repodata/repomd.xml from qubes-dom0-cached: [Errno 256] No more mirrors to try.
file:///var/lib/qubes/updates/repodata/repomd.xml: [Errno 14] curl#37 - "Couldn't open file /var/lib/qubes/updates/repodata/repomd.xml"
No updates avaliable

It's already discussed in #1685 (in short: minor issue, causing major user confusion).

Three. System Tools, File Manager 'shows' a proper Dolphin icon, yet that link does not launch a/any File Manager. System Tools, File Manager actually (only) launches:

Indeed it shouldn't be there. Generally there should be no file manager in dom0 installed. All the user files are in VMs.

Four. I have no idea while after performing a clean install of a Fed 23 system under Qubes 3.1 during installation, there are any CLI references to yum, and I do mean, for any reason. Yum is/has been deprecated since Fed 22.

DNF rocks, stably, period.

Almost. There are two major issues with it:

• a bug affecting Xen PV, making dnf extremely slow https://bugzilla.redhat.com/show_bug.cgi?id=1227014 - the fix exists upstream, but isn't included in Fedora yet
• no central configuration configuration - /etc/dnf/dnf.conf is used only by dnf command line tool, but not PackageKit or other frontends. This means proxy needs to be configured in every of those tools. Some of them doesn't even support such setting...

Also there are some minor issues (not bugs, but affecting usage in Qubes OS), for example https://bugzilla.redhat.com/show_bug.cgi?id=1279001

Anyway we are working to resolve those issues.

Thanks for your feedback.

[marmarek]

One. Personally, I find it impossible to live a rich digital life without the packages available in the RPM Fusion repos.

Thanks for the bugreport, copied here: #1716

Two. I am not particularly concerned about my current inability to update dom0, given Joanna's thoughts on this topic, but let's make sure we understand: why.
failure: repodata/repomd.xml from qubes-dom0-cached: [Errno 256] No more mirrors to try.
file:///var/lib/qubes/updates/repodata/repomd.xml: [Errno 14] curl#37 - "Couldn't open file /var/lib/qubes/updates/repodata/repomd.xml"
No updates avaliable

It's already discussed in #1685 (in short: minor issue, causing major user confusion).

Three. System Tools, File Manager 'shows' a proper Dolphin icon, yet that link does not launch a/any File Manager. System Tools, File Manager actually (only) launches:

Indeed it shouldn't be there. Generally there should be no file manager in dom0 installed. All the user files are in VMs.

Four. I have no idea while after performing a clean install of a Fed 23 system under Qubes 3.1 during installation, there are any CLI references to yum, and I do mean, for any reason. Yum is/has been deprecated since Fed 22.

DNF rocks, stably, period.

Almost. There are two major issues with it:

• a bug affecting Xen PV, making dnf extremely slow https://bugzilla.redhat.com/show_bug.cgi?id=1227014 - the fix exists upstream, but isn't included in Fedora yet
• no central configuration configuration - /etc/dnf/dnf.conf is used only by dnf command line tool, but not PackageKit or other frontends. This means proxy needs to be configured in every of those tools. Some of them doesn't even support such setting...

Also there are some minor issues (not bugs, but affecting usage in Qubes OS), for example https://bugzilla.redhat.com/show_bug.cgi?id=1279001

Anyway we are working to resolve those issues.

Thanks for your feedback.