search

QubesOS / qubes-issues

The Qubes OS Project issue tracker
https://www.qubes-os.org/doc/issue-tracking/
534 stars 47 forks source link

New installation from usb fails to boot #6447

Open tonym1995 opened 3 years ago

tonym1995 commented 3 years ago

Qubes OS version:

Qubes-R4.0.4-x86_64

Affected component(s) or functionality:

Trying to install Qubes onto a Dell Laptop 7280. Installation fails to boot. NOTE! The laptop has never had Qubes installed. This is the first installation. Installer fails to a root prompt.

Snippet of the log.

[ 14.748312] localhost kernel: scsi 3:0:0:0: Direct-Access USB SanDisk 3.2Gen1 1.00 PQ: 0 ANSI: 6 [ 14.750823] localhost kernel: sd 3:0:0:0: Attached scsi generic sg1 type 0 [ 14.752247] localhost kernel: sd 3:0:0:0: [sdb] 120176640 512-byte logical blocks: (61.5 GB/57.3 GiB) [ 14.753493] localhost kernel: sd 3:0:0:0: [sdb] Write Protect is off [ 14.754406] localhost kernel: sd 3:0:0:0: [sdb] Mode Sense: 43 00 00 00 [ 14.755138] localhost kernel: sd 3:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [ 14.765578] localhost kernel: sdb: sdb1 sdb2 [ 14.769624] localhost kernel: sd 3:0:0:0: [sdb] Attached SCSI removable disk [ 145.447257] localhost dracut-initqueue[506]: Warning: dracut-initqueue timeout - starting timeout scripts

[ 210.672480] localhost dracut-initqueue[506]: Warning: Could not boot. [ 210.673077] localhost dracut-initqueue[506]: Warning: /dev/root does not exist [ 210.698358] localhost systemd[1]: Starting Setup Virtual Console... [ 210.710360] localhost systemd[1]: Started Setup Virtual Console. [ 210.711984] localhost audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-vconsole-setup comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' [ 210.729662] localhost kernel: audit: type=1130 audit(1615262562.795:13): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-vconsole-setup comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' [ 210.714858] localhost systemd[1]: Starting Dracut Emergency Shell...

Steps to reproduce the behavior:

Expected or desired behavior:

Successful installation of Qubes is desired.

Actual behavior:

Installer rdsosreport.txt boot fails

General notes:

I have attached the full rdsosreport.txt The usb also has a second partition in fat32 format as suggested in other posts. This made no difference.

NOTE! This is a brand new install (not an update). I have not successfully installed Qubes yet. The installer itself fails to boot. rdsosreport.txt

I have consulted the following relevant documentation:

I am aware of the following related, non-duplicate issues:

rdsosreport.txt

andrewdavidwong commented 3 years ago

Can you please confirm that this hardware satisfies all the system requirements and that you have gone through the installation troubleshooting documentation?

mallorybowes commented 3 years ago

I'm having the same issue and I'm using a Lenovo T460s (20F9004FUS) that I picked off the Qubes HCL as one of the models that seemed to have full support. I've tried all suggestions from the Troubleshooting page as well as any forum sites I could find.

As referenced here, it looks like the internal NVME SSD isn't coming up as being recognized. (The USB drive containing the installation medium as well as other USB drives I've tried (one 3.5 sata and one NVME SSD) are both recognized when I plug them in while waiting for dracut to move on to the next installation step. Not sure if these are normal debug messages for the installation boot but it's basically all I've seen that looks out of place:

systemd-gpt-auto-generator: EFI loader partition unknown, exiting. systemd-gpt-auto-generator: (The boot loader did not set EFI variable LoaderDevicePartUUID.)

A quick googling on those error messages brings up this fedora bug and this one. Not sure if it's related or not.

Other things to keep in mind: only UEFI boots (legacy does not), I've tried 4.0.4 and the 4.1 alpha, I used the old bios and upgraded it (laptop had v 1.2, upgraded to v 1.5), I've tried every combination of enabling / disabling the security chip, SGX, and VT / VT-d.

Thanks!

mallorybowes commented 3 years ago

Final edit: Yeah, Imma gonna leave this up so the interwebs can see what not to do when troubleshooting something. See the next comment below... :-)

Ok, some more updates on what I've tried:

I'm really thinking it has something to do with that EFI path or there's some bios setting combo I'm missing but I haven't been able to figure out a way to get the installer to work yet... :-/ Def any help would be appreciated...

Edit: I did some sleuthing through the debugs and this seems like a logical potential issue:

  • command -v lvm
  • lvm pvdisplay WARNING: locking_type (4) is deprecated, using --sysinit --readonly.
  • lvm vgdisplay WARNING: locking_type (4) is deprecated, using --sysinit --readonly.
  • lvm lvdisplay WARNING: locking_type (4) is deprecated, using --sysinit --readonly.
  • command -v dmsetup
  • dmsetup ls --tree No devices found

There was something I tried where I changed the locking type on the installer USB to 1 but I can't find where I found that issue to try. If I can find the link, I'll document it here.

Anyhoo, heading down this rabbit hole...

mallorybowes commented 3 years ago

Ok, I'm an idiot... It had to do with the USB creation. The process I was using to create the 4.0.4 USB from the ISO was the issue. (I was using WoeUSB on another machine to create the boot device. I saw problematic block reads coming from the USB device while loading other Linux distros so I was like, well, it's a cheap USB that's failed so I'll use another. Same errors on the next one. And on the one after that. I checked the Qubes Installation page and used the recommended dd command and what do you know? It worked. After that, I tried creating / installing both 4.0.4 and 4.1 alpha which worked. So yeah, I'm an idiot...

Idk if this is the same issue the op had that was producing these same errors but I'm guessing that's what it is. So, op, try using the recommended USB creation commands and see if it works for you. I'll quote it out here for those that might follow...

If you choose to use a USB drive, copy the ISO onto the USB device, e.g. using dd:

$ sudo dd if=Qubes-RX-x86_64.iso of=/dev/sdY status=progress bs=1048576 && sync Change Qubes-RX-x86_64.iso to the filename of the version you’re installing, and change /dev/sdY to the correct target device e.g., /dev/sdc). Make sure to write to the entire device (e.g., /dev/sdc) rather than just a single partition (e.g., /dev/sdc1).

On Windows, you can use the Rufus tool to write the ISO to a USB key. MediaTest is not recommended. Be sure to select “DD image” mode (after selecting the Qubes ISO):

One last thought about this issue: I'm thinking that if ppl get the dracut script timeout error in the future, the first troubleshooting step should be to direct them to the Qubes installation page to confirm they created the USB according to those instructions. It's waaaaay too easy to go down a technical rabbit hole here with all the interesting Linux problems that get thrown up for this issue.

(I promise my future posts about qubes will contain novel and interesting security problems and next time, I'll thoroughly discount my learned Linux knowledge and will RTFM before crying to Dad... :-) )

tonym1995 commented 3 years ago

Hi mallorybowes,

Great post. I followed your dd command and the installation got to the start of the installation where you select the language. That is further than I have ever got before. Thanks :-)

I can not test further until I get another hard drive. I'll post again to let everyone know if the installation is successful. Hopefully it will be.

Good luck everyone.

mallorybowes commented 3 years ago

Ugh, sorry it didn't work out for you, @tonym1995. I was so certain that must've been the problem based on my weekend's experience. But since the expression of that bad USB install disc is seemingly hardware errors, it makes it hard to distinguish between the two. I hope you don't have a legit hardware issue and you can eventually figure out what's going on... :'-(

tonym1995 commented 3 years ago

Hi mallorybowes,

You were correct!!!

My initial problem was a failure to boot into the installation as shown in my initial log snippet below. Following your advice fixed that problem. Once I have a new hard drive (so I do not overwrite my current Linux installation) I will continue with the installation of Qubes.

So you were correct and using the dd command as you suggested allowed the installation to start correctly. I should be getting a new drive tomorrow and will do the full installation. I will let you know how installation goes in the next couple of days. :-)

mallorybowes commented 3 years ago

@andrewdavidwong Hey, Andrew! Just thought I'd make another plug to possibly add this "situation" to the Installation Troubleshooting doc. Doing my research and debugging, I feel like I saw enough of the "dracut timeout" posts as well as the error messages produced by this situation can easily be misinterpreted to be other hardware / software issues. My rough cut of that section on the troubleshooting page is below.

Edit: Andrew, looks like you can also close this issue and we all love that... :-)

Thanks, y'all!

(And @tonym1995, so glad you were able to get it to rock! Thanks for putting up the initial bug request and allowing me to waste my entire weekend running down the error messages... ;-D

Proposed entry on the troubleshooting page (italics are the proposed verbiage):

Change the method you used to write your ISO to a USB key: Some people use the dd command (recommended), others use tools like Rufus, balenaEtcher or the GNOME Disk Utility. If installation fails after using one tool, try a different one. For example, if you are facing trouble installing Qubes after writing the ISO using Rufus, then try using other tools like balenaEtcher or the dd command. In case the boot partition is not set to “active” after copying the ISO, you can use some other tool like gparted on a Linux system to activate it. If you experience a "dracut timeout" and the installation drops to a dracut shell during the installation, please verify the USB was created with one of the verified procedures listed on this page.

andrewdavidwong commented 3 years ago

@andrewdavidwong Hey, Andrew! Just thought I'd make another plug to possibly add this "situation" to the Installation Troubleshooting doc. Doing my research and debugging, I feel like I saw enough of the "dracut timeout" posts as well as the error messages produced by this situation can easily be misinterpreted to be other hardware / software issues. My rough cut of that section on the troubleshooting page is below.

Edit: Andrew, looks like you can also close this issue and we all love that... :-)

Thanks, y'all!

(And @tonym1995, so glad you were able to get it to rock! Thanks for putting up the initial bug request and allowing me to waste my entire weekend running down the error messages... ;-D

Proposed entry on the troubleshooting page (italics are the proposed verbiage):

Change the method you used to write your ISO to a USB key: Some people use the dd command (recommended), others use tools like Rufus, balenaEtcher or the GNOME Disk Utility. If installation fails after using one tool, try a different one. For example, if you are facing trouble installing Qubes after writing the ISO using Rufus, then try using other tools like balenaEtcher or the dd command. In case the boot partition is not set to “active” after copying the ISO, you can use some other tool like gparted on a Linux system to activate it. If you experience a "dracut timeout" and the installation drops to a dracut shell during the installation, please verify the USB was created with one of the verified procedures listed on this page.

In case you (or any others reading this) are not already aware, the documentation is a community effort, and everyone is welcome to contribute. (That's how things like this get updated!) So, if you'd like to get involved with the project, this is a great way to do it. You can read more about how to submit documentation changes here:

https://www.qubes-os.org/doc/doc-guidelines/

tonym1995 commented 3 years ago

Hi mallorybowes,

Sorry for taking up your weekend :-(

The installation was a success as you can see from the attached photo. Unfortunately it will not boot saying "No Boot Device Found.". I tried changing the bios from legacy boot which boots Linux Mint fine to UEFI but it made no difference.

Any suggestions?

Maybe I should try a stable version instead.

Many thanks for the feedback you have already given. Have a great day. :-)

20210505_183400 20210505_184032 20210506_085028

mallorybowes commented 3 years ago

@andrewdavidwong Gotcha. I'll take a look at how to contrib docs over there. Thanks!

@tonym1995 I swear I read something that was similar to what you're seeing. (Installer goes through a full install and then doesn't boot.) I'll see if I can dredge that up and add to the thread...

tonym1995 commented 3 years ago

@mallorybowes I have found a possible solution at https://www.qubes-os.org/doc/uefi-troubleshooting/

I will try the solution below tonight after work. I hope for success. :-)

Boot device not recognized after installing Some firmware will not recognize the default Qubes EFI configuration. As such, it will have to be manually edited to be bootable. This will need to be done after every kernel and Xen update to ensure you use the most recently installed versions.

Copy the /boot/efi/EFI/qubes/ directory to /boot/efi/EFI/BOOT/ (the contents of /boot/efi/EFI/BOOT should be identical to /boot/efi/EFI/qubes besides what is described in steps 2 and 3):

cp -r /boot/efi/EFI/qubes/. /boot/efi/EFI/BOOT Rename /boot/efi/EFI/BOOT/xen.cfg to /boot/efi/EFI/BOOT/BOOTX64.cfg:

mv /boot/efi/EFI/BOOT/xen.cfg /boot/efi/EFI/BOOT/BOOTX64.cfg Copy /boot/efi/EFI/qubes/xen-*.efi to /boot/efi/EFI/qubes/xen.efi and /boot/efi/EFI/BOOT/BOOTX64.efi. For example, with Xen 4.8.3 (you may need to confirm file overwrite):

cp /boot/efi/EFI/qubes/xen-4.8.3.efi /boot/efi/EFI/qubes/xen.efi cp /boot/efi/EFI/qubes/xen-4.8.3.efi /boot/efi/EFI/BOOT/BOOTX64.efi

DemiMarie commented 3 years ago

Hi mallorybowes,

Sorry for taking up your weekend :-(

The installation was a success as you can see from the attached photo. Unfortunately it will not boot saying "No Boot Device Found.". I tried changing the bios from legacy boot which boots Linux Mint fine to UEFI but it made no difference.

Any suggestions?

Maybe I should try a stable version instead.

Many thanks for the feedback you have already given. Have a great day. :-)

20210505_183400 20210505_184032 20210506_085028

That message indicates that the computer is trying to PXE (network) boot, which is very insecure. Can you remove the NIC from the boot order and retry?

tonym1995 commented 3 years ago

@DemiMarie Thanks for your suggestion. I changed the boot option to USB first and then the SATA hard drive. It did not solve the boot problem.

@mallorybowes SUCCESS!!!!!

I could not wait so I reinstalled from the USB and after the installation was complete I pressed Ctrl+Alt+F2 to get the console. I attempted to follow the solution I mentioned before but the files were not there so I typed reboot.

The installation appeared to do a couple of things I did not see after pressing the Reboot button after previous installations. The laptop rebooted and then flashed something about configuring Hypervisor (or something like that. It was very quick.) Then it proceeded to boot into an initial system configuration. I went through that and it booted into Qubes. :-)

The only thing I did different apart from change the bios boot sequence was to reboot from the command line. I don't know if that was the solution or not but I am ecstatic it is finally installed and working.

Thanks for all your help :-) 20210506_101736

mallorybowes commented 3 years ago

@tonym1995 So glad you got it working! :-) (btw, I was joking with you about wasting my weekend earlier on tracking it down. I was going to do it anyway since I was suffering from the same problem and I was trying to be a bit jokey in my reply. Yeah, my humor is a bit dry at times. {Damn Brit upbringing...}).

I'm glad we figured it out and I'll submit the documentation upgrade request so we can help the next ppl this happens to! :-)

tonym1995 commented 3 years ago

@mallorybowes I too came from a Brit upbringing so I get the humor. All good. :-)

The crucial bit that got me going with the installation was your dd command writing to /dev/sdY (which was /dev/sdb for me). I had tried other dd commands but I always ended up with the dracult problem. I recommend that command is put as the preferred way of creating the USB from the iso image in the documentation.

If possible the guys who work on the installation could investigate if there is any difference in typing reboot from the command line and pressing the Reboot button. What ever the reason it finally worked after multiple installations. I used all the default settings.

Thanks again. Have a great day. :-)

andrewdavidwong commented 3 years ago

The crucial bit that got me going with the installation was your dd command writing to /dev/sdY (which was /dev/sdb for me). I had tried other dd commands but I always ended up with the dracult problem. I recommend that command is put as the preferred way of creating the USB from the iso image in the documentation.

Isn't that what it already says? In any case, it sounds like @mallorybowes will take care of it. Thanks, Mallory!

Reopening for the doc addition.

yorickdowne commented 2 years ago

Something for the docs: Rufus in ISO mode causes this issue; Rufus in dd mode works fine.

andrewdavidwong commented 2 years ago

Something for the docs: Rufus in ISO mode causes this issue; Rufus in dd mode works fine.

In case you (or any others reading this) are not already aware, the documentation is a community effort, and everyone is welcome to contribute. (That's how things like this get updated!) So, if you'd like to get involved with the project, this is a great way to do it. You can read more about how to submit documentation changes here:

https://www.qubes-os.org/doc/how-to-edit-the-documentation/

You may also be interested in the documentation style guide:

https://www.qubes-os.org/doc/documentation-style-guide/

coffeepenbit commented 2 years ago

I'm getting this issue with by both installing using the provided dd command and via Rufus w/ dd selected.

I've confirmed I meet the minimum system requirements, verified the ISO, tried multiple USB sticks, tried with both BIOS/UEFI.

Edit: this is the same issue I am having https://forum.qubes-os.org/t/qubes-4-1-all-usb-devices-unusable/10920/2

coffeepenbit commented 2 years ago

I can confirm that it works in the 4.0 release but not 4.1, similar to the forum thread I linked.

/dev/mapper/qubes_dom0-root does not exist /dev/qubes_dom0/root does not exist /dev/qubes_dom0/swap does not exist Crypto LUKS UUID not found

It looks like I’ll need to hold off on using Qubes OS as the 4.0 is not longer supported come August, and I don’t want to be in a position where I can’t move to a newer release.

DemiMarie commented 2 years ago

@coffeepenbit what hardware are you running on?

coffeepenbit commented 2 years ago

@DemiMarie

Let me know if you need any other info

Thanks for the prompt reply

itaishmueli commented 2 years ago

I think I am facing a similar issue to @coffeepenbit . system details:

After following the recommendation given here #7570 I managed to get to the graphical installer and complete the installation by adding dom0_max_vcpus=1 dom0_vcpus_pin to the cmd in grub.

Notable changes:

After that, the first boot configuration failed. It froze on templateVM creation, and after some time the screen went black. short press on the power button woke up the screen, but it was still completely unresponsive to keyboard and mouse. After rebooting and adding the mentioned params in grub, I managed to boot in, and the journalctl of the previous boot shows the same problematic logs as with the installation.

After reinstalling and booting each time with those params I do manage to complete the installation and configuration. But I now can't manage to get a network connection...

coffeepenbit commented 2 years ago

but it was still completely unresponsive to keyboard and mouse.

I had the same issue w/o trying the above.

"dom0_max_vcpus=1 dom0_vcpus_pin" does this have any negative impact? I'll give it a shot.

Edit: @itaishmueli This resolved my issue, thank you so much! I spent many, many hours trying to figure this out

You don’t need to do this manually each time. You can set it in the grub cfg under /etc/. The one you edit depends if you used UEFI or legacy boot.

I also was able to boot when dom0_max_vcpus=2. I believe this is because it’s still the same physical CPU core due to hyper threading.

The post-installation configuration took a long time. The progress bar stopped moving but the text below it updated eventually.

I am also experiencing network issues.

The common denominator seems to be ryzen 5xxx

itaishmueli commented 2 years ago

I'm experiencing network issues as well, and general slugish-ness of the ui. maybe setting dom0_max_vcpus=2 would resolve the latter.

coffeepenbit commented 2 years ago

I was not experiencing sluggishness with vcpus=2. I recommend trying that in your grub cfg file.

I’m hoping these are unrelated issues as it may mean the workaround you posted is invalid otherwise.

I’m connected via Ethernet to my mobo, and the connection icon on the GUI keeps spinning. This seems promising: https://forum.qubes-os.org/t/no-internet-network-icon-spins-but-does-not-connect-ethernet/2162

I’ll update if I find a solution.

I hope the Qubes team considers reviewing the pertinent timeout troubleshooting shooting entry from as this doesn’t appear to be only due to improperly formatted USBs.

itaishmueli commented 2 years ago

according to this page ryzen 5000 series isn't supported on xen < 4.15, and according to the release notes of qubes 4.1 it uses xen 4.14. Idk where they got the info on support issue with xen. couldn't find reference to it anywhere else. Depending on how difficult it is to upgrade to 4.15, I think this might be a dead end.

Hopefully the network issues turn out to be unrelated...

coffeepenbit commented 2 years ago

I couldn’t see mention of Ryzen desktop skus on the Qubes OS HW list — at least, nothing ending with “X”

I wonder if there are plans for Qubes OS to update to 4.15 in the near future? At least, I think many people are using Zen 3 processors…

DemiMarie commented 2 years ago

according to this page ryzen 5000 series isn't supported on xen < 4.15, and according to the release notes of qubes 4.1 it uses xen 4.14. Idk where they got the info on support issue with xen. couldn't find reference to it anywhere else. Depending on how difficult it is to upgrade to 4.15, I think this might be a dead end.

Hopefully the network issues turn out to be unrelated...

I suspect the needed patches can be backported.

itaishmueli commented 2 years ago

I couldn’t see mention of Ryzen desktop skus on the Qubes OS HW list — at least, nothing ending with “X”

I wonder if there are plans for Qubes OS to update to 4.15 in the near future? At least, I think many people are using Zen 3 processors…

yeah sorry, I could have been more specific.

On TongFang GM5ZN7W: Ryzen 5000 series not supported by Xen < 4.15

itaishmueli commented 2 years ago

according to this page ryzen 5000 series isn't supported on xen < 4.15, and according to the release notes of qubes 4.1 it uses xen 4.14. Idk where they got the info on support issue with xen. couldn't find reference to it anywhere else. Depending on how difficult it is to upgrade to 4.15, I think this might be a dead end. Hopefully the network issues turn out to be unrelated...

I suspect the needed patches can be backported.

I'll give it a look tomorrow, but since I couldn't find any reference to it outside of qube's hcl (not even in xen's release notes) I suspect it will be a bit difficult to find. let's hope the commit messages are descriptive

coffeepenbit commented 2 years ago

I was not able to find anything outside of those Qubes forum posts that indicate Xen 4.15 may have better support for Zen 3 desktops.

Note, those are also mobile CPUs in that post. Not sure if that would make an impact; they were having a different error.

GSF1200S commented 2 years ago

I have the same issue.

I can't get into the installer even with the suggestions in this thread. Perhaps if I left it overnight or whatever. I get lines similar to:

nvme nvme0: I/O 4 QID 0 timeout, completion polled

If I run:

dom0_max_vcpus=1 dom0_vcpus_pin

I don't recall those errors popping up but it still doesn't load. FWIW Fedora 36 works (almost) perfect on this hardware; the only exception is an I/O sensor (for fan speed, voltages, mobo temps, etc) that needs to be force loaded but works after that.

I was going to ask but didn't really know where to ask it: will a point release come later that includes Xen 4.15 or better? I'd really hate to wait until Qubes 4.2 to use it on this hardware :P

GSF1200S commented 1 year ago

Just for everyone's information, a few days ago I found out about @fepitre's weekly builds of Qubes OS and decided to try the "kernel-latest" option- booted right into the installer!

I wouldn't be surprised if the issues reported in this thread are fixed once a new ISO is released given that "kernel-latest" will be included in the next 4.1 ISO (as per https://github.com/QubesOS/qubes-issues/issues/5900).

coffeepenbit commented 1 year ago

Thanks for the heads-up @GSF1200S ! I'll give it a shot when it is available. I've been eager to use Qubes on my desktop.

seonwoolee commented 1 year ago

I too am facing this issue

The Threadripper Pro 5975WX's CPU cores uses the same architecture as the Ryzen 5000 series CPUs, so any Xen incompatibility for Ryzen 5000 probably applies to the Threadripper Pro 5975WX

Without changing the GRUB options, the installer can't boot and I see errors along the lines of

nvme nvme0: I/O 4 QID 0 timeout, completion polled

Max number of devices this xHCI host supports is 64 usb usb1-port4: couldn't allocate usb_device

When I try the suggested options of

dom0_max_vcpus=1 dom0_vcpus_pin

I am able to run the installer version Qubes-4.1.20221231-kernel-latest-x86_64.iso from the weekly releases server but not the current release 4.1.1 nor Qubes-4.1.20230114-x86_64.iso nor Qubes-4.1.20230128-x86_64.iso. @GSF1200S which installer version worked for you?

I was able to install Qubes, but like itaishmueli and coffeepenbit it will only boot with dom0_max_vcpus=1 dom0_vcpus_pin set.

I haven't tested the network yet

GSF1200S commented 1 year ago

I have a working solution for Qubes 4.1 finally :D And apologies @seonwoolee as I haven't been on github recently!

I waited until the recent release candidate came out (4.1.2), and selected the bottom option- to boot with a more recent kernel. It didn't boot hanging just as before, but then I remembered that I had different UEFI options set before. Long story short after a lot of trial and error, I figured out that if I had "SMT" set to "Auto", it would lock on booting the installer. This surprises me since I think the Qubes team disables hyperthreading by default anyways so not sure why this would have an effect. Incidentally even after installing, Qubes will not boot with "SMT" set to "Auto"- I have to have it set to "Disabled."

Once I set "SMT" to "Disabled" and used the latest kernel option in the installer Grub menu, it booted into the installer, installed without issue, and has since worked fine :D

I have no options like "dom0_max_vcpus=1 dom0_vcpus_pin" set- it works with a normal kernel line (just usb stuff added in my case). The only change from my comment above is that I now have 64GB Crucial DDR4 ECC memory instead of just 32GB.

The key settings that must be set for me: IOMMU to enabled, SVM enabled, SMT disabled, Secure Boot disabled. I also do not have CSM enabled. Any questions, just ping me!

EDIT It's worth emphasizing that using the latest kernel option in the installer will ensure that you use that in your actual install. Perhaps your issues requiring you to set kernel commandline options are because you are using the older kernel? Your comment seems to suggest that you are using the newer one too, but I thought I'd add this edit to make sure. Also, my network works fine just FYI..