Recent content by thenickdude

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...

You missed to set the machine type to q35

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).

I'm now running 5.4.78-2-pve recompiled to enable the KASAN kernel address sanitiser, so fingers crossed that it crashes again for me now!

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 haven't had any more crashes since reverting to pve-kernel-5.4.78-1-pve.

Your OSK is wrong, it is case sensitive.

Check /var/log/kern.log or the rotated version /var/log/kern.log.1 for log entries made at the time of the reboot.

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...