Search results

the warning will be shown if a removable bootloader entry is detected, but the config isn't set up in a way that automatically upgrades it. this combination is only a problem if you also attempt to use that entry to boot, which is not the normal way of booting. so the warning is a bit over...

the problem is we currently don't have the option to limit tasks like this (it is on our TODO list!). so enabling higher concurrency within tasks without at the same time offering a way to limit the number of active tasks while queuing the rest, makes this really unpredictable.

wow, that's very strange. what kind of system is this? could you also post the output of `efibootmgr -v`? the log looks a bit like it crashes on setting the boot efi variable..

see the linked patch set, which also contains the docs that exist atm ;)

which issue? the update exposed a (configuration) issue on some systems. so now there is a warning to detect potentially affected systems so the configuration issue can be fixed before the next reboot. you need to run those commands (or fix the config in a different fashion).

that would be possible in a test build maybe, but the comments here: https://lore.proxmox.com/pbs-devel/e5a2dcac-630e-4797-bbbf-f38bc260c2ca@proxmox.com/ still apply - just blindly throwing more threads at "hot paths" very quickly causes negative results, what we actually need is a way to...

instead of "scsi10", pick the lowest free scsi slot of your VM

see https://bugzilla.proxmox.com/show_bug.cgi?id=6273 - seems like there might have been a regression there

die iso wird nicht gesichert, aber sie muss existieren damit die VM gestartet werden kann (in dem fall pausiert). s.o. viele machen das anders und laufen dann genau in dieses problem - sh. https://bugzilla.proxmox.com/show_bug.cgi?id=4225 & https://bugzilla.proxmox.com/show_bug.cgi?id=5636

seems like nobody wrote a patch yet.

the file is a valid vmdk file, please ask their support about their limitations!

then ask their support why they don't accept it, the file looks okay.

please post the output of "qemu-img info file.vmdk"

could you maybe try with a lower index (e.g., the next "free" one in your VM config?)

you should still run the command it lists, but you don't seem to have the issue the other two people here in this thread have, so maybe start a new one?

the .img file is in raw format, if you want a vmdk file you need to convert it (e.g., with "qemu-img convert" or a similar tool)

those are still not the logs I am looking for.. the logs I want are - journal of the PVE host where you do the mapping - journal of the VM that you give the mapped loop device to your logs show attempts to mount the mapped loop device on the PVE host, that is not what I am after..

let's continue in the other thread: https://forum.proxmox.com/threads/after-new-update-get-stuck-on-grub.164141/#post-758809

we need to find out why pass through doesn't work as expected, so we need logs from when you try that (from both the host and the VM side)