Environment
- Unikraft CLI 0.4.2 (linux/amd64)
- Metro: fra
- Image: python:3.13-alpine (Linux-compat guest, reported kernel 6.5.13)
Summary
Runtime --args appear to become kernel boot parameters. Passing a moderately long argument (~900 bytes) is accepted by the CLI and the API, the instance is created, and then the guest panics during boot instead of the request being rejected.
Steps to reproduce
Pass a ~900-byte program as a single argument:
$ unikraft run --metro fra --name spike --image python:3.13-alpine \
--args=/usr/local/bin/python3 --args=-c --args="<~900 bytes of Python>" \
-p 443:8080/http+tls -m 512MiB
The instance is created and reports state: starting. unikraft instances logs spike then shows:
[ 0.004199] Kernel panic - not syncing: Too many boot init vars at `log:'
[ 0.005416] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.5.13 #2
[ 0.006446] Call Trace:
[ 0.006883] <TASK>
[ 0.007269] dump_stack_lvl+0x41/0x60
[ 0.007924] dump_stack+0x14/0x20
[ 0.008526] panic+0x15c/0x300
[ 0.009075] ? register_console+0xbc/0x410
[ 0.009798] start_kernel+0x233/0x3e0
[ 0.010447] x86_64_start_reservations+0x1c/0x30
[ 0.011254] x86_64_start_kernel+0x7d/0x80
[ 0.012894] </TASK>
[ 0.013311] Rebooting in 1 seconds..
The instance ends in stopped with stop_reason: "unknown stop", which gives no hint that the arguments were the cause.
(Note the panic names log: — the token where parsing gave up — which happened to be a variable in my program. So the limit appears to be on the number of parsed tokens, not only total length.)
Expected
The API rejects arguments exceeding the boot-parameter budget at creation time, with a message naming the limit.
Actual
Accepted, created, billed a boot, and panics with a message that requires reading guest console logs to find. stop_reason reports "unknown stop".
Impact
The failure is silent from the CLI's perspective — unikraft run returns successfully. I only found the cause by pulling instance logs on a hunch. Documenting the limit would also help; I could not find it stated anywhere.
Environment
Summary
Runtime
--argsappear to become kernel boot parameters. Passing a moderately long argument (~900 bytes) is accepted by the CLI and the API, the instance is created, and then the guest panics during boot instead of the request being rejected.Steps to reproduce
Pass a ~900-byte program as a single argument:
The instance is created and reports
state: starting.unikraft instances logs spikethen shows:The instance ends in
stoppedwithstop_reason: "unknown stop", which gives no hint that the arguments were the cause.(Note the panic names
log:— the token where parsing gave up — which happened to be a variable in my program. So the limit appears to be on the number of parsed tokens, not only total length.)Expected
The API rejects arguments exceeding the boot-parameter budget at creation time, with a message naming the limit.
Actual
Accepted, created, billed a boot, and panics with a message that requires reading guest console logs to find.
stop_reasonreports "unknown stop".Impact
The failure is silent from the CLI's perspective —
unikraft runreturns successfully. I only found the cause by pulling instance logs on a hunch. Documenting the limit would also help; I could not find it stated anywhere.