Apparently this directory is created when you install a Debian-packaged Rust package. So to solve this missing "anyhow" library, run apt install librust-anyhow-dev. It'll create that /usr/share/cargo/registry directory for you and store it in there for you.
The machine model changes the layout of the built-in emulated devices like the PCI bus, plus a bunch of other platform settings. It's like choosing a motherboard generation.
With the much older and cruder i440fx model, things look quite different and buses have different names, I don't think...
It's possible that your edits to the kernel cmdline didn't sync to all of the members of the RAID set. Run "cat /proc/cmdline" to see the kernel commandline that actually booted, and verify that it contains your intel_iommu/iommu arguments as expected.
You can find the OSK freely posted on Google, look for any tutorial for macOS on QEMU or libvirt. (And the OSK OP posted just needs capitalization fixed, as I said)
I had been running crash-free with KASAN enabled for nearly a month. But I just got my first KASAN error detection (a double-free) caused by my Magic Trackpad 2 being "unplugged" when the host USB controller it was connected to was detached to be attached to a VM. It looks like that's a reported...
That's unfortunate that there's no log messages as clues. At least you can rule out running out of RAM, since this would log errors from the oom killer (out of memory killer).
Argh, my machine died overnight while running 5.4.78-1-pve, so my crashes definitely weren't caused by the transition between 5.4.78-1-pve and 5.4.78-2-pve. This time it didn't manage to write the crash log to disk and I could only see the tail end of it on the monitor. It didn't look the same...
On the hypothesis that the kernel memory pool is being corrupted and this is what triggers a death in vmalloc, I'll see if I can figure out a debug build of -2 with memory bounds checking enabled.
I've now had the system crash again while the VM was just idling, I believe, this time without the vendor-reset module loaded. The crash stack trace still contains setsockopt:
Dec 17 02:59:54 proxmox kernel: [31419.688435] kvm [22443]: vcpu0, guest rIP: 0xffffff800965dd92 ignored rdmsr: 0x621...
>So, it works with "pve-kernel-5.4.78-1-pve" for sure?
No, I haven't positively identified that yet. But I haven't encountered this fault before today. As you say, the changes between -1 and -2 look small and totally irrelevant.
I'm currently changing one variable at a time and seeing if I can...
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.