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.
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.
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).
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.
Sure, i understand about non-low spec requirements for Qubes (that was my point about uefi in OP).
I was thinking more about circumstances they might be starting from so that they can install Qubes on their new high-spec pc – those circumstances might not be high spec, e.g. fat32, no access to dd command, smartphone, etc. Maybe they’ll just have to install something else first, and then use that to make Qubes installation USB… At least there’s dd command in the maintenance shell of the qubes install…
There is no ETA right now, AFAIK. My understanding is that the core devs are deciding whether the release of 4.2 should be blocked on certain deliverables, which could change the release date significantly in either direction.
Because dom0 is fedora, maybe dom0+fedora would be better than dom0+debian, for consistency and easier learning curve. (Some commands on debian are different, right? - like package management…)
I’m guessing that’s going to be around 3gb… Which is not much different than 2.5 and still much better than 6 (which is, let’s be honest, kinda out of control :)). Fedora also has a little better hardware support, right?
Just some considerations; I don’t have that much experience with linux distros.
I’d just like to point out that on one hand you are asking them to drop Legacy BIOS under the assumption that it’s irrelevant and outdated even though almost every motherboard being manufactured today still support it. Qubes has the option to be set up under UEFI or Legacy BIOS… On the other hand you are asking them to tailor their ISO file to an old filesystem constraint that very few people have dealt with in years. For those of us in 1st world countries, it’s almost impossible to find a flash drive for sale that is less than 16gb in size and a 64gb usb stick can be acquired for ~$15… Even if you are on a relatively dated or inexpensive internet connection and only getting 200mbps, you should still be able to download the 6gb Qubes file in ~4 minutes, it should cost you no more than $10-$15 for a USB drive, and there should be 0 issue finding a USB drive that is larger than 6gb.
The standard method for the inexperienced user to write most linux ISO’s to USB has been the same for over a decade… Download the ISO and verify it’s hash, download a free ISO burner such as Etcher or Rufus, and click a few buttons. If this is too difficult for a user to figure out, then they have nowhere near the skill set to be jumping into an advanced operating system designed with security as a focus from the ground up.
And that brings me to my main point. This operating system is designed to be as secure as possible. The devs are not going to risk security so users can drag and drop their ISO onto a USB drive instead of clicking two buttons in ISO burner software or running a single command in the terminal. Nor are they going to prioritize users ability to download and install Qubes from a phone. Not only would NEEDING to use a phone be very uncommon, but phone’s are arguably the least secure digital devices in existence and catering to the fraction of a percent of users that have no way to access another type of device and indirectly making it easier for the general public to be lazy and use their phone instead of a computer would be irresponsible and work against their central goal of a secure operating system.
You mentioned you have a computer you can use. I’d highly recommend using that, or simply using a friend/family/library/university computer to download and burn the ISO. If security is of importance to you, it’s probably best to keep your phone compartmentalized from the devices you desire that security on.
I’m not saying that Qubes shouldn’t make things as user friendly as possible WHEN possible, but there is almost always a trade off between convenience and security and the focus in Qubes is security.
All I’m trying to get at here is I’m sure the Qubes team is doing everything they can to make the process as user friendly as possible while keeping security #1, there is almost certainly a reason why they haven’t already made the file drag and drop, and I couldn’t tell you their reasoning for the file size but I think it is fair for the storage hardware generously available today. And with network drivers in Qubes sometimes being difficult and not working out of the box, it is very nice to be able to install and use it before getting the network connection sorted out.
Regardless, if you adopt the mindset of learning the few reasonable extras needed to be secure, you will reap the benefits that most people never experience because they don’t take those few extra steps.
It’s not easy to identify nomenclature in the settings. My BIOS doesn’t have “SVM mode”, but it does provide an AMD-V option. The terms in the doc all have links pointing to wikipedia for better understanding, and it’s impossible to enumerate all possible phrases that MoBo manufactures are using to describe those CPU features. Sometimes the phrases are even inaccurate, like “VT” representing “VT-x”. So for the best accuracy and the least misunderstanding, it’s best to leave the doc as it is, and encourage users to seek vendor’s / peer’s help to understand the phrases in the BIOS.
If you are going to install Qubes on a computer ( aren’t you? ), you will have to firstly own a computer. Creating a installation media using phone is cumbersome, especially with such a heavy ( as you have stated ) ISO image. So why don’t you simply install a fedora, download Qubes iso and dd it? You can always dual boot for testing purpose. After confirming that things are working properly, you can then do a full-disk install.
And I believe this method avoided your fat32 size limit problem ( no matter why you are still constrained by that ancient fs ).
Edit: Ahhh, I was on the same wavelength as NoNamesWhereWereGoin
old filesystem constraint that very few people have dealt with in years
I think it’s still commonly used on 32gb-and-under SD cards and USB sticks (because it’s easy to implement and it’s universally readable or whatever). But I get your general drift – “get with the times!” – ok, maybe i’m a little behind in some ways.
It’s going to be slower over tor, or else you may be alerting your current or future fascist government to “maybe look into your affairs a little closer”.
ISO to USB method same for over decade
That’s also my point – maybe there’s no need for it anymore, because of UEFI. Is iso+dd way of distribution more secure than zip+unzip? You could check digests on a zip just as well.
“In addition to” , not “instead of” or “prioritize”. Hence “more flexible and user-friendly”. They can distribute a 10gb iso with all templates and a 3gb with just dom0+fedora, right?
I don’t think that’s good advice, i wouldn’t trust their security practices. The docs advise “Pick the most secure existing computer and OS you have available for downloading and copying the Qubes ISO onto the installation medium”.
Hey, Andrew, you are obviously a cool dude and your contributions to the community are much appreciated. In the OP, I only wanted to point out some areas for possible improvement. I did not mean to discourage or dispirit the documentation effort in any way. And if that is the effect, this will get added to my long list of life’s regrets.
If your computer supports Qubes at the moment you discover it, your topic doesn’t exist.
But, if not… My advice is don’t waste your time. Prepare yourself to sell your machine on ebay and invest that in a new one. Learn about what Qubes needs to run smoothly, bring 2 USB’s with you (one empty and one with Qubes ISO burnt to it with the third USB Fedora Live’s Mediawriter) and go to the store and test if it will install onto second, empty USB.
Look for the strongest CPU you are able to afford to yourself, and find one with the most USB controllers. Believe it or not, most of new computers will support Qubes out of the box, starting at soonest from Intel gen12 CPUs.
Read recent HCLs here and you’ll see. Don’t make lassie out of grandma.