Search results

Hard to tell, I cant remember If I had set that option before. Might be the case, so I overwrote the LVM.conf by confirming it with "yes" on upgrade-question.

On setups with modified chrony.conf it also brings a question on upgrade from 8to9. Maybe add this to the list on the wiki, otherwise manually set timeserver gets lost -> errors could happen in corosync or ceph.

Your device is full! No space left on device That is the reason!

No i mean the ring-IP-Adresses. its not allowed to change the ips in here. you need to first add a ring1, reload config. then remove ring0. You cant just simply switch the ip-adresses here.

You could have also set # of pgs to 128 and minimum # of pgs to 128 as well.

Did you just try to replace the ips in corosync.conf without removing the interfaces before? You will now need: https://forum.proxmox.com/threads/made-mistake-in-corosync-conf-now-cannot-edit.77173/#post-716686 you are having a split-brain-scenario now. It is not allowed to edit active links and...

Thanks! Good point, but this was not the solution for me. I noticed that the containers will start exactly after 5 minutes. Seems like a different problem. So waiting 5 minutes is ok for me atm. In case someone wants to update the debian containers to trixie to make the workaround actually work...

No unfortunately not. Thanks! On my side it only worked when doing the proxmox-boot-tool init /dev/sda2 && proxmox-boot-tool init /dev/sdb2 && proxmox-boot-tool refresh before rebooting.

Yes those vms are using 2 disks in a zfs mirror. Manually booting does not work it just goes back to bios again. This is how it looks like. I also only see one proxmox-entry.

Thanks I also needed to restart docker via systemctl restart docker on every boot. If I dont, docker does not work on my side.

* On Details: only use Web-Sockets-Support * Custom-Location: / then https then IP then 8006 * SSL all options enabled Thats how it works on my nginx reverse proxy.

on HA setups, using the maintenance-mode is a lot easier. On disabling: It even puts them back to the host the vms/ct were before enabling it.

Hello this is a english speaking forum, plöease post in english. There are multiple reasons why a PVE system could shut down / reboot. Is this a cluster or single-node system? Have you checked your logs (journalctl)? Is network stable? Any errors on the server/ipmi/bmc?

Why would you prefer broadcast mode over frr or routed setup? Why are you needing open-v switch for your ceph meshed network?

Please post your firewall-rules in your security-group so people have the possibility to check it out in more detail. Did you put the security-group on a specific level (datacenter / host / vm)-level?

Your VM-100-Disk-2 is raw, and is only allowed to be qcow2. Seems like a vTPM-disk. I personally also did not set "Use LUNs directly" not sure, if its a requirement though.

Ill add my forum-post to this list: https://forum.proxmox.com/threads/pve-9-beta-pve-nested-upgrade-from-8-to-9-breaks-boot.168662

I just tested the PVE-8 to PVE-9 Upgrade on a freshly installed PVE-8 Installation (Nested, VM) so not on physical hardware. After upgrading and rebooting, the VM does not boot anymore and goes to VM-BIOS. Thats the proxmox-boot-tool status output before rebooting: root@pve-2:~#...

After upgrading to the beta, I get an error on all my vms regarding cloudinit + also for my ct, that are on a lvm-thin pool. all vms and ct cant start: TASK ERROR: activating LV 'pve/vm-103-cloudinit' failed: Check of pool pve/data failed (status:64). Manual repair required! TASK ERROR...

The wiki-post says: How to do that? running apt policy seems not to be the full command? Might be useful adding an example on howto check. Also apt update brings up the following, might be related to check seeing if the new repo-format is used or not. My sources.list still contains pvetest...