December 20, 2019 9:13 PM, "Claudia" <claud...@disroot.org (mailto:claud...@disroot.org?to=%22Claudia%22%20<claud...@disroot.org>)> wrote: December 20, 2019 6:05 PM, brendan.h...@gmail.com (mailto:brendan.h...@gmail.com) wrote: On Friday, December 20, 2019 at 9:29:55 AM UTC-5, Claudia wrote:December 19, 2019 12:13 AM, "Claudia" <clau...@disroot.org (javascript:false)> wrote:
> This is R4.1 build 20191013
>
> It works pretty well, definitely better than 4.0, but there are some weird
> boot issues. If I let it
> boot with everything as default, it will boot loop before reaching the disk
> password screen. I
...Looks like rd.qubes.hide_all_usb is what's causing it to crash. When I
remove it, it boots fine with the graphical splash and passphrase prompt.
Another AMD Ryzen user mentioned having the same problem a while back.
Something about AMD's IOMMU grouping of USB controllers, or something.
Unfortunately, (my understanding is) that exposes the dom0 to the USB ports.
Even if you have a sys-usb, dom0 is still exposed temporarily on boot.
Thanks for the tip. I actually thought removing that parameter just simply
disabled USB Qube functionality and attached all devices to dom0, but I guess
that's only when sys-usb is not running. Once sys-usb is running, it takes over
the USB controllers from dom0, I guess. It's just that they're exposed before
sys-usb starts, in that case.
It would be nice to have working, but I've never had a USB Qube before, even on
my old machine, so I haven't lost anything. I don't use a lot of USB devices,
and it's not a big part of my threat model. I'll play around with it when I
have a chance.
I realized I had disabled autostart for all VMs including sys-usb to speed up
boot time (systemctl disable sys-{net,usb,firewall,whonix}@qubesvm.se
(mailto:whonix...@qubesvm.se)rvice), and I hadn't actually run sys-usb at all
since then. I decided to start sys-usb while the system was running, and
everything went to hell: the screen froze, audio stopped, even the caps lock
light wouldn't come on.
So this isn't limited to hide_all_usb, just USB controller passthru in general
on this machine.
So I reinstalled 4.0.2-rc3, once again, this time without USB Qube, and
everything works (except suspend/resume which doesn't work anywhere except
Fedora 30, not even F29 iirc), including audio and amdgpu without nomodeset.
All this time I was blaming it on the old-ness of 4.0, but it was hide_all_usb
all along. The only reason I tried getting rid of hide_all_usb in 4.1 is
because the nomodeset trick didn't work in 4.1 so I had to continue
troubleshooting, whereas in 4.0 it worked and I moved on. And also grub makes
it way more convenient to modify boot options.
So in summary, for 4.0 and 4.1 alike, everything works except suspend/resume,
as long as you don't set up a USB Qube. I attached updated HCL reports to
reflect this, and will update them as I do more testing.
I'm going to try and figure out some of this IOMMU grouping stuff and start
another thread about this issue. But like I said, I never had a USB Qube
before, so I'm not going to miss it.
--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/bbffffdf183debac9338e0f46d32bbcb%40disroot.org.
Qubes-HCL-Dell_Inc_-Inspiron_5575-20191220-220355.yml
Description: Binary data
Qubes-HCL-Dell_Inc_-Inspiron_5575-20191221-021654.yml
Description: Binary data
