Search results

bitte poste mal "efibootmgr -v"

ist das update abgebrochen worden? bitte poste mal den inhalt von /var/log/apt/term.log.. ansonsten, mit "apt full-upgrade" sollte sich das upgrade wieder anstossen lassen, bitte den output davon ebenfalls posten..

nice find! once the fix has finalized, I will see about getting it included in Trixie (next point release is in January, so still a bit of time for the dust to settle ;))

please also check the system logs, post the VM config, pveversion -v from source and target node and the full migration and VM start logs!

each storage represents a single namespace, so yes, you need to set up one for each

tracked here: https://bugzilla.proxmox.com/show_bug.cgi?id=4186

which kernel are you running on the 9.0 nodes, and which on the 9.1 nodes?

authentication is not (yet?) implemented. please file an enhancement request in our bugzilla!

is this a cluster? check the cluster status, this sounds like something is broken there..

thanks. there is not much we can do there at the moment - the removal of the volume has to run in locked context, and the lock can be held for at most 60s, but the removal took longer in your case..

each snapshot that was verified successfully was okay at that point in time. so you just need to prune the corrupt snapshots. but I would still recommend investing time to find the reason for the corruption, else it might come back!

yes, even disabling KSM by unmerging does not get rid of all traces of KSM inside the memory mappings, and unfortuantely, this particular slowness requires the VM to be stopped and started again afterwards to get rid of all memory mappings that have been merged in the past.

you cannot downgrade to PVE 8.x (other than by reinstalling). you could try the RFC patch I just sent to pve-devel: https://lore.proxmox.com/pve-devel/20251125135107.561633-1-f.gruenbichler@proxmox.com/T/#u depending on your current KSM usage pattern, you might want to adapt the threshold...

the change is in qemu-server ,not the kernel, so the only workaround atm is to disable KSM (either globally or selectively for certain VMs).

that sounds like you might indeed have an IP conflict and are sometimes connecting to one and sometimes connecting to the other PBS instance?

are you using KSM? if so, this might be https://bugzilla.proxmox.com/show_bug.cgi?id=6935

ich nehme an es gibt auf wasabi seite keine genaueren logs? die GC sollte einen halbwegs konstanten stream an listobjects und (falls garbage vorhanden ist) delete calls ausloesen..

mostly that every admin has their own preference for that, but we could look into spawning a tmux session with custom config and socket for the upgrade session at least.. would you mind filing an issue in our bugzilla?

in phase2 gibt es derzeit keine fortschrittsanzeige, sie kann allerdings eine weile dauern: - es werden (in batches von 1000 objekten) alle chunks auf dem S3 storage gelisted - fuer jeden dieser chunks wird geschaut ob es lokal einen marker gibt, und falls ja, ob der chunk garbage ist oder...

silent bitrot could happen anyway, ESPs don't support filesystems with checksumming after all. if the disk has a hardware problem, it is very unlikely it will affect all ESPs but not the main part of the disk used by ZFS. I don't think some over-enginereed solution makes sense here. if you are...