Recent content by wbumiller

Yeah this seems to be an issue in glibc, fixed 11 days ago: https://sourceware.org/git/?p=glibc.git;a=commit;h=7107bebf19286f42dcb0a97581137a5893c16206 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=79139

Okay I managed to reproduce the issue by producing a file with enough hole and large-enough filled extents. This seems to be an interaction between zfs and glibc (and the buggy behavior seems to be in glibc from initial analysis). If you intend to upload more large files, you'll want to mount...

It's a bit unexpected that the bad iso is the one with holes. It would be interesting to see - the file's allocation information before the copy - how cp sees the holes. Could you provide the following: - The output of the breaking cp command(strace -f cp ...) - The output of: zdb -Ovv...

Sieht aus als wäre images/152/vm-152-disk-0 keine subvolume, sondern ein normales directory. Auf btrfs sollten raw files innerhalb von subvolumes angelegt werden. Hast du die files mal manuell verschoben mit cp/rsync/mv/... oder irgendein anderes tooling, das btrfs subvolumes nicht mitnimmt...

Files are written to a temp file, synced, and then moved into place. If the backup was abnormally cancelled (crash, powerloss, etc.) the files can linger. The code around this had a few changes since those dates (eg. the files would now end in `.tmp_<random letters>`), so I'd argue that these...

This is something PVE will need to improve upon. Currently we just spread containers across cpus - that is if a core count is set for a container. If you have P+E cores I currently recommend settings the core count to 0 (unlimited) and use the cpu limits instead and let the scheduler do its...

AFAICT this error message comes from GRUB and is normally about licenses in its modules. Since this is the installer my first guess would be some kind of corruption of the installer image or an issue with the USB stick it is on (if it is on a stick that is... not sure how you're loading the...

Thanks for confirming. Yeah this is a regression and the sync code needs fixing (or the changes to it better documented, as in theory this is the 'keys' property which could be set explicitly, but this way of doing TFA is very old and not flexible and not really editable by the users...

Do you happen to be using LDAP with realm sync? If so, can you post the settings (ideally the the section from `/etc/pve/domains.cfg`) and compare `/etc/pve/user.cfg` between working and non-working? If not, can you please answer all the following: - Describe your setup a bit more (how many...

Thanks for the report. There's already a bug report available here[1], but the proposed patch was not ready, but this should be fixed soon. [1] https://bugzilla.proxmox.com/show_bug.cgi?id=3989

This sounds like a weird kind of corruption. And is there really a space in 'authorized _keys' there or did you add that by accident? You can use `sqlite3 /var/lib/pve-cluster/config.db` as root to inspect & possibly fix the db directly. (but make a backup of it first...) On the sqlite3 prompt...

Do you still have the broken container? Can you check the file it mentions? (/var/lib/lxc/206/apparmor/lxc-206_<-var-lib-lxc>). I suspect that it might be empty, if that's the you can remove it and see if it starts then. Also, if that's the case, I wonder how it happened and we probably need to...

That 'data' lv isn't an actual volume you can use. It represents the entire thin pool covering the VM disks. You can create a new lv inside that pool, format it and mount it somewhere, but be aware that when using thin provisioning it's possible to overprovision and if you do that and run out of...

Whoops. Glad this could be cleared up. Hope you didn't loose important data from this mixup.

That's unexpected. Are you really logged in as root and running the PVE kernel? (uname -a) Are there any special syslog/journal messages while running this command? Also I wonder which which namespace fails exactly - can you try `unshare -m`, `unshare -n` and `unshare -U` separately to see...