[qubes-users] Re: HCL - MSI Bravo 17
> 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 https://forum.qubes-os.org/t/hunting-for-qubes-compatibility-issues-on-msi-bravo-17/6303/2 -- 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/2078359399.1168435006.1631568787858.JavaMail.root%40zimbra39-e7.
[qubes-users] Re: HCL - MSI Bravo 17
> 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. -- 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/1778855935.945520868.1626131203449.JavaMail.root%40zimbra39-e7.
[qubes-users] Re: HCL - MSI Bravo 17
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 :) -- 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/1415829767.945516405.1626130895454.JavaMail.root%40zimbra39-e7.
Re: [Qubes Forum] [qubes-users] Issues building dom0, "Package rpm-devel is not signed" [Mailing Lists/qubes-users]
- Mail original - De: "mailinglist_bot via Qubes OS Forum" À: ydir...@free.fr Envoyé: Lundi 5 Juillet 2021 16:20:57 Objet: [Qubes Forum] [qubes-users] Issues building dom0, "Package rpm-devel is not signed" [Mailing Lists/qubes-users] mailinglist_bot July 5 ydir...@free.fr : Hi all, (resent here since something seems to block with qubes-devel) I'm probably missing something in how the build is supposed to work: Following the build instructions at Qubes ISO Building | Qubes OS , configuring with ./setup, first with NO_SIGN=1. The build of rpm-dom0-fc25 succeeds, and then the build of linux-dom0-updates-dom0-fc25 fails with: Downloading Packages: [SKIPPED] perl-Fedora-VSP-0.001-4.fc25.noarch.rpm: Already downloaded [SKIPPED] perl-generators-1.10-1.fc25.noarch.rpm: Already downloaded Package rpm-devel-4.14.2.1-5.fc25.x86_64.rpm is not signed Plugging that error into a search engine suggests adding a "--nogpgcheck" flag to yum to work around it, but it seems odd/suspicious that would be needed if the other packages are passing the signature check. Are you building a 4.0 ISO? Yes, for a start I'm trying to build 4.0, next planned step being updating some packages for better support for my hardware. Is 4.0 supposed to be immune to the problem described in https://github.com/QubesOS/qubes-issues/issues/6522 ? At first I thought that maybe the NO_SIGN=1 case was not being as much used as the NO_SIGN=0 one, so I went generating a key and configure it as explained in Qubes Builder | Qubes OS . You should be able to complete the entire build without signing it. The error is saying the downloaded package is not signed, not your build. What is strange then, is that if I remove "rpm" from the packages to build (the same way it is suggested to remove gcc to save build time) I get rid of the error (and then it fails with the same problem for "drpm", but at least linux-firmware was built first, so while not satisfying it looks like a viable workaround for my immediate needs) Also, is it really a good thing to have 2 separate pages talking about roughly the same thing, with /doc/qubes-builder/ telling about NO_SIGN (which we see in templates) and .rpmmacros, and /doc/qubes-iso-building/ talking about "fully signed build" using SIGN_KEY (which we don't see in templates) ? Probably not the best, but when I last looked at it I couldn't figure out a way to consolidate them without making it overly cluttered. Please submit a pull request if you have an idea, though. I'll happily try once I've understood those signing issues :) Visit Topic or reply to this email to respond. To unsubscribe from these emails, click here . -- 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/1890564469.920617731.1625586435640.JavaMail.root%40zimbra39-e7.
[qubes-users] Issues building dom0, "Package rpm-devel is not signed"
Hi all, (resent here since something seems to block with qubes-devel) I'm probably missing something in how the build is supposed to work: Following the build instructions at https://www.qubes-os.org/doc/qubes-iso-building/, configuring with ./setup, first with NO_SIGN=1. The build of rpm-dom0-fc25 succeeds, and then the build of linux-dom0-updates-dom0-fc25 fails with: Downloading Packages: [SKIPPED] perl-Fedora-VSP-0.001-4.fc25.noarch.rpm: Already downloaded [SKIPPED] perl-generators-1.10-1.fc25.noarch.rpm: Already downloaded Package rpm-devel-4.14.2.1-5.fc25.x86_64.rpm is not signed At first I thought that maybe the NO_SIGN=1 case was not being as much used as the NO_SIGN=0 one, so I went generating a key and configure it as explained in https://www.qubes-os.org/doc/qubes-builder/. Doing that I noted one accuracy (see https://github.com/QubesOS/qubes-doc/pull/1167) which I hopefully circumvented, but that did not help. I'm not even sure I understand how signatures are supposed to be generated, since there is this optional "make sign-all" to be run *after* "make qubes": it seems likely normal that configuring things for the later step does not impact the earlier one. Setting VERBOSE=1 and even DEBUG=1 does not seem to help in understanding what exact step is at fault. I could not find an "understanding how the build system works", which would greatly help onboarding new devs :) Also retried after setting SIGN_KEY, still same result. Also retried by copying the example-configs/qubes-os-r4.0.conf instead of using ./setup, still same result. I also note some peculiar content in this ./setup-generated conf, eg. "DIST_DOM0 ?= fc20", when the targeted version correctly seems to be set to fc25. What did I miss ? Also, is it really a good thing to have 2 separate pages talking about roughly the same thing, with /doc/qubes-builder/ telling about NO_SIGN (which we see in templates) and .rpmmacros, and /doc/qubes-iso-building/ talking about "fully signed build" using SIGN_KEY (which we don't see in templates) ? Best regards, -- Yann -- 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/923475090.890791864.1624999401993.JavaMail.root%40zimbra39-e7.
[qubes-users] No network in win10 HVM clone, persistence of original qube's IP
Hello, I have installed a windows 10 standalone HVM qube, which works as expected. Now if I clone it, the cloned qube cannot even ping his default gateway. Digging a bit I can see that: - sys-firewall has a route, through the proper iface, to the IP associated with the cloned HVM, but the IP shown by Windows is the one of the original qube - windows network settings show that wrong IP in the "Properties" section of the interface config pane, where the "IP settings" section has no IPv4 address or gateway defined - qvm-prefs does show the expected IP Setting the static IP config manually in window indeed works, but I guess it's not supposed to work that way. What would be the Right Way to fix the setup ? Note that while digging into Qubes networking I started with https://www.qubes-os.org/doc/networking/. The routing table example for Driver Domain shown there does not match the sys-net routing table at all - notably it mentions "eth0" which seems to hint to that doc being out of sync, with eth interfaces being named "en*" nowadays. Not sure it makes sense to keep that example, maybe now a sys-firewall example would be more fitting ? -- 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/589878530.833896641.1623847792671.JavaMail.root%40zimbra39-e7.
[qubes-users] Re: HCL - MSI Bravo 17
> > 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 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 > https://github.com/QubesOS/qubes-issues/issues/5609, > 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 https://yum.qubes-os.org/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 https://github.com/QubesOS/qubes-issues/issues/4792) 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". -- 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/766265063.637286138.1619777250507.JavaMail.root%40zimbra39-e7.
[qubes-users] Re: HCL - MSI Bravo 17
> 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 https://github.com/QubesOS/qubes-issues/issues/5609, 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, -- Yann -- 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/606270673.634114217.1619709094781.JavaMail.root%40zimbra39-e7.
[qubes-users] HCL - MSI Bravo 17
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, -- Yann -- 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/905610205.632609916.1619685795971.JavaMail.root%40zimbra39-e7. --- layout: 'hcl' type: 'notebook' hvm: 'yes' iommu: 'yes' slat: '' tpm: 'unknown' remap: 'yes' brand: | Micro-Star International Co., Ltd. model: | Bravo 17 A4DDK bios: | E17FKAMS.117 cpu: | AMD Ryzen 7 4800H with Radeon Graphics cpu-short: | AMD 4800H chipset: | Advanced Micro Devices, Inc. [AMD] Device [1022:1630] chipset-short: | AMD Renoir Root Complex gpu: | Advanced Micro Devices, Inc. [AMD/ATI] Device [1002:7340] (rev c1) Advanced Micro Devices, Inc. [AMD/ATI] Device [1002:1636] (rev c6) (prog-if 00 [VGA controller]) gpu-short: | AMD Renoir AMD Radeon RX 5500M network: | Intel Corporation Device 2723 (rev 1a) Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15) memory: | 15771 scsi: | usb: | 2 versions: - works: 'yes' qubes: | R4.0 xen: | 4.8.5-30.fc25 kernel: | 5.4.107-1 remark: | Had to comment out the noexitatboot and mabps on install media. TPM2.0 is enabled in BIOS though not seen by Qubes. Qubes cannot report on SLAT availability, though it has to be there. credit: | Yann Dirson ---
