Oryx Pro (oryp9) Tester

General Discussion
#1

First time post :slight_smile:

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:

230 W Charger
4.7 GHz i7-12700H (up to 4.7 GHz - 24 MB Cache - 14 Cores - 20 Threads)
64 GB Dual Channel DDR4 at 3200 MHz (2x 32GB)
1 TB PCIe Gen4 Up to Seq Read: 7,000 MB/s, Seq Write: 5,000 MB/s
16 GB RTX 3080 Ti w/ 7424 CUDA Cores
15.6" Matte 144Hz Full HD 1080p
United States QWERTY Keyboard
WiFi 6 + Bluetooth

Looking forward to the discourse :partying_face:

2 Likes
HCL - System76 Oryx Pro (oryp9)
#2

image

1 Like
Memes about Qubes OS
#3

YIKES! I’m probably going to have to give up on this for right now, as I have no backup machine currently, and this is not working out very well :frowning:

This seemed to be the most helpful post: Nvidia driver installation - #2 by dhn

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.
:face_holding_back_tears:
:cry:
:sob:

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 :confused: If anyone has some good ideas, I can install Qubes onto another SSD for testing at a later date :slight_smile:
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.

I hope anyone reading has a wonderful day! :slight_smile: :wave:

#4

Do you mean the cursor didn’t show on the screen, or do you mean that your trackpad wasn’t detected?

Maybe give this a go:

https://wiki.archlinux.org/title/NVIDIA/Troubleshooting#Avoid_screen_tearing

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” :unamused:

2 Likes
#5

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 :partying_face: 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 :crossed_fingers: 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 :frowning: )

Agreed, I am actually planning on not attempting the driver-installation in dom0 anymore anyway :smiley:

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 :man_shrugging:

#6

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. :thinking:

Do you care to post it as a thread in this forum with the HCL tag? That should work.

1 Like
#7

That’s what I was also hoping.

Done!

Thanks for the chatting. I think I’m convinced to just try again right now :roll_eyes: lol. Here we go (no NVIDIA in dom0 this time…)

1 Like
#8

I’m SUPER tired now :sleepy: :sleeping: . I got it running very, VERY smoothly:

That fixed the tearing!

OK bedtime… :sleeping_bed:

Hopefully this is useful or helpful to someone someday!

2 Likes
#9

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 :roll_eyes: 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’m committed to using QubesOS! :ok_hand:t3::fire::sunglasses::partying_face:

1 Like
#10

I think I found the issue with the touchpad. I’m going to try the workarounds here, and I have a good feeling.

#11

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 :frowning:

  • 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.

TTFN

#12

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 :+1:t3:
6pghuw
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'.

6pgi6h
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.
#13

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…” :frowning_face:

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:

IMG20220810040432
IMG202208100404321920Ă—1444 268 KB

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! :thinking: Perhaps this is a bunch of HocusPocusCoincidence, but…

From https://forum.qubes-os.org/t/cannot-create-sys-usb-via-salt/:

#14

HELLO! ANOTHER UPDATE!

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! :smiley:

I’m going to cruise back through my old posts (uploaded from my cell phone) and clean up the picture-errors into actual text :+1:

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

1 Like
#15

Is there anything interesting in dmesg of sys-usb?

I’m curious about what was actually happening. I also want to be able to give you kudos for your fix in an informed manner :yum:

Ok, that ones got me. Oh wait……nVIDIA……:expressionless:

#16

dmesg findings from dom0

power

ACPI Warning: \_SB.PCI0.PEG2.DEV0._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20210730/nsarguments-61)

video

nouveau 0000:01:00.0: unknown chipset (b73000a1)

which seems to be talked about here: https://www.reddit.com/r/Ubuntu/comments/k771yg/nouveau_unknown_chipset_b74000a1

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.

#17

TL;DR / Summary Post

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

  1. 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

  2. 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

  3. 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

Section "Device"
    Identifier "Intel Graphics"
    Driver "intel"
EndSection

  1. 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

  2. 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 :crazy_face:

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!

that looks like most of it

#18

I would really like to use i3 WM

I think I’ve discovered a problem-scenario:

Good state: mousepad is working and screen is not tearing :+1:

  1. change to i3 at logon
  2. use it successfully
  3. reboot
  4. no touchpad working - it is obvious as soon as logon screen loads
  5. :slightly_frowning_face:
  6. logon to i3 [with no mouse] in order to allow external mouse to dom0
  7. logout → change to XFCE → logon → reboot from Log Out menu
  8. 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”? :slight_smile:

#19

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 :confused:

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 :roll_eyes:]

I will probably move back over to Silverblue for at least the root-immutability. I wish I could stay here…

until we meet again

1 Like