Search results

since this weekend's Debian point release, glibc is fixed, so this should no longer be an issue on a fully updated and rebooted system.

the issue is that the template contains hardlinks to symlinks, with one of the hardlinked copies being dangling: $ ls -lha llvm/usr/lib64/llvm18/lib/ total 114M drwxrwxr-x 2 fgruenbichler fgruenbichler 180 Jan 12 12:01 . drwxrwxr-x 3 fgruenbichler fgruenbichler 60 Jan 12 12:01 .. lrwxrwxrwx...

thanks, I can reproduce the problem now..

you can't, at the moment - the code in question there assumes 4k pages at the moment, and this is also encoded in the on-disk format, so can't just be bumped without breaking compatibility. we'd need to implement a fallback path there that works without mmap. could you please file a bug in our...

could one of you please provide the journal for a failed boot using the problematic kernel? or if there isn't one, collect console output via netconsole/serial console? thanks!

sounds good!

what kind of settings do you choose when creating the container? could you try re-downloading the OCI template?

seems to work for me (as in - I don't get that error, I haven't verified further) - could you provide more details about the container configuration?

what about "efibootmgr -v" and "pve8to9"?

please provide the full container config.

1. we did fix the issue we could reproduce quite fast 2. despite this long thread, only a (small!) subset of systems is affected, which is the reason why we haven't been able to reproduce the remaining issue at all so far, despite many hours spent by multiple team members on our end 3. rebooting...

its performance and reliablity are not on a level where I would consider using it directly as a datastore. the lock failures are likely (transient?) issues on their end, either ratelimiting or service interruptions.

is this datastore backed by a hetzner storagebox?

from which kernel version to which kernel version? were other components/packages upgraded at the same time? do you see other symptoms described in this thread (connections stalling with tiny receive windows)?

that's yet another issue I think. I will take a closer look!

your issues sound different.. please open a new thread!

are you also running PBS inside a privileged container?

I think your issue is that you are running inside a privileged container, which is (nowadays) a kind of exotic environment.. I will see if we can fix this up on the package side, but you might need to implement such a manual workaround.

"grub-install.real: error: cannot find EFI directory." that sounds like you are missing a mount for the ESP. so yes, your steps look okay, please do them and then post "efibootmgr -v" and any output of the commands you did!

the ACL path is wrong - you need to give SDN.Use on the bridge/VNET, not on the VM..