Search results

you are trying to restore a backup of a privileged container as unprivileged. this only works if the backup doesn't contain any entries that only work for privileged containers. the usual culprit is postfix with a chroot setup that contains device nodes. you can convert your container to not use...

since the digest is calculated at the client side and re-verified at the server side (with additional checksums on the transport layer that should prevent the data being corrupted in flight on the wire), a digest mismatch is almost always memory on either end :)

please post the whole output of the failing boot process.. if you changed hardware, it is possible that your initrd is missing some modules or firmware files (e.g., for your GPU). in that case, you might need to boot from a live CD, chroot into your PVE installation, install missing packages...

I don't think a bwlimit on the backup job will help here, as there is likely a traffic spike at the end of the backup task that is decoupled from the backup I/O issued by the VM. the only proper solution is not sharing storage or guest traffic with corosync traffic by separating the links.

it's probably flushing at the end of the backup that causes corosync traffic to not meet its latency requirements..

see https://bugzilla.proxmox.com/show_bug.cgi?id=5753 , which is basically the same issue ;)

that sounds like broken memory either on the client or server side..

might be another instance of this: https://lore.proxmox.com/pbs-devel/20241008083355.181031-2-f.gruenbichler@proxmox.com/ (fix not yet applied)

the two entries named "cephfs" are referencing the same thing. one is on the Ceph level, where a cephfs called "cephfs" exists. the other is on the PVE level, where a storage of type "cephfs" called "cephfs" exists, which uses the cephfs called "cephfs". you could also call your cephfs or your...

is the trusted.gpg.d directory set to 755/rwxr-xr-x?

this should be fixed in libpve-http-server-perl 5.1.2: https://git.proxmox.com/?p=pve-http-server.git;a=commit;h=f5ac409d204a9f24673e101d31d2967718fb4336

that looks like your backup traffic/load either overloads the network, or the qnap box entirely.. I don't think there is a good way out of this other than spec-ing your hardware accordingly. not sure whether your "quorum VM" is a full blown PVE, or just a qdevice, if it's the former, switching...

well, you'd need to find out whos messing with the permissions ;)

yes, if our LVM disk is still around, you can add it as storage again and all the disks should become visible in PVE.

did you follow the instructions I linked? you need to bind mount certain virtual file systems from the host into the chroot..

https://openid.net/specs/openid-connect-frontchannel-1_0.html https://openid.net/specs/openid-connect-backchannel-1_0.html are probably what you are after (actively logging out on the RP side if a logout occurs on the OP side) there is also...

you need to modprobe fuse outside of the chroot

you need to set the hostname to pve, or add an entry for "ubuntu"

would you mind adding that information to the bug entry? thanks!

to further note: clients on RPs being logged out via a requests or session state changes on the OP side is an optional part of OIDC, and PVE doesn't indicate it supports that (yet) anywhere.. there's multiple ways to implement it, but almost all of them (except RP-initiated logout, which is not...