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.)
(at least 2 links to the following page, which “Qubes crowd” is bound to click on :))
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.