Bug: Kernel Set Fails With Symlinks In Tarballs

Aug 9, 2025 by Henrik Larsen 48 views

Bug: `kernel set` Fails to Handle Symlinks Within Tarball in Container System

Hey everyone,

We've got a tricky bug to tackle today that's causing some headaches when using the container system kernel set command with symlinks inside tarballs. Let's dive into the details and see what's going on.

Understanding the Issue

This issue arises when the container system kernel set command encounters a symbolic link (symlink) within a tarball. Specifically, the command doesn't correctly handle these symlinks, leading to errors and container launch failures. This can be a major roadblock, especially when you're trying to deploy containers with specific kernel versions or configurations.

The core problem lies in how the container system extracts and activates the kernel image when it's a symlink. Instead of following the symlink to the actual kernel binary, it seems to get stuck on the symlink itself, leading to file not found errors or other unexpected behavior. This symlink handling issue affects the container's ability to start properly and can also interfere with setting the recommended kernel.

To really understand the impact, let's walk through a scenario. Imagine you're using a pre-built kernel package where the main kernel image is a symlink pointing to the actual kernel file. When you try to set this kernel using the container system kernel set command, the system might extract the symlink but not the actual kernel, or it might try to use the symlink as if it were the kernel itself. This is like trying to start a car with just the key fob – you need the actual key (or in this case, the kernel binary) to get things moving.

The symptoms of this bug are quite clear. You'll likely see errors during the container run, such as "The virtual machine failed to start," or when setting the recommended kernel, you might encounter errors related to file existence or permission issues. These errors are your clues that a symlink might be the culprit. In essence, this bug disrupts the normal workflow of setting and using custom kernels, which is a critical feature for many container deployments. The symlink issue prevents the correct kernel from being loaded, leading to the container failing to initialize and run. This can halt development and deployment pipelines, making it a priority to resolve.

Steps to Reproduce

To reproduce this bug, follow these steps:

Download a Kata Containers release:

curl -O 'https://github.com/kata-containers/kata-containers/releases/download/3.19.1/kata-static-3.19.1-arm64.tar.xz'

Set the kernel using the container system kernel set command:
```
container system kernel set --tar `pwd`/kata-static-3.19.1-arm64.tar.xz --binary opt/kata/share/kata-containers/vmlinux.container
```
- Note: Inside kata-static-3.19.1-arm64.tar.xz, vmlinux.container is a symlink to vmlinux-6.12.36-160.
Run a container:
```
container run <...>
```

Attempt to set the recommended kernel:

container system kernel set --recommended

Run a container again:
```
container run <...>
```

Current Behavior

Here's what you'll likely experience when you run through these steps:

Step 2: The requested kernel image is extracted and activated, which is what we expect.
Step 3: Running a container fails with the following error:
```
Error: unknown: 
```