LFx Mentorship (CNCF - urunc: Integration of urunc's sandbox execution with Argo)

[cmainas]

Mentorship plan: Integration of urunc's sandbox execution with Argo

This discussion outlines the proposed plan for the CNCF mentorship project "Integration of urunc's sandbox execution with Argo"”.

The plan is structured into three phases. Each phase has clear goals and specific outcomes, along with suggested tasks and sub-tasks to help guide the work. The listed sub-tasks are meant as guidance and reference points, they are not strict requirements. The exact order of tasks within each phase can be adjusted as long as the main outcomes are achieved.

Phase 1

The goal of Phase 1 is to build the necessary background on both sides of the problem: the architecture and execution flow of Argo, and the execution model of urunc. This phase is expected to last up to 3 weeks (07/09/2026 – 27/09/2026). During this time, the focus will be on understanding how Argo turns a workflow into pods and how those pods coordinate, understanding which of these assumptions urunc breaks and scoping all the necessary fixes.

Tentative tasks and sub-tasks

• Theoretical background (Argo Workflows architecture):
  • Study the components of Argo Workflows (workflow-controller, argo-server) and the CRDs they operate on.
  • Understand how a workflow spec is turned into pods, the Argo node lifecycle and how the controller decides that a Argo node is finished.
  • Identify the role of each container in a workflow pod: the init container, the wait sidecar and the main container, and the role of the argoexec binary in each of them
  • Identify all the channels these containers use to communicate:.
• Theoretical background (urunc's execution model):
  • Get familiar with urunc's execution model; the use of sandboxes, the various rootfs types and netowkring inside a pod.
  • Study the Knative integration as a reference: what was handled inside urunc, what required an upstream patch.
• Hands on with Argo and urunc:
  • Set up a Kubernetes cluster with urunc and Argo Workflows and reproduce the integration issue.
  • Based on the theoeitical background above pinpoint the exact step of the execution flow where the coordination between the sandbox and Argo breaks.
  • Map every pod-level assumption that Argo makes against what a urunc sandbox actually provides. For each incompatibility identify whether it originates from a missing feature in urunc, from a capability the guest does not have, or from an assumption of Argo, and mark the ones that can be resolved in urunc alone

Outcome

Deadline: Completed no later than 27/09/2026 (AoE).
Description: A report with:

• the architecture of Argo Workflows and the execution flow of a workflow pod
• the execution model of urunc and the parts of it that are relevant to that flow
• a clear breakdown of the main incompatibilities, along with a compatibility matrix of Argo features against guest capabilities

Phase 2

The goal of Phase 2 is to design the integration and implement a PoC with the necessary patches in urunc. This phase is expected to last up to 5 weeks (28/09/2026 – 01/11/2026). During this time, the focus will shift from exploration to a concrete design, agreed with the maintainers, and to the implementation of the core parts of the integration: the lifecycle and signalling between the sandbox and the rest of the workflow pod.

Tentative tasks and sub-tasks

• Pick one rootfs type and guest of urunc to base a PoC (Linux over shared-fs):
  • Scope and design the necessary fixes for each issue define in the previous phase.
  • Implement the fixes for each issue till a working PoC.
  • Open the respective PRs in urunc.
• Generalizing the PoC to other toofs types:
  • For each rootfs type define the contract between the sandbox and the wait sidecar: what signals the completion of a step, where the exit status is published, and which ordering guarantees are required.
  • For each rootfs type design a solution with all the necessary fixes and where they should live: (in urunc, the monitor or inside the sandbox).
  • Add support for the input and output parameters and artifacts of a step for the guests and define how the data reaches the guest and how it is collected back
  • Analyze the alternatives, list the side effects of each one.
• Start the work to upstream the necessary PRs:
  • Draft PRs for each rootfs type and specific fix.

Outcomes

Deadline: Completed no later than 01/11/2026 (AoE).
Description: The following items:

• A design document describing the integration, the alternatives that were considered and the side effects of the chosen approach.
• Open PRs with the changes in urunc (e.g. sandbox lifecycle, signalling networking) for each rootfs type.

Phase 3

The goal of Phase 3 is to complete the integration, finalize the changes, create the necessary documentation and perform some basic evaluation. This phase is expected to last up to 4 weeks (02/11/2026 – 27/11/2026). During this time, the focus will be on the necessary testing, tutorials and evaluation comparing the normal vs "urunc's" execution model.

Tentative tasks and sub-tasks

• Finalize and test:
  • Merge the remaining PRs from the previous phase.
  • Provide the necessary unit and integration tests for the new changes.
  • Add an end to end test in urunc's CI that runs an Argo workflow.
• Documentation and tutorial:
  • Write a tutorial in urunc's documentation showing how to deploy and run Argo workflows with urunc, covering the setup, the configuration and a few example use cases
  • Document which Argo features are supported for which guest and monitor capabilities and clearly state the remaining limitations
• Evaluation:
  • Measure the overhead that a sandboxed step adds to a workflow compared to a step running as a plain container.
  • Analyze the overhead for each rootfs type and identify the bottlenecks.
• Expanding the current support (time permitting):
  • Explore the rest of the Argo ecosystem (Argo Events, Argo CD, Argo Rollouts) and identify what else would be required for urunc to fit in them
  • If a change on the Argo side turned out to be necessary, prepare and propose it upstream

Outcomes

Deadline: Completed no later than 27/11/2026 (AoE).
Description: The following items:

• Merged PRs with the complete integration, along with the unit, integration and end to end tests.
• A tutorial in urunc's documentation for deploying and running Argo workflows with urunc.
• A report summarizing all the work, the evaluation results and the remaining limitations.

[cmainas]

Hello @indrajithekanayake,

please take a look on the above plan and feel free to suggest any changes. If you agree with everything just reply here that everything looks ok.

[indrajithek]

Hi @cmainas, I'm happy with the proposed plans.
One suggestion: Linux guest and unikernel guest possibly have to be tested separately shall we embed that somewhere at the end of Phase 1 (if you agree with the above)

Also, one question: When we refer to different rootfs, we are referring to shared and non-shared rootfs(i.e., initrd, block-backed) corect?

The rest looks good and archivable.

PS: I'm documenting my weekly LFX-urunc work here: https://indrajith.net/lfx-brain/lfx. Everything related to #1027 will be copied to this discussion thread too for transparancy

[cmainas]

Hello @indrajithekanayake ,

there are currently 4 options in urunc related to rootfs:

1. No rootfs at all, meaing that the guest is just an application that does not need rootfs.
2. Initrd-based rootfs, the rootfs is in the form of a cpio file.
3. Block-based rootfs where the rootfs is a block image inside the contianer image or a block device through the use of a bock-based snapshotter (devmapper, blockfile).
4. Shared-fs based, where the guests shares a directory with the host. This directory contains the rootfs of the container image and the mounts speciifed in the mount list of the container spec.

I will agree with you that Linux is more straightforward compared to other guests. However, in my pionion the guest does not matter that much as the rootfs type. In the case of shared-fs the guest shares the container's rootfs with the host and therefore the integration can be much easier. I have slightly updated the plan and mentioned that the PoC to be implemented over Linux with shared-fs.

[indrajithek]

Argo Integration Report

This is an impromptu working document(so do expect typos and bad grammar). I will be updating this weekly. All my experiment logs and steps to reproduce can be accessed here: https://github.com/indrajithek/urunc-argo-intigration/tree/main

Problem introduction

The problem highlighted here #573 (specifically #135, and #882). In summary, Argo Workflow spawns three containers inside the pod: init, wait, and main. The visible issue on the surface is we can see that the main and init have successfully terminated, while wait keeps running.

For that specific problem issue is "execution-model mismatch". The bigger question is execution-model mismatch to what level? We don't really know. That's what we gonna find out at the end of Phase 1 by analyzing Argo and Urunc execution models.

Also, we cannot say that if wait container stops, everything will be sorted. While that provides an initial POC, we need to continue testing under different constraints to see how Argo Workflows react. Those test scenarios I will update somewhere in this document once we have a working POC.

1. Understanding Argo Workflows execution model (with runc)

The full log dump of this experiment can be found here: https://github.com/indrajithekanayake/urunc-argo-intigration/tree/main/argo-runc

I'm using k8s cluster built with kubeadm to understand mechanically what Argo Workflows does on a machine (Please note that I do not have access to a bare-metal machine, so I am working on an Ubuntu VM with nested KVM virtualization). I'm not using a logging stack because I think it will make the logs messy by spawning so many processes (Flannel is chosen over Calico also for the same reason). Priority is given to logging processes and Im using;

1. journalctl for service logs
2. kubectl logs for container logs
3. snap.sh for snapshots; Also, AI suggested process-level tracing uses BPF execsnoop instead of auditd for spawn sequence tracing(which I'm not much familiar with). But will test that too

So I'm running experiment.yaml which will write EXPERIMENT-BEGIN marker to stderr and the result to stdout

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: experiment-
spec:
  entrypoint: demo
  templates:
    - name: demo
      script:
        image: python:alpine3.23
        command: [python]
        source: |
          import sys, time
          print("EXPERIMENT-BEGIN", file=sys.stderr, flush=True)
          time.sleep(300)
          print("42")

Later, once we have a basic POC, we need to test the other two types of Argo Workflows with unikernels(i.e., DAGs and sequential workflows)

The original unpacked argoexec image (comes from quay.io/argoproj/argoexec:v4.1.4) is basically around 166.6MB and at the usual location for all unpacked images /var/lib/containerd/. Both init and wait containers spawn from this image. But they never co-exist. In the above example, init ran and exited before anything else started 11:28:43.197 → 11:28:43.283.

Container	Image	Created	Started	Finished	Alive	Exit
init	quay.io/argoproj/argoexec:v4.1.4	11:28:43.150	11:28:43.197	11:28:43.283	0.087 s	0
wait	quay.io/argoproj/argoexec:v4.1.4	11:28:47.304	11:28:47.431	11:33:48.001	300.570 s	0
main	python:alpine3.23	11:28:47.700	11:28:47.768	11:33:47.889	300.121 s	0

Interestingly enough, before init exit it copies argoexec executable/binary (the image is basically one Go executable/binary, so same size as above; 166.6MB) into /var-run-argo/argoexec emptyDir for the main container to use.

ex (look at the copied argoexec binary snapshot below):

/var/lib/kubelet/pods/c6903810-78f0-485c-8bf7-f39d6b3e552c/volumes/kubernetes.io~empty-dir/var-run-argo/argoexec     166,569,319 bytes

var-run-argo is not the only emptyDir we are dealing with here. Three emptyDirs' created per pod and destroyed when that pod dies. Its path is keyed by the pod UID. I think it would be better to put in a diagram.

In addition to the emptyDirs' there is projected volume mounted the service-account token to all three containers read-only. Only wait ever uses it (because wait requires the executor Role to communicate the exit code to the API server, and the ServiceAccount credential materials are stored in this projected-volume).

The main actually does the craziest part. Instead of letting runc to launch python /argo/staging/script, main launches it as a child under the argoexec emissary with /var/run/argo/argoexec emissary -- python /argo/staging/script

wait logged completion 1 ms after emissary logged sub-process exited (so Im assuming it's file watch)

Also, I noticed stdout 42 is only printed in the terminal. Since our workflow is a single step with nothing after, Argo skips capturing the stdout. This was printed in the init and wait container logs as includeScriptOutput=false. test this behavior again when running multi step, DAG workflow. When another pod references to scripts stdout result this must become true

BPF execsnoop was started before the workflow was submitted, so every exec below is caused by this pod/ sandbox. I've used a Python script to reconstruct the spawn sequence below from the /root/argo-lab/captures/execsnoop.log

TIME	TREE (indent = ancestry)	PID	CONTAINER
	containerd	96334
11:28:42	└─ shim SPAWN	98658	sandbox
11:28:42	└─ shim SERVE ← the pod's shim	98666	sandbox
11:28:42	└─ runc create	98677	sandbox
11:28:42	└─ runc start	98696	sandbox
11:28:42	└─ pause ← ENTRYPOINT	98690	sandbox
11:28:43	└─ runc create	98703	init
11:28:43	└─ runc start	98723	init
11:28:43	└─ argoexec init ← ENTRYPOINT	98717	init
11:28:43	└─ runc kill --all	98737	init
11:28:43	└─ runc delete	98743	init
11:28:46	└─ shim REAP	98753	init
11:28:46	└─ runc delete --force	98761	init
11:28:47	└─ runc create	98789	wait
11:28:47	└─ runc start	98808	wait
11:28:47	└─ argoexec wait ← ENTRYPOINT	98801	wait
11:28:47	└─ runc create	98822	main
11:28:47	└─ runc start	98842	main
11:28:47	└─ argoexec emissary ← ENTRYPOINT	98836	main
11:28:47	└─ python /argo/staging/script	98858	main
11:33:47	└─ runc kill --all	106595	main
11:33:47	└─ runc delete	106601	main
11:33:47	└─ shim REAP	106608	main
11:33:47	└─ runc delete --force	106616	main
11:33:48	└─ runc kill --all	106621	wait
11:33:48	└─ runc delete	106627	wait
11:33:49	└─ shim REAP	106645	wait
11:33:49	└─ runc delete --force	106653	wait
11:33:50	└─ runc kill	106659	sandbox
11:33:50	└─ runc kill --all	106666	sandbox
11:33:50	└─ runc delete	106672	sandbox
11:33:50	└─ shim REAP	106678	sandbox
11:33:50	└─ runc delete --force	106686	sandbox

2. Execution model of urunc (relevant parts for the Argo integration)

More information will be appended over time as my mental image of urunc improves over time.

Below, I tried to put together the urunc execution architecture for the 3 types of guests we have,

Guest Type	OS / Kernel	Filesystem	Initialization	Application Execution	VMM / Monitor
1. Linux Guest	Linux kernel	Initrd, block/devmapper, 9pfs, virtiofs	urunit (when configured)	urunit launches the application	QEMU, Firecracker, Cloud Hypervisor
2. FreeBSD Guest	FreeBSD kernel	Block/devmapper, 9pfs	urunit (when configured)	urunit launches the application	QEMU, Firecracker
3. Unikernel Guest	Unikernel (OS + application)	Initrd, block/devmapper, shared filesystem (9pfs for supported Unikraft configurations), in-memory filesystem, or no separate rootfs	Unikernel-specific	Integrated application or framework-specific execution	QEMU, Firecracker, Solo5, etc.

3. Breakdown of the main incompatibilities, along with a compatibility matrix of Argo features against guest capabilities

More information will be appended over time when I come up with new incompatibilities, plus when my understanding of urunc improves over time. Identifying compatibility matrix I will do later given the list can be exhaustive and maybe not so necessary too

Below is a known list of incompatibilities withhold argo intigration with some priority indication (🔴 > 🟡 > 🟢). The green ones are low priority things that break when Im running tests. They dirrectly do not affect argo intigration but worth fixing:

• 🔴 urunc has no exec OCI-runtime subcommand, causing Argo Workflows (and any exec-dependent controller) to hang forever #882 Argo uses kubectl exec to stop containers. The docs describe this for injected sidecars. Well well well I initially thought this was not a priority, but this turned out to be a high-priority requirement. In the experiment below there were 3 exec calls, and v0.8.0 has no exec, so all three attempts failed
• 🔴 Passing app arguments on the kernel command line quietly mangles some of them #1067 Need immediate fix in POC stage
• 🟢 The containers urunc hand over to runc are placed under /system.slice/... instead of the pod's slice #1105 Just a correction issue not a blocker. No major impact on Argo compatibility.
• 🟢 Refactor and use libcontianer to setup the execution environment for the monitor process #780 In following experiment main exited 1 s so I don't have cgroup captures to prove (Note to me: take a look at this in later experiment). However, I think given libcontainer=false by default, no cgroup is created at all. So QEMU and virtiofsd stay in whatever cgroup their parent was in ( shim's cgroup under system.slice). The problem is VM's memory (guest RAM, 1024 MiB in our config, plus QEMU and virtiofsd) isn't counted as the pod's usage. It's charged to the shim's/containerd's cgroup instead.

My first instinct on the above was to test with libcontainer=true and I did. With that libcontianer library created cgroup for the VM but again in the wrong place. It landed in /system.slice/kubepods-pod<uid>.slice:cri-containerd:<id>, not inside kubepods.slice/…. It redirects us again to #1105 and solving that would fix this too. Also, it led to another discovery in pkg/unikontainers/libcontainer_cgo.go:67, urunc replaces the whole resources section with a new one that only says "allow all devices". That throws away the memory and CPU limits, and VM now has memory.max=max and cpu.max=max. So I guess worth opening another issue. Note: before opening an issue wrote small patch but it led to OOM, so it seems a deliberate design choice. But maybe from inspiring from kata we can introduce overhead I added my findings in #127 as a comment, given this will be something maintainers work on.

[indrajithek]

Please let me know if there are any suggestions for the phase 1 report. I will keep adding incompatibilities to the list on the go. Other than that I feel we can consider it as complete.

[cmainas]

The report looks good. We can consider it completed.

[indrajithek]

Below is the ArgoCon Europe draft. Currently, @cmainas and I have edit access. If anyone else requires access, please send a request.

CFP deadline: Sunday, 18 October 2026, at 11:59pm Central European Time (UTC+2)

https://docs.google.com/document/d/1TGLaSP5rMxJQBxVSQHzL1fPkX7qyilYvnUOF_veuIwg/edit?usp=sharing

[indrajithek]

Design document describing the integration

This is an impromptu working document(so do expect typos and bad grammar). I will be updating this weekly. All my experiment logs and steps to reproduce can be accessed here: https://github.com/indrajithek/urunc-argo-intigration/tree/main

1. POC for #135 hang (urunc v0.8.0 Linux virtiofs guest)

The full log dump of this experiment can be found here: https://github.com/indrajithekanayake/urunc-argo-intigration/tree/main/argo-urunc

In urunc v0.8.0, the Linux guest can boot in 3 ways basically,

1. shared fs (host fs shared with guest VM)
2. block (container rootfs is attached to the VM as a disk; devmapper or block image)
3. initrd (rootfs packed into an initrd and booted from RAM)

For Unikernel guest, there is this 4th option too, which is no rootfs at all

As we discussed at the starting point, I'm focusing on shared fs because in block or initrd, urunc shares no host directories with the guest, which will make POC bit complicated.

For logging I'm using the same logging stack I used before, with some changes to snap.sh (please check those out in the experiment dump repo in my personal GH). In experiment.yaml made four changes

1. Set the build to start with the bunny image (python:alpine3.23 plus the 6.12.36 virtiofs kernel)
2. The image exists locally, so imagePullPolicy: Never
3. Set runtime class to urunc
4. 32 is the Linux kernel's limit on environment variables passed to init from the boot command line. Strangely urunc v0.8.0 puts the container's env vars on the kernel command line. In the experiment below, I went out of the limit. Removing service links through the enableServiceLinks: false flag (we had 16 of them) brought it down to 25 variables, which is under the 32 cap. I feel this has to be addressed. Oh wait, new finding: I saw (actually, my Claude agent saw) the feat/unchanged_containers branch always boots urunit, so env already goes through the config there, while args still go on the command line. Edit after some time: some of my understanding here seems wrong; I wrote a detailed explanation under Passing app arguments on the kernel command line quietly mangles some of them #1067. Please refer to that as it gives the full picture

So the final experiment.yaml comes as below

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: experiment-
spec:
  entrypoint: demo
  podSpecPatch: '{"runtimeClassName":"urunc","enableServiceLinks":false}'
  templates:
    - name: demo
      script:
        image: docker.io/urunc-argo/python-linux-qemu:135
        imagePullPolicy: Never
        command: [python]
        source: |
          import sys, time
          print("EXPERIMENT-BEGIN", file=sys.stderr, flush=True)
          time.sleep(300)
          print("42")

Three exit codes were coming from main (from different layers). Exit code 64 is written into ctr/main/exitcode which is the emissary panic running Python due to bug #1067, exit code 2 comes from Go upon argoexec process death, exit code 0 is what kubelet record as main's exit code upon QEMU shutdown.

Container	Image	Started	Completed	Duration	Exit code
init (urunc → runc)	quay.io/argoproj/argoexec:v4.1.4	20:17:09.266	20:17:09.350	84 ms	0, Completed
wait (urunc → runc)	quay.io/argoproj/argoexec:v4.1.4	20:17:16.716	20:19:42.785	2 min 26.1 s	64, Error: no route to host to the API server
main (urunc → QEMU)	docker.io/urunc-argo/python-linux-qemu:135 (local)	20:17:17.120	20:17:18.148	1.03 s	0 CRI 2 argoexec process 64 ctr/main/exitcode

Overall in urunc v0.8.0 Linux virtiofs guest #135 hang does not happen. It occurs in older versions plus initrd and block file system only. There are 3 new hangs in shared fs. Observing the process tree helps us understand what's exactly wrong.

• The kernel drops everything after the second -- on its command line. Emissary started with no command, panicked, and wrote exitcode 64. This will be addressed under Passing app arguments on the kernel command line quietly mangles some of them #1067 (PR fix(linux): pass the application command to urunit in config #1136 )
• Wait read that code but could not reach the API server. urunc's tc rule sends all pod eth0 traffic to the VM's tap device, and wait shares the pod network. wait exited with an error and the workflow went to Error. Knative integration had similar issue, i need to look bit futher how it was sorted and open op sevaral issues on this to work on next week.
• Once main has terminated, the controller signals every still-running container with argoexec kill. The request reaches urunc through the pod's single urunc shim. v0.8.0 has no exec, so all three attempts fail with OCI runtime exec failed: urunc did not terminate successfully.

TIME	TREE (indent = ancestry)	PID	CONTAINER
	containerd	1162774
20:16:48.719	└─ shim SPAWN	not captured	sandbox
20:16:48	└─ shim SERVE ← the pod's shim (containerd-shim-urunc-v2)	1171865	sandbox
20:16:48.727	└─ urunc create → runc create	1171881	sandbox
20:16:48.754	└─ urunc start → runc start	1171905	sandbox
20:16:48	└─ pause ← ENTRYPOINT	1171899	sandbox
20:17:09.250	└─ urunc create → runc create	1172054	init
20:17:09.266	└─ urunc start → runc start	1172078	init
20:17:09	└─ argoexec init ← ENTRYPOINT	1172071	init
20:17:09.352	└─ urunc kill --all → runc	1172098	init
20:17:09.356	└─ urunc delete → runc	1172109	init
20:17:15.662	└─ shim REAP	not captured	init
20:17:15.667	└─ urunc delete --force → runc	1172164	init
20:17:16.700	└─ urunc create → runc create	1172185	wait
20:17:16.715	└─ urunc start → runc start	1172209	wait
20:17:16	└─ argoexec wait ← ENTRYPOINT	1172202	wait
20:17:17.113	└─ urunc create (urunc.json found: linux, qemu)	1172239	main
20:17:17.114	└─ nsexec stage-0	1172246	main
20:17:17.114	└─ nsexec stage-1 (setns into pause's ipc, uts, net)	1172247	main
20:17:17.116	└─ nsexec stage-2 = urunc reexec	1172248	main
20:17:17.120	└─ urunc start	1172254	main
20:17:17.121	└─ urunc reexec: tap0_urunc + eth0 → tap tc redirect	1172248	main
20:17:17.122	└─ qemu-system-x86_64 ← ENTRYPOINT (execve, same PID)	1172248	main
20:17:17.123	└─ virtiofsd	not captured	main
20:17:17.840	└─ [guest] argoexec emissary (init=, guest PID 1)	guest 1	main
—	└─ [guest] python /argo/staging/script ← never started	—	main
20:17:18.150	└─ urunc kill --all ("no such process")	1172276	main
20:17:18.154	└─ urunc delete	1172283	main
20:17:20.799	└─ shim REAP	not captured	main
20:17:20.803	└─ urunc delete --force	1172321	main
20:17:31.968	└─ urunc exec ← argoexec kill 15 1 (rejected)	not logged	wait
20:17:42.190	└─ urunc exec ← argoexec kill 15 1 (rejected)	not logged	wait
20:18:01.985	└─ urunc exec ← argoexec kill 9 1 (rejected)	not logged	wait
20:19:42.787	└─ urunc kill --all → runc	1174397	wait
20:19:42.791	└─ urunc delete → runc	1174408	wait
20:19:44.364	└─ shim REAP	not captured	wait
20:19:44.368	└─ urunc delete --force → runc	1174449	wait
20:19:46.173	└─ urunc kill → runc	1174454	sandbox
20:19:46.179	└─ urunc kill --all → runc	1174466	sandbox
20:19:46.183	└─ urunc delete → runc	1174478	sandbox
20:19:47.118	└─ shim REAP	not captured	sandbox
20:19:47.122	└─ urunc delete --force → runc	1174497	sandbox

TBC...

There could be more things to work on but above two has to sorted first IMO... So currently im working on it

2. POC for #135 hang (urunc v0.8.0 Unikernel guest with initrd-based rootfs)

TBC...

3. POC for #135 hang (urunc v0.8.0 Unikernel guest with Block-based rootfs)

TBC...