You used a different repo. Not sure if it makes a difference for kernel updates but there is some detail about the different repositories here How to install software in dom0 | Qubes OS
It does say it requires kernel 6.1
Thank you @Foxboard for your comment. I couldn’t find an existing HCL report from you. There is one for this machine by @sheepskin and it already contains the remark “requires kernel 6.1+ and igfx troubleshooting”.
If you can, please submit your own HCL report. Having two reports for the same machine increases confidence.
---
layout:
'hcl'
type:
'laptop'
hvm:
'yes'
iommu:
'yes'
slat:
'yes'
tpm:
status: 'partial'
message: '2.0 present - not supported (yet)'
remap:
'yes'
brand: |
Star Labs
model: |
StarBook VI
bios: |
'Coreboot 8.32'
cpu: |
12th Gen Intel(R) Core(TM) i7-1260P
cpu-short: |
FIXME
chipset: |
Intel Corporation Device [8086:4621] (rev 02)
chipset-short: |
FIXME
gpu: |
Intel Corporation Device [8086:46a6] (rev 0c) (prog-if 00 [VGA controller])
gpu-short: |
FIXME
network: |
Intel Corporation Wi-Fi 6 AX210/AX211/AX411 160MHz (rev 1a)
memory: |
65379
scsi: |
usb: |
1
versions:
- works:
'yes'
qubes: |
R4.1
xen: |
4.14.5
kernel: |
6.1.12-1
remark: |
'Needs kernel version 6.1+'
'Sys-audio requires snd_hda_intel power_save to be turned off'
'Intel IGFX troubleshooting - Software Rendering or Video Lags'
'Issues with Bluetooth initlization upon sys-usb qube startup'
credit: |
FIXAUTHOR
link: |
FIXLINK
---
Remarks
- Needs kernel version 6.1+ to work correctly
- Sys-audio requires snd_hda_intel power_save to be turned off to prevent media lagging or fully outright stopping.
- Intel IGFX Troubleshooting - Software Rendering or Video Lags
- Issues with Bluetooth initialization upon sys-usb qube startup
Note: Used sys-net for USB, Audio, and networking.
Other comments:
Based on Star Labs StarBook Mk VI with some additional troubleshooting
For some of these remarks, StarLabs possibly could build a custom Starbook Qubes ISO with some of the fixes included? This would be an option for Starlabs to consider. Then again, this would have some security concerns as well to contend with. Up for debate.
Re: TPM, the HCL report generator did not detect the TPM chip despite it being present. It might be due to it not being supported in Qubes. Using dmesg and grepping for TPM will show it.
# dmesg | grep TPM
[ 0.451055] ACPI: TPM2 0x000000007661B000 00004C (v04 COREv4 COREBOOT 00000000 CORE 20221020)
[ 0.451128] ACPI: Reserving TPM2 table memory at [mem 0x7661b000-0x7661b04b]
[ 2.976865] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0x1B, rev-id 22)
Re: Intel HDA Power save, placing the following file inside the sys-audio template will fix the issue if using a sys-audio setup:
/etc/modprobe.d/50-snd.conf
options snd_hda_intel power_save=0
Re: Bluetooth issues, it might be possible that the issue I’m facing is due to a software configuration error, as not only the public address for the bluetooth isn’t saved, any pairings is also lost. For now, the following fixes the bluetooth issues (requires bluez in sys-usb qube):
fix-bluetooth.sh
#!/bin/bash
echo $(hciconfig hci0 | grep "BD Address" | cut -d " " -f 3)
sudo btmgmt public-addr $(hciconfig hci0 | grep "BD Address" | cut -d " " -f 3) || true
sleep 5
sudo btmgmt name hostname
hostname being placeholder for the device’s name. This should work being executed from a service file.
Edit (hopefully the only one needed): If using blueman and bluez, adding the following directory:
/var/lib/bluetooth
to bind-dirs will preserve pairings. The above script will still be needed, unless someone is able to fix the initialization issues.
Attachments
I want to submit an HCL report but it seems like I need to generate it from my own machine and submit log files. For privacy reasons I would rather not do this. Is it possible to submit an HCL report without submitting logs?
The information that the HCL tool gathers does not contain any personally identifying information. For reference, the support files it generates is:
- Information about dom0 (guessing that is what xl-info contains)
- dmesg log before dom0 itself starts
- SCSI device information if present
- The Qubes-release number
- Information about PCI devices
- SMBIOS/DMI Table information
- Information about the processor in your machine.
The yml file it generates is a template version of what you see in the main HCL list.
---
layout:
'hcl'
type:
'laptop'
hvm:
'yes'
iommu:
'yes'
slat:
'yes'
tpm:
'unknown'
remap:
'yes'
brand: |
Star Labs
model: |
StarBook
bios: |
8.31
cpu: |
12th Gen Intel(R) Core(TM) i7-1260P
cpu-short: |
FIXME
chipset: |
Intel Corporation Device [8086:4621] (rev 02)
chipset-short: |
FIXME
gpu: |
Intel Corporation Device [8086:46a6] (rev 0c) (prog-if 00 [VGA controller])
gpu-short: |
FIXME
network: |
Intel Corporation Wi-Fi 6 AX210/AX211/AX411 160MHz (rev 1a)
memory: |
65379
scsi: |
usb: |
1
versions:
- works:
'FIXME:yes|no|partial'
qubes: |
R4.1
xen: |
4.14.5
kernel: |
6.3.2-1
remark: |
FIXME
credit: |
FIXAUTHOR
link: |
FIXLINK
---
Remarks
Here another HCL report for StarBook Mk VI Intel from Star Labs
Kernel 6 required
I had issues at first when I installed Qubesos with kernel 5th serie and most of them were solved upgrading to 6th kernel (reported by other HCL).
Lack of GPU virtualization
The main remaining issue is lack of GPU support - The CPU is not sufficient even for displaying a 720p video at a comfortable refresh rate, at full-speed fan.
I thought of making graphics virtualization work to share a bit of GPU power with some App VMs.
I tried hard to make SR-IOV from 12th gen intel cpu work with Xen but never succeeded.
(Xorg.0.log - AIGLX: Screen 0 is not DRI2 capable)
Mouse hangs under high load
Another issue is the mouse refresh rate slowing down under high load (starting heavy App VM for example).
Attachments
layout:
'hcl'
type:
'Laptop'
hvm:
'yes'
iommu:
'yes'
slat:
'yes'
tpm:
'2.0'
remap:
'yes'
brand: |
Star Labs
model: |
StarBook
bios: |
8.99
cpu: |
12th Gen Intel(R) Core(TM) i7-1260P
cpu-short: |
FIXME
chipset: |
Intel Corporation Device [8086:4621] (rev 02)
chipset-short: |
FIXME
gpu: |
Intel Corporation Alder Lake-P GT2 [Iris Xe Graphics] [8086:46a6] (rev 0c) (prog-if 00 [VGA controller])
gpu-short: |
FIXME
network: |
Intel Corporation Wi-Fi 6 AX210/AX211/AX411 160MHz [8086:2725] (rev 1a)
memory: |
65377
scsi: |
usb: |
1
certified:
'no'
versions:
- works:
'FIXME:yes|no|partial'
qubes: |
R4.2.0
xen: |
4.17.2
kernel: |
6.6.2-1
remark: |
FIXME
credit: |
FIXAUTHOR
link: |
FIXLINK
Remarks
TLDR: GPU issues with Starlabs MK-VI intel => upgrade to 4.2 and coreboot 8.99 !
GPU issues with another i7-12th => try upgrade to 4.2.
New HCL report after upgrading to 4.2 and coreboot bios to 8.99, the gpu is now recognized and seems to work much better.
On 4.1 (fedora 32 kernels - coreboot bios 8.31), GPU acceleration seemed not provided in AppVM, leading to low image rates videos and no chance to launch 3d a game. I didn’t have time yet to try all use cases which I tested out in 4.1 but videos seem much faster now !
I’ll probably dig deeper again in GPU virtualization.
Attachments
- Qubes-HCL-Star_Labs-StarBook-20231228-204700.yml (798 Bytes)
@distopia Thanks for the HCL report. I just submitted a pull request with it.