Hello,
Did my best to replace generated FIXME's with accurate info, just tell me if
the level of information is inadequate.
The two big issues in this report (aside for the need to modify the config in
the install media, which is not obviously transposable to 4.1 snapshots) are
the lack of detection of TPM and SLAT. Will be happy to help with these.
Best regards,
Qubes-HCL-Micro_Star_International_Co___Ltd_-Bravo_17_A4DDK-20210429-041553.yml (1.14 KB)
The two big issues in this report (aside for the need to modify the
config in
the install media, which is not obviously transposable to 4.1
snapshots) are
the lack of detection of TPM and SLAT. Will be happy to help with
these.
Another issue is that the default 5.4 kernel does not support VFIO on
this hardware. So I installed kernel-latest, and that one just fails
to boot: I successively get:
- Xen startup logs
- some Linux services starting, with "Failed to start Setup virtual
console" as first line of this screen, and a couple of lines until
"starting dracut initqueue hook" and "starting Show PLymouth boot screen"
(order may vary)
- after a couple of seconds, the laptop reboots
EFI boot not providing a menu means booting from USB is the only way to
recover from such an issue, right ?
Alas, rescue mode breaks for me with anaconda rescue is broken · Issue #5609 · QubesOS/qubes-issues · GitHub,
whether I try to boot with 4.0.4 or with 4.1-20210422.
What options do I have to recover ?
Then, is there a way with qubes-dom0-update to get intermediate kernel versions
to check when is started to break ?
Best regards,
Hi Yann,
you did an excellent job preparing your HCL report. The edits I've made where for consistencies sake with all the other HCL reports and I shortened you remarks to what has to be done.
Feel free to reply to this thread with more details if you like. I will be linked from your report which is now part of this pull request:
... and will be visible on the website soon!
/Sven
> The two big issues in this report (aside for the need to modify the
> config in
> the install media, which is not obviously transposable to 4.1
> snapshots) are
> the lack of detection of TPM and SLAT. Will be happy to help with
> these.Another issue is that the default 5.4 kernel does not support VFIO on
this hardware.
Is it useful to add this information to the HCL entry itself ?
So I installed kernel-latest, and that one just fails
to boot: I successively get:
- Xen startup logs
- some Linux services starting, with "Failed to start Setup virtual
console" as first line of this screen, and a couple of lines until
"starting dracut initqueue hook" and "starting Show PLymouth boot
screen"
(order may vary)
- after a couple of seconds, the laptop rebootsEFI boot not providing a menu means booting from USB is the only way
to
recover from such an issue, right ?Alas, rescue mode breaks for me with
anaconda rescue is broken · Issue #5609 · QubesOS/qubes-issues · GitHub,
whether I try to boot with 4.0.4 or with 4.1-20210422.What options do I have to recover ?
Answering to myself on this: using any rescue USB key to change the default
boot entry in partition 1 does the job, and we can then proceed with removal
of the kernel-latest package.
Then, is there a way with qubes-dom0-update to get intermediate
kernel versions to check when is started to break ?
Maybe there's a simpler way, but I could not list available versions using
dnf. So I selected one from Index of /r4.0/current/dom0/fc25/rpm/.
Then "qubes-dom0-update kernel-latest-5.10.8-1.qubes" does download the rpm
but fails claiming "No package kernel-latest-5.10.8-1.qubes available"
(looks like qubes-dom0-update - dom0 package updates are downloaded but not installed · Issue #4792 · QubesOS/qubes-issues · GitHub) and I have
to finish installing it by running dnf on the rpm file.
It seems older kernel-latest versions are not even in the dnf index, and I had
to wget them and transfer them manually to dom0, which is quite an ordeal 
Of older versions of kernel-latest, unfortunately only 5.4.10-1 will boot
(tested in a quick manual bisect: 5.5.7-1, 5.6.16-1, 5.10.8-1). Older 5.5 and 5.6
get stuck at one point (probably in a loop, as fans start spinning faster), and
5.10 has a same reboot loop similar to 5.11.
Bottom line seems to be "no vfio for now in 4.0".
Is there any kernel with which VFIO is supported, or is it simply "VFIO not supported"?
/Sven
I was finally able to boot kernel-latest (running 5.12 now), by hiding the dGPU
from the amdgpu module (with "pci-stub.ids=1002:7340"), and installing the linux-firmware
package from current 4.1 snapshot.
We can note that this does not give proper GPU support
even for the iGPU, as dom0 Xorg still uses LLVMpipe for rendering, but at least we have
a display. Occasionally some screen corruption appears as horizontal lines, which go away
by temporarily switching to another desktop; also the miniatures in xfce's alt-tab window
list often get garbled in a not-unlike way, eg. when a firefox reopens a many-window session,
until the window gets fully drawn by alt-tabbing to it once.
Sven wrote:
Is there any kernel with which VFIO is supported, or is it simply "VFIO not supported"?
Even with 5.12-9 the kernel logs show "AMD IOMMUv2 functionality not available on this system",
although lspci does show a 1022:1631 device, which recent pci.ids identify as "Renoir IOMMU".
I can see the kernel got some cleanup of drivers/iommu/amd since 5.12, but no commit there
advertises support for this hardware. But then, history for this part of the kernel does not appear to
show much information about newly-supported hardware, and no pci_device_id list appears there
either, so who knows without testing :).
Not sure how this information can fit in the HCL
I was finally able to boot kernel-latest (running 5.12 now), by
hiding the dGPU
from the amdgpu module (with "pci-stub.ids=1002:7340"), and
installing the linux-firmware
package from current 4.1 snapshot.
Oh and I forgot, resuming after suspend does not work either,
with 5.12 or 5.4. I did not investigate this any further yet.
Thank you for updating! This thread is linked from your HCL report so others who want to install on the same kind of machine will find your additional information here.
/Sven
Sven wrote:
> Is there any kernel with which VFIO is supported, or is it simply
> "VFIO not supported"?Even with 5.12-9 the kernel logs show "AMD IOMMUv2 functionality not
available on this system",
although lspci does show a 1022:1631 device, which recent pci.ids
identify as "Renoir IOMMU".
I have to correct this statement: having the dom0 kernel reporting
"AMD IOMMUv2 functionality not available on this system" and not seeing
vfio groups in dom0 is not the symptom to look for.
OTOH /var/log/xen/console/hypervisor.log does show:
[2021-09-11 17:04:58] (XEN) AMD-Vi: IOMMU 0 Enabled.
[2021-09-11 17:04:58] (XEN) I/O virtualisation enabled
So IOMMU is really supported here (running 5.10 on QubesOS 4.1beta here).
See Hunting for Qubes compatibility issues on MSI Bravo 17 - #2 by yann