Greetings! I recently had a use case and reason to order the beefy System76 Oryx Pro model that was just released July 21! I placed the order yesterday and am eagerly awaiting any update on the assembly/delivery!
I chose the maximum specs for performance and was wondering if anyone had some existing knowledge concerning the System76 machines and any tweaks that may be necessary. Here is my current list of posts to review/attempt/use:
It was successfully installed, although I did not have a mouse. The installation and afterward had incredibly glitchy screen display - a lot of tearing. I cannot seem to get the NVIDIA drivers to installed, as I keep getting an error when attempting to make the module with
sudo make module IGNORE_XEN_PRESENCE=y CC="gcc -DNV_VMAP_4_PRESENT -DNV_SIGNAL_STRUCT_RLIM"
Error after entering the appropriate src kernels folder is:
/bin/sh: -c: line 0: syntax error near unexpected token `('
/bin/sh: -c: line 0: `if [ "gcc (GCC) 10.3.1 20210422 (Red Hat10.3.1-1)" != ""gcc (GCC) 10.3.1 20210422 (Red Hat 10.3.1-1""]; then \`
make[1]: *** [Makefile:1724: prepare] Error 1
make: *** [Makefile:82: modules] Error 2
then it exits.
I’m trying to get this working while continue my normal, daily job, so this machine won’t be able to be down for so long If anyone has some good ideas, I can install Qubes onto another SSD for testing at a later date
I’m going to miss Qubes - especially the compartmentalization - every day, and I’ll keep an eye on the forums for other oryp9 model information.
The nouveau drivers should be able to at least get rid of the tearing. Although you won’t be playing Cyberpunk inside Qubes OS any time soon, unfortunately…
The Qubes OS kernel patches probably have code that conflicts with nVIDIA’s open-source* module. That’s likely why your builds are failing.
In all honesty, I’d be very careful about installing proprietary nVIDIA software inside dom0. We don’t fully know exactly what it does.
But security concerns aside, you shouldn’t actually need it. The nouveau drivers should at least give you a “working” display…
* nVIDIA’s definition of “open-source” seems to be “we will release source code that calls parts of the driver that are still proprietary”
I meant that during install, and before a few reboots (and probably the kernel-latest package), the pointer stayed dead-center in the middle of the screen and responded to zero input from the touchpad. After the latest kernel and some updates, it just started working I did not check for detection originally because I had a bigger issue of not being able to see the screen very well. I’m not sure what the best/correct way to explain it was, but the screen was refreshing from top to bottom or bottom to top with a wiping horizontal line - like very, very, very slow refresh rate e.g. 1 full 1920x1080 update per 3-4 seconds or so.
Once I get a working environment on it, I’m going to put another NVMe in and re-install Qubes. I don’t care to game on the laptop, but I am hoping to be able to use the GPU-passthrough for some 3D renders / modeling / CAD work eventually I would actually be totally fine with not installing NVDIA to dom0, I was just rushing through random attempts, as it was a fresh install with no data on it (and was starting to expect to not get it working as I wanted during that attempt )
Agreed, I am actually planning on not attempting the driver-installation in dom0 anymore anyway
I will keep us posted!
Also, while I’m typing here, I cannot seem to figure out how to get the HCL report sent to the google group. I keep getting a delivery failure
That happens on the most recent Intel Apple hardware too. The older kernels just don’t seem to know how to use their internal trackpads. But that’s awesome that you got it working!
Well, if you can get dom0 to use the integrated graphics in your i9, you could potentially pass the nVIDIA GPU into a VM, install the proprietary nVIDIA drivers in there, and then use it for your renderings.
Do you care to post it as a thread in this forum with the HCL tag? That should work.
Windows Tools Won't Download - #13 by qubesn00b
Somehow I was also affected by this odd thing… I noticed near some of the first couple boots, it updated or installed qubes-mgmt-salt-dom0 and something else I cannot remember right now - like “stone” or “onyx” or something in the name. After those successfully installed I was unable to install anything else viz. i3, i3-settings-qubes, and qubes-windows-tools
So I “successfully” used it all day today! I then wanted to reboot for some reason near the end of the day. After the reboot, by mouse is undetected again. I noticed that a PTS touchpad is detected but that’s not the one that works. When the touchpad is working, there are two other detected touchpads.
I also somehow lost the ability to properly use the Phillips 49" ultra wide that had worked for me all day long now it only “mirrors” the laptop overlapping. Maybe it’s because I tried using i3 after the reboot… But I don’t think it worked in XCFE either. I need to take a break for now but hope to find some useful posts in the forums later this evening.
I really am going to have to throw in the towel for now [on this machine]. I would like to do work on it, and I simply cannot do tasks efficiently with the current issues
the touchpad is not detected reliably (seems like ~50-60% of the time it is)
when it is detected, I cannot save any settings like speed or “reverse scroll direction”
this is in i3 and XFCE
the secondary display is now working 0% of the time - USB-C and HDMI attempted
no WiFi controls that I can find in i3, so even having this machine to the side to try working on / fixing is inconvenient, as it also needs the network cable usually used for the “main” machine at this workspace.
I’m looking forward to getting my Librem14 back from the repair depot, as Qubes ran on that machine most excellently.
So hopefully I’m really back for good. I had enough time to put a second drive in this machine, so that I can get Qubes working peacefully and still get work done lol.
Starting fresh, I got this error on the first boot, post install and “second install,” JUST before the user login screen
[Dom0] Error
['systemctl','start','qubes-vm@sys-usb.service'] failed:
stdout: ""
stderr: "Job for qubes-vm@sys-usb.service failed because the control
process exited without error code.
See "systemctl status qubes-vm@sys-usb.service" and "journalctl -xe" for
details.
"
OK
I updated the X11 conf file as noted above.
I am not going to update to kernel latest unless I just have to, as I am still experiencing no available touch pad.
The two initial dom0 updates are “qubes-mgmt-salt-dom0-update” and “qubes-rpm-oxide.” I suspect that one of these packages may prevent me from installing packages in the future, and I will need to run the steps listed above in order to get anything installed into dom0… We’ll see.
ONWARD
::EDIT::
The errors, if it will let me upload
what seems to be useful from this one:
dom0 qvm-start[22181]: Start failed: internal error: Unable to reset PCI device 0000:00:14.0: internal error: Unable to reset PCI device 0000:00:0d.2: internal error: Unable to reset PCI device 0000:0:d.0: internal error: libxenlight failed to create new domain 'sys-usb', see /var/log/libvirt/libxl/libxl-driver.log for details
dom0 systemd[1]: qubes-vm@sys-usb.service: Main process exited, code=exited, status=1/FAILURE
dom0 systemd[1]: qubes-vm@sys-usb.servie: Failed with result 'exit-code'.
This one appears to have nothing useful, but here is the yellow line:
dom0: systemd[1]: Configuration file /etc/systemd/system/qubes-vm@sys-usb.service.d/50_autostart.conf is marked world-inaccessible. This has no effect as configuration data is accessible via APIs without restrictions. Proceeding anyway.
A reboot sent me to a frozen boot screen at “hold until boot process finishes up…”
Reinstall I guess…
Maybe I do need kernel-latest
::EDIT::
A reinstall + intel.conf = “Hold until boot process finishes up…”
Reinstall
kernel-latest and intel.conf file are needed.
I noticed that for some reason this time I do not have a sys-usb; they are all attached to dom0 (and I did not change any settings for it in the post-install). I did uncheck the box for personal , work, and vault
Another oddity - the clock was off by around 8 hours even though it had Internet during install and I set the timezone correctly during install:
This error was VERY weird, as it almost seemed like this user over here was potentially having the same strange issue - where they would try reinstalling literally at a different time of day e.g. 9AM instead of 9PM! Perhaps this is a bunch of HocusPocusCoincidence, but…
I am currently sitting here with a successful install and a successfully started sys-usb qube and a detected and working mouse! I did not do anything differently that I can tell - this is probably my 4th or 5th install, and the strange thing is the each time, the result is random i.e. sometimes the mouse works (usually not), sometimes there is no sys-usb qube (sometimes there is).
I’m afraid to make any changes or reboot!
I’m going to cruise back through my old posts (uploaded from my cell phone) and clean up the picture-errors into actual text
Would anyone have a suggestion or certain order of steps or logs to check, so that I can move forward slowly?
Last time I got far enough to use it, I put in the X11 .conf file, and it hung on the Hold until boot process finishes up… message, which required a reinstall, again
This probably confirms that I need kernel-latest installed.
Also for reference, I see the mouse being detected:
input: ELAN0412:00 04F3:316F Mouse as /devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-0/i2c-ELAN0412:00/0018:04F3:316F.0001/input/input10
input: ELAN0412:00 04F3:316F Touchpad as /devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-0/i2c-ELAN0412:00/0018:04F3:316F.0001/input/input12
hid-multitouch 0018:04F3:316F.0001: input,hidraw0: I2C HID v1.00 Mouse [ELAN0412:00 04FD:316F] on i2c-ELAN0412:00
Is this something that is already known or maybe it doesn’t matter?
systemd[1]: /usr/lib/systemd/system/usbguard.service:15: PIDFile= references a path below legacy directory /var/run/, updating /var/run/usbguard.pid -> /run/usbguard.pid; please update the unit file accordingly
I certainly noticed that if you place the X11 conf file BEFORE updating to kernel-latest, you will get the Hold until boot process finishes up... message, BUT if you do the updates along with the reboots, and THEN add the file, it works just fine.
The problem I see, is that for some reason that seems to make the touchpad stop working. So with my current scenario of testing, that simple “Intel Graphics” X11 conf file blocks my touchpad for some reason. I am currently rebooting with the file removed to see if the screen tearing does come back AND the touch pad is re-recognized.
SOME CONFIRMATION: I now have no-screen-tearing AND touchpad working! (persistent through three reboots so far)
This worked for me; Your Mileage May Vary
Run standard install and reboot+post-install-setup by painfully making my way through the slow moving screen “refreshes?” using an external mouse or Alt+shortcuts
Upon first logon, update to the latest kernel (I updated for my VMs also, for consistency in kernel while testing): sudo qubes-dom0-update kernel-latest kernel-latest-qubes-vm REBOOT
Upon next logon, the mouse should still be working with tearing screen; I added this file, followed by a REBOOT: sudo vim /etc/X11/xorg.conf.d/20-intel.conf
Upon next logon, my screen was no longer tearing, but my touchpad was not detected under xinput. move the 20-intel.conf file out of the xorg directory: sudo mv /etc/X11/xorg.conf.d/20-intel.conf ~/. REBOOT
Upon next logon, copy the 20-intel.conf back to X11 directory: sudo cp ~/20-intel.conf /etc/X11/xorg.conf.d/. Log out (reboot was not necessary) log back in
I’m not sure what would be of value here, so here is what sticks out to me from dmesg in sys-usb
Booted with the nomodeset parameter. Only the system framebuffer will be available.
Unknown kernel command line parameters "rd_NO_PLYMOUTH", will be passed to user space.
...
cpu 0 spinlock event irq 52
...
cpu 1 spinlock event irq 57
...
fail to add MMCONFIG information, can't access extended PCI configuration space under this bridge.
...
cevice-mapper: core: CONFIG_IMA_DISABLE_HTABLE is disabled. Duplicate IMA measurements will not be recorded in the IMA log.
...
db_root: cannot open: /etc/target
...
piix4_smbus 0000:00:01.3: SMBus Host Controller not enabled!
Good state: mousepad is working and screen is not tearing
change to i3 at logon
use it successfully
reboot
no touchpad working - it is obvious as soon as logon screen loads
logon to i3 [with no mouse] in order to allow external mouse to dom0
logout → change to XFCE → logon → reboot from Log Out menu
touchpad working [for this boot].
(I have now replicated this exact cycle twice in a row - 4 power cycles)
It seems that after a power cycle, if the last logon session was i3, the touchpad is not successfully recognized/registered/whatever-the-correct-term-for-what-is-happening-is upon the next boot
This was grabbed using journalctl -o short-precise -k -b -1 -p 4
-- Logs begin at Wed 2022-08-10 10:10:59 CDT, end at Thu 2022-08-11 15:01:30 CDT. --
Aug 11 03:45:29.001177 dom0 kernel: ACPI BIOS Warning (bug): Incorrect checksum in table [BGRT] - 0x24, should be 0x5F (20211217/tbprint-174)
Aug 11 03:45:29.001320 dom0 kernel: cpu 0 spinlock event irq 121
Aug 11 03:45:29.001394 dom0 kernel: cpu 1 spinlock event irq 131
Aug 11 03:45:29.001407 dom0 kernel: cpu 2 spinlock event irq 137
Aug 11 03:45:29.001420 dom0 kernel: cpu 3 spinlock event irq 143
Aug 11 03:45:29.001432 dom0 kernel: cpu 4 spinlock event irq 149
Aug 11 03:45:29.001456 dom0 kernel: cpu 5 spinlock event irq 155
Aug 11 03:45:29.001469 dom0 kernel: cpu 6 spinlock event irq 161
Aug 11 03:45:29.001481 dom0 kernel: cpu 7 spinlock event irq 167
Aug 11 03:45:29.001494 dom0 kernel: cpu 8 spinlock event irq 173
Aug 11 03:45:29.001506 dom0 kernel: cpu 9 spinlock event irq 179
Aug 11 03:45:29.001519 dom0 kernel: cpu 10 spinlock event irq 185
Aug 11 03:45:29.001537 dom0 kernel: cpu 11 spinlock event irq 191
Aug 11 03:45:29.001549 dom0 kernel: cpu 12 spinlock event irq 197
Aug 11 03:45:29.001562 dom0 kernel: cpu 13 spinlock event irq 203
Aug 11 03:45:29.001650 dom0 kernel: Grant table initialized
Aug 11 03:45:29.007734 dom0 kernel: pci 0000:00:07.0: DPC: RP PIO log size 0 is invalid
Aug 11 03:45:29.024659 dom0 kernel: pnp 00:00: disabling [mem 0xc0000000-0xcfffffff] because it overlaps 0000:00:02.0 BAR 9 [mem 0x00000000-0xdfffffff 64bit pref]
Aug 11 03:45:29.039421 dom0 kernel: pcieport 0000:00:06.0: can't derive routing for PCI INT D
Aug 11 03:45:29.039597 dom0 kernel: pcieport 0000:00:06.0: PCI INT D: no GSI
Aug 11 03:45:29.039927 dom0 kernel: pcieport 0000:00:06.2: can't derive routing for PCI INT B
Aug 11 03:45:29.040093 dom0 kernel: pcieport 0000:00:06.2: PCI INT B: no GSI
Aug 11 03:45:29.041882 dom0 kernel: hpet_acpi_add: no address or irqs in _CRS
Aug 11 03:45:29.042822 dom0 kernel: device-mapper: core: CONFIG_IMA_DISABLE_HTABLE is disabled. Duplicate IMA measurements will not be recorded in the IMA log.
Aug 11 03:45:29.042854 dom0 kernel: sysfb: VRAM smaller than advertised
Aug 11 03:45:35.961675 dom0 kernel: i2c_hid_acpi i2c-ELAN0412:00: failed to reset device: -61
Aug 11 03:45:42.104642 dom0 kernel: i2c_hid_acpi i2c-ELAN0412:00: failed to reset device: -61
Aug 11 03:45:48.248661 dom0 kernel: i2c_hid_acpi i2c-ELAN0412:00: failed to reset device: -61
Aug 11 03:45:54.394630 dom0 kernel: i2c_hid_acpi i2c-ELAN0412:00: failed to reset device: -61
Aug 11 03:45:55.418127 dom0 kernel: i2c_hid_acpi i2c-ELAN0412:00: can't add hid device: -61
Aug 11 03:45:55.418433 dom0 kernel: i2c_hid_acpi: probe of i2c-ELAN0412:00 failed with error -61
Aug 11 03:45:55.459586 dom0 kernel: ACPI Warning: \_SB.PCI0.PEG2.DEV0._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20211217/nsarguments-61)
Aug 11 03:45:55.462584 dom0 kernel: nouveau 0000:01:00.0: unknown chipset (b73000a1)
Aug 11 03:45:55.481595 dom0 kernel: kauditd_printk_skb: 13 callbacks suppressed
Aug 11 03:45:55.623829 dom0 kernel: tmpfs: Unsupported parameter 'huge'
Aug 11 08:46:06.529777 dom0 systemd[1]: Configuration file /etc/systemd/system/qubes-vm@sys-usb.service.d/50_autostart.conf is marked world-inaccessible. This has no effect as configuration data is accessible via APIs without restrictions. Proceeding anyway.
Aug 11 08:46:07.449392 dom0 kernel: platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
Aug 11 08:46:10.154640 dom0 kernel: kauditd_printk_skb: 77 callbacks suppressed
Aug 11 08:46:16.090423 dom0 kernel: pciback 0000:00:14.3: xen-pciback: Driver tried to write to a read-only configuration space field at offset 0x48, size 2. This may be harmless, but if you have problems with your device:
1) see permissive attribute in sysfs
2) report problems to the xen-devel mailing list along with details of your device obtained from lspci.
Aug 11 08:46:16.917586 dom0 kernel: kauditd_printk_skb: 25 callbacks suppressed
Aug 11 08:46:25.947707 dom0 kernel: kauditd_printk_skb: 2 callbacks suppressed
Aug 11 08:46:26.437642 dom0 kernel: pciback 0000:00:14.0: xen_pciback: cannot enable memory-write-invalidate (-22)
Aug 11 08:46:34.750619 dom0 kernel: kauditd_printk_skb: 23 callbacks suppressed
Aug 11 08:47:22.943611 dom0 kernel: kauditd_printk_skb: 73 callbacks suppressed
Aug 11 08:47:40.371627 dom0 kernel: kauditd_printk_skb: 15 callbacks suppressed
Aug 11 08:47:50.694657 dom0 kernel: kauditd_printk_skb: 64 callbacks suppressed
Does anyone have any ideas how I might be able to further identify an actual issue/problem/setting that can make this “fixed”?
I must say farewell for my own mental health’s sake hah…
The touchpad is apparently not reliably fixed at all. I’ve been only using XFCE in order to not lose it, but it’s been gone for two reboots (in XFCE-only) now
I also cannot seem to get the wireless card working (and considered swapping it out with an older,slower free-firmware model), and I’ve tried solutions in this thread and ones like it on other, non-qubes forums/posts.
I’m super bummed because I think this machine was a waste of a lot of money [because I have a very, very strong desire to be using QubesOS ]
I will probably move back over to Silverblue for at least the root-immutability. I wish I could stay here…
If anyone has some good ideas, I can install Qubes onto another SSD for testing at a later date 
I would actually be totally fine with not installing NVDIA to dom0, I was just rushing through random attempts, as it was a fresh install with no data on it (and was starting to expect to not get it working as I wanted during that attempt 
lol. Here we go (no NVIDIA in dom0 this time…)
. I got it running very, VERY smoothly:
)
