Search results

the 6.17.9 kernel is now on pve-test, please ensure you also have amd64-microcode and latest system firmware ("BIOS") updates installed if your system has an AMD Zen 5 based CPU: see "AMD Zen5 CPU issue with RDSEED instruction on kernels newer 6.17.9" in...

I think I found the offending commit, a fix for it is in 6.17.5, we already have a 6.17.9 based kernel in internal testing that should hit the public repositories this week..

okay, those should not be affected by the quirk setting..

similar symptoms reported in https://bugzilla.proxmox.com/show_bug.cgi?id=7249

thanks. so between 6.17.2 and 6.17.4 a quirk for a specific NVME model was added.. you could post "lspci -vvv" for both NVMEs in your system? thanks!

thanks! so that one seems to be PCIe/nVME related ( as opposed to the CPU stuck messages by other users). what kind of nVME is this? which previous kernel version worked for you on this system?

because it's a Linux based piece of software, and Linux doesn't care about such things (paths are sequences of bytes). shell handling does require extra attention, that's why tools like find and xargs have special modes: $ find . -iname "*001D9C7A*" -print0 | xargs -0 ls -lha -rw-r--r-- 1...

https://bugzilla.proxmox.com/show_bug.cgi?id=7244

there are no plans for this at the moment as far as I know. to mirror an APT repository (correctly), you need to do partial syncs in the right order and have some safety checks built-in, or have a way to synchronize mirroring and repository updates, no matter whether you are using rsync or plain...

could you try once more with "quiet" removed from the kernel commandline?

a totally unrelated one that just had a similar name :)

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"?