[qubes-users] apt-get autoremove error (Katoolin installation)
I'm triying to install Katoolin tools following this guide on Qubes 4.0.2-rc3 https://www.qubes-os.org/doc/pentesting/kali/ when i run "sudo apt-get autoremove" i get the following error: Removing 'diversion of /etc/pam.d/su to /etc/pam.d/su.qubes-orig by qubes-core-agent-passwordless-root' Removing user user from group sudo gpasswd: user 'user' is not a member of 'sudo' dpkg: error processing package qubes-core-agent-passwordless-root (--remove): installed qubes-core-agent-passwordless-root package post-removal script subprocess returned error exit status 3 dpkg: too many errors, stopping Errors were encountered while processing: qubes-core-agent-passwordless-root Processing was halted because there were too many errors. E: Sub-process /usr/bin/dpkg returned an error code (1) user@kali:~$ then if i try to install some Katoolin packages i get the following error: kat > 0 Reading package lists... Done Building dependency tree Reading state information... Done E: Unable to locate package acccheck E: Unable to locate package automater E: Unable to locate package dnmap E: Unable to locate package ghost-phisher E: Unable to locate package maltego-teeth E: Unable to locate package miranda E: Unable to locate package sslcaudit E: Unable to locate package wol-e -- 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/cfb395be-4899-451b-afc9-72db3a1c15c2%40googlegroups.com.
[qubes-users] Re: One of the configured repositories failed (Fedora 20 - x86_64)
On Monday, December 23, 2019 at 9:06:09 AM UTC-5, Spleen Productions wrote: > > I've setup a machine running R2 since i need audio working on Windows HVM. > > I would like to install QWT but when i run sudo-qubes-dom0-update i get > the following error: > > One of the configured repositories failed (Fedora 20 - x86_64) > ... > Cannot retreive metalink for repository: fedora. Please verify it's path > and try again. > > Do i need to configure qubes-dom0.repo? > Fedora 20 is no longer supported. Qubes R2 is no longer supported. Generally, I doubt anyone on the list will recommend you continue using such older unmaintained security software. So..if your hardware supports Qubes R4.0, my suggestion would be installing that, assigning one of your PCI USB controllers to the Window HVM, and then utilize a hardware USB audio device for audio out of the Windows HVM. B -- 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/901abed3-4556-405c-8aea-0825cca54c2a%40googlegroups.com.
Re: [qubes-users] One of the configured repositories failed (Fedora 20 - x86_64)
> I've setup a machine running R2 since i need audio working on Windows HVM. > > I would like to install QWT but when i run sudo-qubes-dom0-update i get the > following error: > > One of the configured repositories failed (Fedora 20 - x86_64) > ... > Cannot retreive metalink for repository: fedora. Please verify it's path > and try again. > > Do i need to configure qubes-dom0.repo? > Fedora 20? It should be Fedora 30. -- 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/47hZJf6z5gz6tm7%40submission01.posteo.de.
Re: [qubes-users] HOWTO: Enable screen poweroff (instead of blanking)
On 22. 12. 19 15:45, Claudia wrote: > > I just wanted to drop a note here before I forget. Out of the box, Qubes > blanks the screen after a few minutes, but never powers off the screen, even > though it's configured to do so in the XFCE Power Manager. I've had this > problem on several machines, all the way back to R3.2, and I always blamed it > on lack of hardware support. > > Turns out, it's because Qubes comes with Xscreensaver enabled which overrides > the XFCE Power Manager settings. Xscreensaver is only configured to blank the > screen; I'm not sure if it even supports powering it off. To return control > to XFCE, go to Menu > System Tools > Session and Startup > Application > Autostart, and uncheck "Screensaver". Then you can logout, reboot, or go to > Menu > System Tools > Screensaver > File > Kill Daemon. You may have to also > open Menu > System Tools > Power Manager > Display, and switch "Display power > management" to off and then on again. > > Note this will disable the lockscreen. This is not recommended if you use a > USB keyboard or mouse and a USB Qube, or if someone has physical access to > your computer while it's on. Otherwise, I recommend enabling screen poweroff > in order to conserve energy and lengthen the lifespan of your screen's > backlight. > > I have also noticed this annoyance on several machines and different linux distributions so it must be an Xfce problem, not a Qubes problem. You're probably asking yourself why do we even need xscreensaver when we can instead use a screen locker like lightlocker. I think I read on the issues tracker that xscreensaver is the most secure screen "locker" for X11 which is why it is used in Qubes, and if you would want to use something stronger you'd have to go wayland. I hear Qubes 4.1 will use the new Xfce 4.14 though I am unsure whether this bug has been fixed in that version. Kind regards! -- 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/3b432230-31f0-771a-077f-4abc67f88c86%40countermail.com.
Re: [qubes-users] UPnP in Qubes
December 23, 2019 6:09 PM, "hut7no' via qubes-users" wrote: > I have a setup like this: > AppVM -> FirewallVM -> NetVM -> internet > and want to be able to use UPnP for the AppVM. > Do any of you know how you would set this up in Qubes? > > -- 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/4800d296-0722-9b78-b16c-de83c5bfaffe@tt3j2x4k5ycaa5zt. > nion. I don't know, but I was actually wondering about this too. You mean for automatic port forwarding, right? I would imagine you can get a UPnP daemon that allows you to set commands to be run when a client requests port forwarding, and have it run qvm-firewall or iptables/nftables accordingly. You may have to write some glue code but it should be fairly simple. See: https://www.qubes-os.org/doc/firewall/ https://qubes-core-admin-client.readthedocs.io/en/latest/manpages/qvm-firewall.html https://www.qubes-os.org/doc/networking/ https://manpages.ubuntu.com/manpages/precise/man5/upnpd.conf.5.html (Just an example. There are many implementations out there and this one may or may not be the best choice.) If you find a solution, please follow up and share what you came up with. -- 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/21f6a5aaf83de6e09ca5e1c6b6fa43fb%40disroot.org.
[qubes-users] UPnP in Qubes
I have a setup like this: AppVM -> FirewallVM -> NetVM -> internet and want to be able to use UPnP for the AppVM. Do any of you know how you would set this up in Qubes? -- 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/4800d296-0722-9b78-b16c-de83c5bfaffe%40tt3j2x4k5ycaa5zt.onion.
Re: [qubes-users] Re: HCL - Dell Inspiron 15 5000 (5575) AMD Ryzen 5 2500U w/ Vega 8 Graphics
December 23, 2019 1:17 PM, "qubes123" wrote: > As I remember, distribution releases (Fedora, Debian) without Xen were OK for > me, however, with > upstream Xen installed, obviously all had this suspend issue. > I don't have a debug card, so the symptoms are: when the computer wakes up > with this issue, the > screen remains blank and the processor start to heat up and the PC remains > unresponsive. It doesn't > turn off automatically you have to forcibly turn it off using the power > button >5 sec. When you say it remains blank, do you mean the screen is totally powered off, or do you mean the backlight comes on but it just displays a black screen? Going from memory here, but I *think* in F29 (without Xen) the backlight would come on, but the screen was just blank, and I could make the caps lock light come on and hear sounds from the OS, and ctrl-alt-delete would cause it to reboot after 60 seconds as expected. Possibly a graphics driver problem. In Qubes R4.1 (F29-based) with Xen, when I resume I can hear the fans come on, but that's it. The backlight remains powered off, the caps lock light won't come on, sound doesn't resume playing, and I have to hold the power button to force reboot. Sounds to me like it could be a Xen panic, although I believe this is the same as what happened in F25, if memory serves. Also, I don't know what a debug card is, but my BIOS has an option called "USB Debugging" which is enabled. Do you know anything about that, or how to make use of it? I'm not looking to get into any serial/UART type stuff, but USB might be an option, depending on what it does, what you need to have, and how difficult it is. -- 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/4818737d63628d0503182f62fa0e0224%40disroot.org.
Re: [qubes-users] Re: HCL - Dell Inspiron 15 5000 (5575) AMD Ryzen 5 2500U w/ Vega 8 Graphics
On Mon, Dec 23, 2019 at 9:46 AM Claudia wrote: > Awesome, in time for Christmas even! Downloading it now. Looks like it > failed a few tests, so I don't know if it'll be usable enough to really > test suspend/resume on it but we'll see. Not sure if I'll get a chance to > install it today but I'll follow up when I do. Thanks for the link brendan. Yeah. Looks like Openqa can’t (or isn’t configured to) utilize iommu under the kvm hosting...and with Xen 4.13 the approach taken to workaround that in the test bed cannot be used any more. So it’s possible that the large percentage of failed/incomplete tests might not have a significant impact on how well it works in your case. That being said I’m curious about how Marek will get openqa working with Xen 4.13 and onward. Brendan -- 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/CAOajFefPOiX0cixj5BjP5iCE_EyB4ZWcVbrZ56PeafHBUduoHQ%40mail.gmail.com.
Re: [qubes-users] Re: HCL - Dell Inspiron 15 5000 (5575) AMD Ryzen 5 2500U w/ Vega 8 Graphics
December 23, 2019 2:27 PM, "Brendan Hoar" wrote: > On Mon, Dec 23, 2019 at 6:45 AM Claudia wrote: > >> I'm not sure this is the problem, though, because I get the same symptoms >> when suspending in a >> Fedora 25 livecd. Which makes me think it's a Fedora problem not a Xen >> problem, at least for R4.0. >> In Fedora 29 I think the symptoms were slightly different, the system was >> responsive but the screen >> just didn't power back on after resume. I don't think suspend/resume >> actually worked correctly >> until Fedora 30. We should have an F31-based R4.1 developer release by the >> end of the month, which >> would be a more accurate test. > > See Marek’s post near the end of this issue, he has a link to a F31 R4.1 ISO > built on openqa: > > https://github.com/QubesOS/qubes-issues/issues/5529 > > -Brendan Awesome, in time for Christmas even! Downloading it now. Looks like it failed a few tests, so I don't know if it'll be usable enough to really test suspend/resume on it but we'll see. Not sure if I'll get a chance to install it today but I'll follow up when I do. Thanks for the link brendan. -- 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/fa130935edfb581463fd0d65dd8e2e54%40disroot.org.
Re: [qubes-users] Re: HCL - Dell Inspiron 15 5000 (5575) AMD Ryzen 5 2500U w/ Vega 8 Graphics
On Mon, Dec 23, 2019 at 6:45 AM Claudia wrote: > > I'm not sure this is the problem, though, because I get the same symptoms > when suspending in a Fedora 25 livecd. Which makes me think it's a Fedora > problem not a Xen problem, at least for R4.0. In Fedora 29 I think the > symptoms were slightly different, the system was responsive but the screen > just didn't power back on after resume. I don't think suspend/resume > actually worked correctly until Fedora 30. We should have an F31-based R4.1 > developer release by the end of the month, which would be a more accurate > test. See Marek’s post near the end of this issue, he has a link to a F31 R4.1 ISO built on openqa: https://github.com/QubesOS/qubes-issues/issues/5529 -Brendan -- 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/CAOajFef-2_HVytQ5Euou8kyvjLOvc%3Dw%3D1hOFO9sPcGa3ZRbYWQ%40mail.gmail.com.
[qubes-users] One of the configured repositories failed (Fedora 20 - x86_64)
I've setup a machine running R2 since i need audio working on Windows HVM. I would like to install QWT but when i run sudo-qubes-dom0-update i get the following error: One of the configured repositories failed (Fedora 20 - x86_64) ... Cannot retreive metalink for repository: fedora. Please verify it's path and try again. Do i need to configure qubes-dom0.repo? -- 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/0b8e83be-4e40-4af2-9881-92ea1bf0d593%40googlegroups.com.
Re: [qubes-users] wipe released diskspace of a disposable VM's
brendan.h...@gmail.com: Other discussions involved performing the encryption inside the VMs, but as I mentioned earlier, if the content in the VM that is being manipulated is untrustworthy...then is the VM's internal encryption really trustworthy? This is a good point which I hadn't thought of. Forgive me I still haven't read the whole discussion, I was just coming up with some ideas for the OP. For networked VMs, it's a moot point because malware could just as easily send the data to attacker.gov instead of breaking encryption. But for non-networked VMs, it's a very good point. - This free account was provided by VFEmail.net - report spam to ab...@vfemail.net ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the NSA's hands! $24.95 ONETIME Lifetime accounts with Privacy Features! 15GB disk! No bandwidth quotas! Commercial and Bulk Mail Options! -- 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/0a687a91-e980-7576-2e8d-4d13ebaa2715%40vfemail.net.
Re: [qubes-users] Intel's continued security meltdown, MDS edition:
Chris Laprise: From Kim Zetter at the New York Times: https://twitter.com/KimZetter/status/1194374230109868032 When Intel released patch for CPU vulns last May, it said the patch fixed all the vulns. But researchers at @vu5ec say this isn't true and Intel knew it. Intel asked them not to disclose this and to alter conf. paper about the vulns. “We think it’s time to simply tell the world that even now Intel hasn’t fixed the problem,” Herbert Bos (@herbertbos ) says. “There are tons of vulnerabilities still left, we are sure. And they don’t intend to do proper security engineering until their reputation is at stake.” https://www.nytimes.com/2019/11/12/technology/intel-chip-fix.html https://mdsattacks.com/ - Its worth noting that the lion's share of these vulns are vendor-specific to Intel. I have long held the position that Spectre+Meltdown showed AMD x86 to be "substantially" better engineered with respect to security; I now believe that assessment to be an understatement. Competition between Intel and AMD is very asymmetrical, as the former amounts to a monopoly and the latter is the only one that feels acute competitive pressure (and hence, AMD has felt a greater need to engineer responsibly). OTOH, Intel has maintained their position with lazy engineering shortcuts, rigged benchmarks, and anti-competitive threats lodged against PC makers. For their threats, the company even announced it will refuse to pay a hefty EU judgment against them. That is the "merit" in how they maintain dominance. Even though I greatly favor the development and promotion of open source hardware (including CPUs), there are no open alternatives for Qubes users in the short-mid term. So recognizing that open source is not a singular guiding principle – that competition is vitally important for the availability of desirable and safe products – I think it would be best if the Qubes project and community recognized the situation and made a modest effort to certify AMD hardware as a safer alternative to Intel. Thanks for the info. As you may remember, I recently switched to AMD just for cost reasons. The problem is, it's hard enough to find an Intel machine that runs Qubes well, let alone an AMD machine. I know conventional wisdom says AMD is about equal to Intel in terms of compatibility, but lately I'm starting to question that. Aside from the fact that Intel is more widely used and tested, here are a couple of specific examples I've come across. https://www.mail-archive.com/qubes-users@googlegroups.com/msg29776.html This user has a mid-range business class Ryzen laptop which experienced a lot of the same problems as my low-end consumer Ryzen laptop with the same processor. The kernel complains of ACPI problems and firmware bugs. Sys-usb doesn't work, possibly due to the way USB controllers are grouped on AMD's IOMMU implementation. And suspend/resume doesn't work right, although that's not uncommon for any machine. https://www.mail-archive.com/qubes-users@googlegroups.com/msg31199.html This is an issue I ran into with the amdgpu driver, where I found that Xen has an Intel-specific option for disabling the IOMMU for the integrated graphics device, but no AMD-equivalent option. (I don't know if that's the actual problem, I'm just saying it's an Intel-specific option, of which there are several.) https://www.mail-archive.com/qubes-users@googlegroups.com/msg31512.html Here I discovered a problem with IOMMU grouping which seems to be common on Ryzen processors and perhaps AMD systems in general. The USB controllers are in the same group as the GPU, SATA controller, and audio devices. So when I try to assign USB controllers to sys-usb, everything stops working. https://www.mail-archive.com/qubes-users@googlegroups.com/msg31515.html Here a user points out that many AMD processors slightly change their feature set (cpuinfo) after a suspend/resume cycle, which causes Xen to panic due to Spectre/Meltdown mitigation. Not sure where Intel stands on this. While there may be security benefits to AMD, I think there are also some compatibility gotchas to watch out for. You're already taking your life in your own hands when you install Linux, especially a hardware-sensitive distro like Qubes. The last thing you probably want to throw into the mix is a second-place CPU vendor. I just don't know if Qubes on AMD is quite ready for primetime. - This free account was provided by VFEmail.net - report spam to ab...@vfemail.net ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the NSA's hands! $24.95 ONETIME Lifetime accounts with Privacy Features! 15GB disk! No bandwidth quotas! Commercial and Bulk Mail Options! -- 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
Re: [qubes-users] Re: HCL - Dell Inspiron 15 5000 (5575) AMD Ryzen 5 2500U w/ Vega 8 Graphics
How recent? Is it present in Xen 4.8-fc25 (R4.0)? Xen 4.12-fc29 (R4.1)? Well, maybe the "recent" was not accurate, as in R4.0 this started after xen-4.8.3.3 - from mid 2018. In R4.1 this issue is there from the beginning, as it was not fixed since - being a minor problem affecting few (not so modern Fam15h) systems. > For many AMD systems (eg. Trinity/Richland) CPUID changes after suspend > (some of the high bits), > > resulting in Xen Panic (see xen/arch/x86/acpi/power.c). So, more > investigation would be needed to > > check why the CPUID bits are changing after resume and whether it had > any security implications or > > not. > > For the time being - if you accept the possible security implications - > you can disable that check > > eg. by commenting the panic line out after "recheck_cpu_features" in the > above mentioned power.c > > file, compile xen for dom0 via qubes builder and test it in your system. > > Thanks for the info. > > I'm not sure this is the problem, though, because I get the same symptoms > when suspending in a Fedora 25 livecd. Which makes me think it's a Fedora > problem not a Xen problem, at least for R4.0. In Fedora 29 I think the > symptoms were slightly different, the system was responsive but the screen > just didn't power back on after resume. I don't think suspend/resume > actually worked correctly until Fedora 30. We should have an F31-based R4.1 > developer release by the end of the month, which would be a more accurate > test. > > What are the symptoms of a Xen panic? Would it prevent the screen from > powering back on? Would it reboot after five seconds? Or would it just hang? > > I'll try booting qubes R4.1 on bare metal without Xen and try > suspend/resume. If it works I'll post cpuinfo before and after. > As I remember, distribution releases (Fedora, Debian) without Xen were OK for me, however, with upstream Xen installed, obviously all had this suspend issue. I don't have a debug card, so the symptoms are: when the computer wakes up with this issue, the screen remains blank and the processor start to heat up and the PC remains unresponsive. It doesn't turn off automatically you have to forcibly turn it off using the power button >5 sec. -- 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/1b59bb8f-aee8-4d4e-a832-ae252fbd1ad3%40googlegroups.com.
Re: [qubes-users] Re: HCL - Dell Inspiron 15 5000 (5575) AMD Ryzen 5 2500U w/ Vega 8 Graphics
December 23, 2019 7:31 AM, "qubes123" wrote: > Suspend/resume problem is most likely caused by a recently added security > feature in Xen, that > checks CPUID after resume with the previously (at boot time) known CPUID. > This is to ensure, that > the CPU microcode level - along with the resulting Spectere/Meltdown etc. > mitigations - still > persist after system resume and there are no features missing. > How recent? Is it present in Xen 4.8-fc25 (R4.0)? Xen 4.12-fc29 (R4.1)? > For many AMD systems (eg. Trinity/Richland) CPUID changes after suspend (some > of the high bits), > resulting in Xen Panic (see xen/arch/x86/acpi/power.c). So, more > investigation would be needed to > check why the CPUID bits are changing after resume and whether it had any > security implications or > not. > For the time being - if you accept the possible security implications - you > can disable that check > eg. by commenting the panic line out after "recheck_cpu_features" in the > above mentioned power.c > file, compile xen for dom0 via qubes builder and test it in your system. Thanks for the info. I'm not sure this is the problem, though, because I get the same symptoms when suspending in a Fedora 25 livecd. Which makes me think it's a Fedora problem not a Xen problem, at least for R4.0. In Fedora 29 I think the symptoms were slightly different, the system was responsive but the screen just didn't power back on after resume. I don't think suspend/resume actually worked correctly until Fedora 30. We should have an F31-based R4.1 developer release by the end of the month, which would be a more accurate test. What are the symptoms of a Xen panic? Would it prevent the screen from powering back on? Would it reboot after five seconds? Or would it just hang? I'll try booting qubes R4.1 on bare metal without Xen and try suspend/resume. If it works I'll post cpuinfo before and after. -- 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/35df692b5dc1538f4762cc54eef9c77b%40disroot.org.
Re: [qubes-users] Re: HCL - Dell Inspiron 15 5000 (5575) AMD Ryzen 5 2500U w/ Vega 8 Graphics
On Monday, December 23, 2019 at 7:51:33 AM UTC, Vít Šesták wrote: > > Qubes123, that's an interesting finding. AFAIU, the CPUID check is rather > a sanity check – it verifies that the microcode is loaded properly. I also, > this should be no issue if Qubes provides a fresh microcode… > > (And maybe it can cause crash if you suspend after BIOS update, provided > that the BIOS contains a newer microcode.) > > Regards, > Vít Šesták 'v6ak' I use a Corebooted system, where the latest AMD microcode is compiled into the BIOS statically. And yes, I use a newer version of the AMD Fam15h microcode, than the version in the Linux Firmware package. This change in some of the CPUID bits after resume could be a result of xen/kernel trying to load the published microcode, and then fails because the BIOS version is newer. However, the /proc/cpuinfo reported microcode version always stays the same - the BIOS version. (..assuming the /proc/cpuinfo output is updated on any microcode upgrade attempts..) As noted, I have a "special" use case, so testing the recommended change in power.c for Claudia's newer AMD system could show, that this CPUID change issue after resume is "special" for my case or "general" for some AMD users. BR, Qubes123 -- 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/5389938b-69f2-4f58-bdc3-b18c5c059cf7%40googlegroups.com.
