On 04/19/2017 12:33 AM, Reg Tiangha wrote: > I'm racing the VM freezing, hence the typos (it's also late in my part > of the world). Here's what I previously wrote, without the typos. Sorry > about the spam; ideas to solve my freezing issues (Qubes VM Manager also > freezes, although I don't know if it's related to the freezing VMs or > something different and sometimes killing it makes the VM responsive > again) are certainly welcome: > > I just realized that Patrick was only relaying the message from someone > on the Whonix forums, which explains why the person who originally > reported it hasn't responded, lol. > > But to add a bit more info from my previous report, running the stock > Debian 8 4.9 kernel from jessie-backports in an up-to-date VM on the > stable track throws the same BadAccess error in the guid log as the 4.9 > coldkernel does, so anyone who wants to test that can easily replicate > it by spinning off a new Debian 8 vm and installing > linux-image-amd64 from jessie-backports; no need to compile and install > a 4.9 coldkernel to replicate the failure. > > >
OK, I may have spoken too soon about 4.9 not working on PVGRUB VMs. In my case, it really was dkms not compiling the u2mfn module properly, and that's why I wasn't getting the green light. My post mortem is here: https://github.com/QubesOS/qubes-issues/issues/2762 So I go back to my original opinion that there's no technical reason that Qubes couldn't run a 4.9 kernel in dom0 or in VMs. However, I do think it should be an opt-in thing that users can do with a meta-package that can help manage the upgrade (similar to how Ubuntu users can choose to opt into newer kernels in LTS releases by explicitly installing an Hardware Enablement package). I really do think that Qubes needs to do it by metapackage because the version of u2mfn that ships with the original R3.2 iso does *not* support kernels higher than 4.8. And in order for things to work correctly, u2mfn 3.2.4 must be installed first so that dkms doesn't fail to compile that module when the kernel is upgraded. So a metapackage could help manage that. It could ensure that a stock R3.2 system has all the prerequisites like an update u2mfn.c file and the appropriate kernel headers installed first before upgrading the kernel, and can also ensure that dkms recompiles all modules for all kernels that may be installed on the system. Plus there's no guarantee that a user coming from a fresh install from the original R3.2 iso will have a completely updated system before running a 4.9 kernel upgrade. After a fresh install, the first thing that person could choose to do is to first upgrade the kernel to 4.9 to fix some communicability issues (for example, garbled video displays that may be fixed with newer drivers) before proceeding to upgrade everything else. So having a metapackage that could ensure all 4.9 prerequisites are met could help ease the transition. A metapackage probably wouldn't be needed if the shipped version of u2mfn.c worked with kernels 4.9+, but it is what it is. Anyways, those are my thoughts. But it would be nice to hear from more people who are running 4.9 and/or 4.10 kernels on different hardware configurations to see what their experiences are like. -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/od8kbn%24up2%241%40blaine.gmane.org. For more options, visit https://groups.google.com/d/optout.
