Search results

our file restore code currently doesn't add ACLs at all to the tar archive, I guess the ACLs you see are inherited from a parent dir wherever you extracted the tar to?

this is kind of missing a few things.. which versions are you using? what are you backing up/restoring? (VM, CT, dir?) what kind of storages/filesystems/.. are involved? how are you doing the restore / file-restore? any warnings in restore logs?

das kann ich dir nicht sagen - copy+paste wuerde fuer den restore vermutlich schon reichen, aber ob diese user/gruppen am host auch in verwendung waren und irgendwelche spezielle initialisierung oder aehnliches brauchen weiss ich nicht ;) wichtig ist nur pro ID (also z.b. 995) nur einen eintrag...

ich meine die user / groups in /etc/passwd bzw /etc/group..

du brauchst den patch nicht einspielen, du kannst einfach die user und gruppen so wie am alten system anlegen dann laeufst du nicht in den bug..

UKIs can be extended, and that is the current plan if they get implemented (give the user the option to add their own overlays/extensions, that the user can sign with their MOK). (enterprise) users asking for SB support and easier installs out of the box are the main reasons we implemented...

again - PVE is not deciding whether your system uses UEFI boot, it has to follow what your system does. it will always create an ESP, both to make it easier to switch, and to allow the Grub+Kernels-on-ESP use case for legacy boot with ZFS.

whether a system boots in legacy or proper EFI mode is determined by the UEFI settings, not by PVE.. the boot loader situation is like it is for historical reasons: - PVE used to use Grub for everything - ZFS and Grub became increasingly brittle, because the ZFS code in Grub didn't keep up...

wir haben uns dagegen entschieden, einen backport von tar fuer dieses issue zu machen, nachdem ein workaround existiert (sicherstellen, dass die ranges und mappings name <-> uid/gid auf beiden hosts ident sind). PVE 9 basierend auf Trixie wird das problem dann nicht mehr haben, erscheint aber...

no, it's the default value of the "preallocation" option on dir-based storages.. https://pve.proxmox.com/pve-docs/pve-admin-guide.html#_common_storage_properties set it to "off" for the storage where the disk is created, then a restore will not attempt to pre-allocate the created images.

I am not sure I follow.. when you restore a backup, the disks are either created on a single restore target storage, or on the original storages from the backed up config. you need to set the option on whichever storage is the right one for your storage task..

yes, see https://bugzilla.proxmox.com/show_bug.cgi?id=1856

you need to set the option on the storage that you restore to..

since you seem to be using that disk only as backup target, either ext4 with a bigger block size (shouldn't affect VMA-based backups negatively), or an FS that supports bigger files out of the box (IIRC XFS for example does) should be fine.

relatime is already the default?

what filesystem is used on the backup storage? with which settings? the error would indicate the backup archive itself grows too large and runs into a file size limit..

upgrading is only possible for root@pam, since it effectively gives you a root shell on the host.

your storage is too slow to allocate the VM disk within 60s.. you can try with preallocation=off on the storage

bitte debug log vom start posten: https://pve.proxmox.com/pve-docs/chapter-pct.html#_obtaining_debugging_logs ist das upgrade selbst denn durchgelaufen? hats irgendwelche warnungen oder fehler angezeigt?

thin_check and thin_repair would be the next steps, but for that the thin pool cannot be active. edit: there also seems to be an updated/rewritten version of those tools, if the packaged ones fail I'd give those a shot: https://github.com/jthornber/thin-provisioning-tools