Support for wsl2 / tar.gz files for Windows platform.

[cdrage]

We have:

• Mac = applehv / raw
• Linux = qcow2 / raw

But nothing native for Windows.

Would be awesome to be able to generate wsl2 / .tar.gz images for native Windows support.

[veillard]

Yes I think that's a very common use case and possibly the largest population we can target from Podman Desktop so it would absolutely make sense, Plus it's a common use case that even customers have raised.

[veillard]

I think there is 2 required sub issues: 1/ Support for WSL2 in the image builder container image: this is already a preview in the online version so hopefully this is an easy step 2/ Support launching WSL2 'images' (a tarball mostly) from the lugin like we do for ISO or raw on Windows platform

[deboer-tim]

Pinging on this again. The Macadam CLI and Podman Desktop bootc extension now have the ability to create and run VMs from disk images, so if bib generated WSL2 we'd have an end-to-end flow from containerfile to running VM on Windows for the first time.

I know Windows isn't exactly the target market for Linux VMs :), but it's still the OS used by >50% of enterprise developers. So, this would double the number of developers who can easily try out bootc and confirm it works.

[cdrage]

@ondrejbudai @veillard @deboer-tim

Did some investigation and I was able to get a bootc image booting by doing the following:

1. Used podman export -o foobar.wsl quay.io/fedora/fedora-bootc:42
2. Modified the resulting WSL file by adding the configuration file by following: https://learn.microsoft.com/en-us/windows/wsl/wsl-config
3. Successfully booted it on Windows

HOWEVER. I was unable to login / ssh / etc into it, as we are lacking support for the build config YAML file.

The build config yaml is required in order for us to setup username/password/ssh in the resulting image file (iso, raw, qcow2, etc.).

I'm assuming we'd have to add this to bootc-image-builder as the build config builds / modifies the image according to the build config.

[jlsherrill]

@cdrage i sorta hacked something together to see if bootc switch would work after i got it booted and i got an error:

ERROR Switching: Initializing storage: Acquiring sysroot: Preparing for write: Detected container (ostree base); this command requires a booted host system.

Update: Okay, i made something a lot less hacky to reproduce the issue and put it here: https://github.com/jlsherrill/wsl2-bootc-reproducer/tree/main

I also opened a bootc issue here: https://github.com/bootc-dev/bootc/issues/1461

[cdrage]

@cdrage i sorta hacked something together to see if bootc switch would work after i got it booted and i got an error:

ERROR Switching: Initializing storage: Acquiring sysroot: Preparing for write: Detected container (ostree base); this command requires a booted host system.

Update: Okay, i made something a lot less hacky to reproduce the issue and put it here: https://github.com/jlsherrill/wsl2-bootc-reproducer/tree/main

I also opened a bootc issue here: bootc-dev/bootc#1461

Awesome! I just tried it out and it was great seeing it boot and all.

Only problem is the build config that's used for the other images too for us to login / ssh / etc for it.

Thanks opening up the bootc issue. I doubt bootc switch would be supported in the future, I'm assuming it's because WSL2 manages the kernel / it's not a "full" VM image.

For me it would be:

Step 1. Have a way to do bootc-image-builder output (with users and all configured, etc from build config file) the .tar.gz WSL2 file

Step 2. Be able to use bootc functions. To be honest, it does not look technically possible (at the moment) since Windows manages the kernel (RHEL in our case?).

For Step 2 IMHO I believe we should warn / tell users that for the full experience, it would require a full-VM tool such as Hyper-V, QEMU, etc. But we can discuss that in https://github.com/bootc-dev/bootc/issues/1461

[cgwalters]

If we're not running the kernel embedded in the image, it's IMO not bootc.

I think we should position it as just "custom WSL2" image which is an ordinary container image right?

It can definitely make sense to test bootc containers as containers of course, and running them via WSL2 makes total sense - we should enable that too, but it's again not really different from just running any other container image AFAIK.