Search results

I am fairly certain that either your medium is outdated, or your PVE system is pointing at an old snapshot on it..

did you also sync your medium afterwards? I assume your PVE install is pointed at that..

could you post the output of "pvenode config get"?

and could you post your POM config and APT sources.list entries as well?

what does "apt list -a qemu-server" output when you only have your mirror configured?

guests don't have ownership in PVE, but you can define ACLs that are limited to specific guests or pools and their contained guests.

that message can only check the official, public repositories - it cannot know whether/that your local mirror is a copy of those. as long as the POM snapshots work, there shouldn't be any issue.

please run "pveversion -v" and post the output here

du meinst, du weisst nicht mehr welche user es gab? je nachdem wie sie gemapped waren, reicht es vielleicht /etc/passwd aus dem backup zu extrahieren (dort muessten die user ja auch definiert sein, wenns ein 1:1 mapping war dann sollte es reichen die am host genauso hinzuzufuegen). ansonsten die...

bitte mal "which pct" eingeben und "echo $PATH", danke ;)

you need to do what it says there - add an EFI disk to store EFI variables (and maybe, re-install your boot loader/..)

I don't think we set that flag file currently, but some stock Debian packages do. but anyhow - every kernel upgrade requires a reboot ;)

I don't really see much out of the ordinary there, except for the OOM kills and this line: Nov 10 12:46:38 FT1-NodeB QEMU[1228209]: kvm: ../block/block-backend.c:1780: blk_drain: Assertion `qemu_in_main_thread()' failed. that would indicate the VM 108 crashed there (similar lines also exist...

pct-scanner-script hat damit nix zu tun - "pct" ist das CLI tool von PVE um container zu managen.. (analog zu "qm" für VMs).. kannst du mal "pveversion -v" hier posten?

"pct rescan --vmid 102" sollte die volumes als unused hinzufuegen, dann kannst du sie entfernen.

nobody is saying we won't ever implement some sort of multi-connection transport - but there is considerable overhead in doing so (both code complexity and actual resources consumed), so it's not a panacea either. I am not saying it's only an issue with high latency links, just that that is...

could you maybe provide logs of all the nodes starting slightly before and ending a bit after such an outage started?

there is no such static list of filters - PVE is not static, new dependencies might be required in a future upgrade.. that's why we have a "sane" set of default exclusions of things we know we never need (well, debug can be needed for debugging, but not for regular operations), knowing that this...

you need to decide what you don't need - since you can in theory install almost any Debian package on a PVE/PBS system.. there's different solutions if all you want to do is cache actually used package files for local access (apt-cacher-ng is the most popular one).

from initramfs - but the initial dmesg of the working boot might be interesting to compare against as well..