Recent content by dafydd

All nodes left the cluster in the early morning Oct 27 03:53:51 corosync[1602]: [QUORUM] Sync members[1]: 2 Oct 27 03:53:51 corosync[1602]: [QUORUM] Sync left[3]: 1 3 4 Oct 27 03:53:51 corosync[1602]: [TOTEM ] A new membership (2.ba4) was formed. Members left: 1 3 4 Oct 27 03:53:51...

I should add - I've spotted that corosync is consuming 100% on all servers (possibly because of losing quorum?).

These are the errors showing on the 3 other nodes pvescheduler[1505772]: jobs: cfs-lock 'file-jobs_cfg' error: no quorum! pvescheduler[1505771]: replication: cfs-lock 'file-replication_cfg' error: no quorum! On the node I updated, just lots of this corosync[2837]: [KNET ] loopback: send...

I have a 4 node cluster running Proxmox 9. I just updated one node with the latest packages and kernel. I spotted something odd and realised that the cluster had no quorum. I don't know if that was due to the upgrade or whether it happed previously (I suspect it did). I rebooted the first node...

No difference. I had initially created the fresh container with nesting enabled (by mistake as it doesn't really need it). But the old containers work without nesting.

Don't think it's the config. It matches the old container details. arch: amd64 cores: 2 hostname: test memory: 2048 net0: name=eth0,bridge=vmbr0,firewall=1,gw=192.168.0.1,hwaddr=XX:XX:XX:XX:XX:XX,ip=192.168.0.29/24,type=veth onboot: 1 ostype: debian rootfs: vmdata:vm-114-disk-0,size=21G swap...

A VM may be an option. What I've done now is take a backup and restore of the original working container to a new one. This works fine even on a different physical server. The one difference I can spot is that the fresh install is running systemd-networkd and systemd-resolved which the old one...

Hi, I am running the latest Proxmox v9 with a container running Debian 9 (yes it's very old, running an application which is currently being upgraded). It was originally created more than 6 years ago and is running fine. I've now created a new container with the same original Debian 9 template...

Ok so the answer as seen in a few places is Amend /etc/default/grub amend this to turn off iommu GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=off"

Thanks. the RAID controller is: Broadcom / LSI MegaRAID SAS-3 3008 [Fury] [1000:005f] (rev 02) Subsystem: Dell PERC H330 Adapter grub.cfg looks ok and has the corrrect VG/LV. The megaraid driver is in the initramfs as I would expect I've now found this thread, which implies a bug with the...

I have a Dell R340 running Proxmox VE 8. It is fully up-to-date but is running kernel 6.5.13. A couple of years ago there was an update to kernel 6.8 but it didn't boot up, so I reverted. I'm now trying to see if I get it running on 6.8 or 6.14 in preparation for upgrading to Proxmox 9. I have...

I've seen the same issue on a Dell R340 - it was failing to find or load megaraid_sas. So it failed to boot further and went into busybox (unfortunately I didn't get a screenshot of the errors before rebooting).

Check the wiki docs here - https://pve.proxmox.com/wiki/Host_Bootloader You can unpin with proxmox-boot-tool kernel unpin

I had the same issue with a Dell server, it couldn't boot up and complained about a missing megaraid module. You can pin the previous kernel with the following command which sets the default kernel in grub. proxmox-boot-tool kernel pin 5.13.19-6-pve

The error goes away when I remove the gateway on eth1. For some reason when I tried this before, it didn't appear to work e.g. the second IP didn't appear to be routable. But it works now anyway. Edit: Unfortuntely the MAC address flip-flopping is still happening.