Search results

Update is released: https://lists.debian.org/debian-security-announce/2023/msg00283.html Also worth mentioning from the terrapin FAQ:

FWIW I tried to trigger the issue on a older but up-to-date system, with a fresh vm with similar config as posted, but was not able to trigger it, regardless arc size or zfs encryption. It has zfs on root. However: the command as posted in the already mentioned openzfs bugreport triggers a crash...

Seeing there was an updated zfsutils-linux: 2.2.0-pve3 already in the no-subscription repo, with changelog: * avoid error from zfs-mount when /etc/exports.d does not exist (yet) * ensure vdev_stat struct layout compat between 2.1 and 2.2, avoiding false-positive detection of the...

On kernel 6.5 no issue seen for now. What I did notice on 6.2.16-19-pve with zfs-2.2.0-pve1: zpool status gives (non-allocating) after each entry. Booting with 6.5 doesn't.

Reading this i first wanted to test without kernel 6.5, so with current 6.2.16-19-pve. As instructed in OP did a full-upgrade on a up-to-date system previously running no-sub repo. System is running zfs as root fs. Also encrypted zfs datasets with manual mount. No issues detected, except one...

See: https://pve.proxmox.com/pve-docs/pve-admin-guide.html#qm_virtual_machines_settings Chapter 10.2.8. Display. virtio-gl. And: https://pve.proxmox.com/pve-docs/pve-admin-guide.html#qm_pci_passthrough It's pretty well described there. With most important note: Vir* GPU <> gpu passthrough

As there are multiple reports of non working cards (but not all) I think it's wise to file a bug report at https://bugzilla.proxmox.com/ There it can be tracked. The forum is not the best place for this. Some quick searching on the kernel.org and ubuntu bugtrackers did not show relevant...

Running multiple systems with sas2008 cards too, no issues with 6.2.x opt-in kernels since becoming available. Another system upgraded to pve8 with 6.2 kernel running fine too. You could investigate your boot logs and compare the working and not working kernel messages. So far you haven't...

To add, if the guest indeed run fine, problably pvestatd isn't running fine due to some other issue like another staff member hinted. You could also try a host reboot or restart pvestatd service.

Hi, I was wondering too as I saw some scattered discussions on using atime and relatime on zfs datasets. And I assumed this thread is about zfs as your linked post is about zfs datasets ;). My pve host (pve-manager/7.4-3/9002ab8a) was installed prior to pve 7.x and zfs rpool dataset has...

Since a while one of my pve hosts runs a zfs dataset with native encryption and did not have any issues so far. I've not implemented automatic loading of the key for the encrypted dataset so if the host is booted I will have to supply it myself. Now I was testing snapshots on this dataset and...

@thiemo since that post I set it up differently, I changed my mind, not using separate hardware anymore for multiple (own) reasons. Two of them: it was to complex and too much hassle to maintain and raspberry pi doesn't get automatic security updates, so the cons outweighed the pros. How to...

Phoronix did some tests.

Thanks, installed and running without issues so far. Though I spotted the following in my boot log: systemd-modules-load[1031]: Failed to find module 'vfio_virqfd' But found this Arch bug report with in it a link to a vfio kernel commit that indeed seems to be introduced in kernel 6.2. The...

Not an expert here, but just to get a hint about what sensor is failing you could compare in both kernels what sensors are reported and working by searching both boot logs and or installing i2c-tools and running i2cdetect. Sensor could be on a different adapter number, as stated here...

Just for test I tried to get a stack trace for 6.1.6 and with pass through physical disk (default options) I was able to get a stack trace like this: - add disk: qm set 100 -scsi1 /dev/disk/by-id/<physicaldiskid> - boot vm with parted live iso, create partition table, create partition ext4. - as...

Indeed fixed in pve test repo :D

Just tested 6.1.10-1-pve and can confirm that amdgpu unregister issue and amdgpu mst issue are both fixed. I just tested for these two, but didn´t see other errors pop up, but also didn't test any further than that.

On my system I saw the same stack trace. And as I could easily reproduce it I decided to do a kernel bisect and filed the bug report upstream: https://gitlab.freedesktop.org/drm/amd/-/issues/2374 Good news, I just tested with Ubuntu mainline kernel 6.1.9 and the issue is gone. Reported upstream...

Thanks for bringing that issue to attention again and the separate thread. Seems that 6.1 kernel needs some polishing on amdgpu side :( For this moment I will probably stay on 5.19 (as long as it will be available), or current default pve kernel on the host. And will see how a vm with gpu...