Please make installing more flexible and user-friendly -- suggestions:

Hi. So I haven’t managed to install yet (been trying different things for several days). Here’s feedback so far:

It seems a lot of advice from troubleshooting docs and hacks from forums could be included/automated in the install… As much as possible this should be done. (For example, if you can identify hardware, like Ryzen 5000 series, that’s only going to be supported by later Xen, maybe automatically include the “dom0_max_vcpus=1 dom0_vcpus_pin” hack. Or update to latest version of Xen! :))

Also, the strict dd requirement for ISO is too limiting. From what I gather, with uefi, you can just unrar an ISO, do a simple copy to an empty usb stick, and install some other OSs like that. That would be much easier for most users, most circumstances – unzip would be even better. I think you’re catering to legacy BIOS with the ISO (please correct if I’m wrong), but the hardware requirements are things like SSDs, VM-supporting CPUs, and many gigs of ram. So what’s the point of catering to legacy BIOS at the expense of a much easier USB creation process – this isn’t tiny core linux – everyone’s gonna have uefi. Surely you can make such an install method work. (This is my situation so far – it was “download iso to unrooted (by me, at least :)) Android, unrar, copy via USB OTG”.)

Please also consider reducing the size of the necessary download at least to the FAT32 filesize limit. The basic fedora is around 1GB. Do you really need to include everything in the initial download, so that it becomes an unwieldy 6 gigs?

How to improve install docs:

Include a section (or page) with all the necessary/recommended uefi settings using the same nomenclature as in the settings – what should be enabled, what should be disabled. For example, I have only “SVM mode”, but nothing with “AMD-Vi” or “AMD-V”, etc. Also, I wasn’t sure about “fast boot”, “secure boot”, “network stack”, etc. Some recommendations in this regard in the install docs would be helpful.

Also, I think you’re sending users down too deep of a rabbit hole with the evil maid links – it’s like a 12yr old article, parts of which are outdated – this is all too much for a novice, too steep of a learning curve right away. My feeling was, “really? You are sending me to read a 12yr old article? Like, nothing changed in tech since then?”. And if all the AEM stuff doesn’t apply to AMD CPUs, which was my takeaway, this could be made much clearer on the install page. I think this section should just be updated with basic contemporary advice, e.g. “consider your threat model, for most people: set passwords in your bios/eufi, physical security, opsec (maybe glitter, etc.)”.

Too much pain, “friction”, steep learning curve, and obscure/irrelevant docs during the install process impede adoption of this otherwise great OS. (Why hasn’t this become the standard paradigm/architecture in the 10+ years it been out there?! I’d really like to understand…)

Also, please include some recommendations (maybe in the FAQ) on fallback options for users who don’t manage to install or get Qubes to work. While they wait for hardware support, for example, what’s the best alternative? Is Fedora on bare metal “not ideal, but maybe good enough” to practice on in the meantime? What’s the most important security advice in that case? Or should people definitely try to install Xen separately first, and then Fedora? Leave SVM mode in bios/uefi enabled or disable? What about"secure boot"? Maybe send them to try the latest beta build of Qubes…

Thank you. (First post, hope this is right place.)

But AEM isn’t mentioned at all in the installation guide. At least, I couldn’t find it with Ctrl+F for AEM, evil, maid, etc. Where are you even seeing this? What is “the install page” and “this section”?

Where, though? If you have specifics (links and quotations), I might be able to fix this.

Interesting idea, thanks. I’ll take a look at where this might be worth mentioning.

I should have been clearer about the “rabbit hole” perhaps (but my post was long enough as it is :)); it is as follows (remove square brackets below – i’ve hit my “2 links per post” limit for new users):

:arrow_down: (at least 2 links to the following page, which “Qubes crowd” is bound to click on :))

:arrow_down:
h[tt]ps://www.qubes-os.org/doc/anti-evil-maid/
:arrow_down:
h[tt]ps://blog.invisiblethings.org/2011/09/07/anti-evil-maid.html
h[tt]ps://groups.google.com/d/msg/qubes-users/sEmZfOZqYXM/j5rHeex1BAAJ
h[tt]ps://github.com/QubesOS/qubes-antievilmaid
(This☝️ page mentions that Joanna’s article is partly outdated.)
h[tt]ps://github.com/Qubes-Community/Contents/blob/master/docs/security/security-guidelines.md

You can see how that’s all probably too much to digest before attempting install. And it’s all irrelevant for AMD CPUs, right?

I should say that further down, the installation doc page seems good; i just never got that far in installing. I would have liked to see more guidance on BIOS/UEFI settings there, using terms that people are actually seeing in the utility (“SVM mode” instead of “AMD-Vi” or whatever is the correct substitution/addition; “fast boot”, “secure boot”, etc. – whatever settings are important).

Thanks.

So, what’s the suggestion? Delete the “installation security” page? Don’t link to it from the “installation guide”? Don’t mention AEM on the “installation security” page? If we had to choose from among these options, the latter would probably make the most sense, as AEM is mentioned only in a parenthetical aside there.

I mean, no one said you had to follow every link from the installation guide N levels deep (including across domains, outside of the Qubes docs) before being able to install, though. That’s just something you decided to do on your own. And it could be a reasonable thing to do for people who like to be extremely thorough, but it’s a bit odd to do it voluntarily, then complain about it.

FWIW, the link to Joanna’s original AEM blog post is under a section called “Background.”

Of course no one forced me to follow those links. “Nudged” maybe? :slight_smile: Don’t get me wrong, the docs are generally good and appreciated – I understand resources are limited. I could very well have made wrong judgements, including about how thorough to be.

I think there were other links on AEM page that led to years-old info/discussions. Maybe make the AEM page more self-contained and comprehensive with up-to-date info helping users understand the considerations and whether it applies to them. For example, does AMD have compatible technology with Intel TXT or is it strictly an Intel thing (and AMD users should make other arrangements)? Extract from those old articles/discussions whatever is still relevant, whatever is the reason you think it’s still worth linking to them. You could maybe include those old links as “historical references” at the bottom, if they are significant in that respect… It’s probably right to mention AEM on “install security” page – keep it.

Consider also adding some kind of date to docs generally, like Wikipedia’s “last edited”, or like here: example 1, example 2.

dom0 alone is 1.5gb+, the rest belong to vm and it is already compressed.

have you try with kernel latest option when installing?

also for ryzen 5xxx, it is already work out of the box in 4.2

i think we can include ‘bleeding edge’ qubes (4.2) version in the doc @adw? with some warning of course.

This would be great, but unfortunately, I don’t have the knowledge to do this myself. PRs welcome from anyone who does.

I think we’ll get that “for free” as part of the transition to the “Read the Docs” (RTD) platform.

Not sure what you mean. Include it how?

Thanks for good news about 4.2.

Yes, I tried all options from grub, and the dom0_max_vcpus=1 hack.

Just before install goes to maintenance shell, I get (from journalctl):

"
EFI loader partition unknown, exiting.
(The boot loader did not set EFI variable LoaderDevicePartUUID.)
Warning: dracut-initqueue timeout – starting timeout scripts
Warning: dracut-initqueue timeout – starting timeout scripts
"

and a little above that, there’s a line in red
"sda: can’t store path info "

Is there a way to manually fix this? The way I created the USB is to use unrar on the downloaded iso and then copy the files (not dd) to empty USB (i think it’s in fat32 – it was formatted by android).

What is the reason you are distributing it the iso+dd way? As opposed to zip+“unzip to usb” way? UEFI doesn’t need the special way of creating the USB, it just needs the files – try it. I could get to grub and the maintenance shell just with iso+“unrar to usb”. You could tweak the install to work this way, couldn’t you? This would be more flexible/user-friendly than creating the usb with dd. And you could just include the minimal fedora (with other templates as separate downloads).

He probably just means “to include a link somewhere in the docs to the directory/folder where latest builds can be found for download. And warn that these are beta/alpha”.

(Possible places for this: download page, install guide page, installation troubleshooting page, faq page.
I think the links are (remove sq brackets):
h[tt]ps://ftp.qubes-os.org/iso/
h[tt]ps://qubes.notset.fr/iso/
But get them from a reliable source, not from me! :slight_smile:
)

Oh, that already exists:

And it’s already linked from the installation guide as of yesterday.

1 Like

@51lieal
FAT32 filesize limit may be important in case people need to download the iso to an sd card or USB OTG on mobile. What about just installing dom0 initially and letting people download whatever vm/template files they need separately, the same way they downloaded the iso? So after installation of dom0, you would show a message like, “ok, we’re done with this USB, you can remove it and insert the one with vm/template files you want to install”. (And they can use/overwrite the same usb stick via “sneakernet”, of course.)

@adw
I don’t think the “testing” page is linked from the install guide – i can’t find it in source on the site… Does it still need to propagate to the public site?
Also, for me, the “hamburger menu” on top on the Qubes site doesn’t work (Chromium-based mobile browser). Confirm?

Strange. You can see my commit in qubes-doc here:

And you can see that @marmarek’s bot included it in the main repo here:

So, by all appearances, it should be on the live website. Yet, it is not.

I’ll try pushing an empty commit to the main repo to trigger a rebuild and see if that helps.

Confirmed. I think that might be a side-effect of upgrading to jQuery 3.6.4 (without any other changes):

Let’s try reverting that commit and see if it fixes the menu.

Edit to add (because the forum doesn’t allow more than three consecutive replies):

Looks like that did the trick. Can you confirm that the hamburger menu works for you now, @Res9?

The reason I upgraded jQuery is because of this automated GitHub alert: Dependabot alert: Potential XSS vulnerability in jQuery. Unfortunately, I’m not a professional web developer and don’t really know how to fix the hamburger menu so that it’s compatible with newer, non-vulnerable version of jQuery.

I also don’t know how serious this vuln is for us in our specific use case. Our site is mostly static and doesn’t handle any sensitive user data. We also have this explicit warning: FAQ: Should I trust this website? Nonetheless, if it presents a significant risk for users, I’d rather let the hamburger menu be temporarily broken until someone with the requisite expertise can fix it.

I’ve created an issue to track this:

Looks like that did the trick. It’s now appearing on the live page (Ctrl+F for “testing a newer release”).

1 Like

it is possible to build dom0 only or dom0 + debian 11 vm only for easy to use. should be only 2.5 gb

Wanted to chime in a bit here. It’s on topic but not really following the current train of thought.

When I went through the provided installer (installed to internal drive from USB) the installer would hang part-way through the installation process. It required me to restart the process from the beginning. Oftentimes it would complete copying from the thumbdrive, reboot, start provisioning from the internal drive, and then hang during template provisioning. I want to say it took the better part of a day to tweak things to get through that. I had to fiddle with which combination of setup parameters wouldn’t jam the provisioning step.

Once it was finally installed it ran great for the most part. I get the occasional freeze (seems unrelated to my installer woes as others have a similar problem) but it’s a great daily driver otherwise.

1 Like

@adw
Yes, the hamburger menu works now. Another idea for a stopgap measure is to upgrade the jQuery and make the menu button into a simple link to the “sitemap” at the bottom of the page (the one that follows the search box).

(People should insist on being able to browse the web with JavaScript turned off anyway… As this jQuery case demonstrates once again.)

After dom0 installation, to install their vm/template files of choice, the option(s) of either “sneakernet” or whonix template should be available, so it never registers with their fascist government that they visited Qubes’ servers.
Also, instead of including debian, can’t you just re-use the fedora that’s in dom0 for the vm/template? Just delta/diff what’s necessary.

Dom0’s fedora version can be significantly outdated. Keeping it up with fedora template’s version adds great burden to the developers.

In fact, when a major version of Qubes is released, its dom0 almost always has reached EOL, which is inappropriate as a template.

1 Like

dom0 + debian 11 should be my bottom line, at first qubes is not for (sorry) low spec pc, but as you learn about qubes, even an i5 x230 8gb ram, im happy with it.

you can also only use dom0 +whonix right in the installer, but not sure if it work out of the box for sys net and firewall