Open Guikingone opened 2 months ago
Hey @Guikingone, thanks for the report. This is not a fun error, because the best we can do here is shorten one of the intermediate directories (the UUID) to the machine name.
For now, a temporary mitigation for you is to update the runtime_dir
in the KraftKit config file (located at ~/.config/kraftkit/config.yaml
) to something shorter, e.g. /Users/__USERNAME__/.kraftkit/
).
I'll contact the QEMU folks to see if this issue has been solved in a newer version or whether it's still an issue that can be resolved. I know they're busy preparing v9 at the moment.
I have opened up an issue on QEMU's issue tracker: https://gitlab.com/qemu-project/qemu/-/issues/2292
Hi @nderjung ๐๐ป
Thanks for the fast feedback, updating the path seems to allow to launch the machines, I'm facing some issues regarding the platform but it resolve the main issue here, thanks ๐
@Guikingone no problem. There are some replies with more information on the QEMU issue; looks like it's OS specific. Maximum is roughly 108 characters.
One of the things we're contemplating is changing the runtime_dir
to something like /var/lib/unikraft/
; but this would require updating install scripts, documentation, permission checks, etc.
Describe the bug
Hi ๐๐ป
When using the
kraft run
command locally, it seems that when the Qemu path generated can trigger an error if the path is longer than 104 bytes:The hardware emulation is found and the process seems to be ready to launch but Qemu seems to don't like too long path, is there any way to change the maximum bytes allowed in the path of maybe change the path where the socket is created?
Thanks again for the help and have a great day ๐
PS: For more informations, I'm on mac M1 chip.
Steps to reproduce
kraft run -p 8080:80 unikraft.org/nginx:latest
Expected behavior
No response
Which architectures were you using or does this bug affect?
arm64
Which operating system were you using or does this bug affect?
macOS
Relevant log output