Day 50: Building some tarballs for puzzles, and trying to make a kernel boot faster

Speeding Up Kernel Boot in Firecracker

Friday's work covered three areas: accelerating kernel boot in Firecracker, packaging puzzles as tarballs, and loading those tarballs into VMs at startup.

Two Boot Delays

The kernel boot process showed two pauses: one lasting 0.3 seconds and another for 0.5 seconds. The first delay traces back to the i8042 keyboard controller driver probing for an auxiliary device. Adding the i8042.noaux kernel option removed that pause entirely.

The second delay remains unexplained. One suggestion pointed to secure boot, but after trying six different kernel configurations, no fix surfaced. That investigation was set aside for the day.

Building Puzzle Tarballs with Docker

A small Python script builds each puzzle. It runs a build.sh script inside a Docker container, then packages the container's working directory into a tarball. The trick: leveraging knowledge of Docker's internal overlayfs layout and archiving just the upper layer of the overlay directly.

This approach sidesteps limitations in standard Docker interfaces. An experimental docker build --squash feature was tried but didn't yield usable results.

Loading Tarballs at VM Startup

A simple Go function handles tarball loading when a VM starts. The implementation is intentionally straightforward: mount the image, extract the tarball into the mounted directory, and unmount.

The design choice to shell out to mount, umount, and tar rather than using Go's native archive package was deliberate. These command-line tools are well-established and reliable; reimplementing them in Go would likely introduce bugs that would then require maintenance.

Filesystem Design Ideas

A conversation about filesystems raised alternatives to the current device mapper approach. Firecracker lacks qcow2 support, prompting discussion around different methods for supporting overlay images. There's also an ongoing GitHub discussion about implementing a virtio backend that would allow a VM to share a directory directly from the host, which could simplify the whole packaging and loading flow.