Hi,
Could you please provide us with the output of the following commands:
zpool get cachefile
stat /etc/zfs/zpool.cache
systemctl status zfs-import.service zfs-import-cache.service zfs-import-scan.service
Hi,
know what happens exactly could you please provide us with the network configuration `cat /etc/network/interfaces` and the output of `ethtool -i <NIC>`. Additionally, i would check the syslog or `dmesg` looking for any interesting message.
you will not lose data, but you may have to install the VirtIO if not installed in your Windows VM. to do that just detach the disk and re-attach it as SCSI.
I would make a backup before doing that!
Yes, using `ifreload -a` is recommended in Proxmox VE over `systemctl restart networking` since it reloads interfaces in a way that aligns with Proxmox VE
To investigate the issue further, could you please check the Syslog during the LXC startup? The Syslog from the PVE host should give us more information and help us understand the root cause.
Thank you for the output!
Could you please try to get rid of the hook from the LXC config espeically the `modprobe tun`. You can copy the LXC config as a backup `cp /etc/pve/lxc/111.conf /root/111.conf-backup`
And try to start the LXC, and run the `modprobe tun` manually?
Can you also please...
Thank you for the syslog!
In the syslog I see the following:
Nov 12 08:02:11 pve kernel: perf: interrupt took too long (3962 > 3942), lowering kernel.perf_event_max_sample_rate to 50000
Before the reboot, this message interrupt took too long indicate CPU interrupt delays, which can imply...
Thank you for the output. The NIC names look ok not changed after the proxmox-kernel updated. Could you please post the output of `pveversion -v`?
Do you have a atlantic.conf in the `/etc/modprobe.d/`?
Hi,
The journalctl/syslog should give you what cause the issue. You can generate the syslog in a specific time using the following command:
journalctl --since '2024-11-11 00:00:00' --until '2024-11-11 08:50:15' > /tmp/$(hostname)-syslog.txt
You may have to edit the date/time in the above...
Can you please re-check if the iommu parameter is correct in the /etc/default/grub?
I would also try test boot from an older kernel to narrow down the issue.
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.