Who owns C:\Program Files\Linux Containers?

[TBBle]

I was trying to understand the current state of LCOW, and when poking around, discovered I have:

• C:\Program Files\Linux Containers\initrd.img dated 16th December 2020 1:17pm
  • Contains gcs.commit with text 92ea373 (somewhere between 0.39 and 0.40)
  • Files in here are generally time-stamped 2019-03-18, which matches that commit as being the initrd.img src
• C:\Program Files\Linux Containers\kernel dated 16th December 2020 1:17pm
  • Contains uname string 4.19.27-linuxkit (root@82332b297024) #1 SMP Sun Mar 10 18:51:44 UTC 2019.
  • This suggests it was built from Update kernel/opengcs/runc linuxkit/lcow#41
• C:\Program Files\Linux Containers\versions.txt dated 15th November 2018 7:29pm
  • This points to https://github.com/linuxkit/lcow/releases/tag/v4.14.35-v0.3.9
  • This also points to Add 4.19 kernels (and remove 4.18 for arm64 and s390x) linuxkit/linuxkit#3211 (between v0.6 and v0.7)

So my first question is, who owns this directory? It's possible I was manually playing with LCOW setup in 2018, but I'm sure I'd remember touching it in late 2020. A quick poke around suggests that on Windows Server, I'd have to manage this directory myself, so perhaps Docker Desktop was or is managing it for me here (Windows 10)?

My guess is that Docker Desktop was managing it for me, and installed the versions pointed at by versions.txt (i.e. the last https://github.com/linuxkit/lcow release), and something else has updated it since with a between-releases opengcs build and unreleased https://github.com/linuxkit/lcow kernel build, and didn't update or remove versions.txt, which is now orphaned. (Which is a shame, as it would have pointed me directly to linuxkit/lcow#41 for example, rather than having to open the kernel in an editor)

Perhaps Docker Desktop is still managing this, but lost track of versions.txt? I see C:\Program Files\Docker\Docker\resources contains lcow-kernel and lcow-initrd.img with the same timestamps and sizes, along with other files similarly timestamped, which suggests they were installed as a Docker Desktop for Windows update, presumably 3.0.0, even though Docker had deprecated LCOW support itself by then.

Anyway, my second question is what is the plan for opengcs distribution in the future? I see that there's an 0.4.0 release of OpenGCS (the last version that would work with current Docker implementation) from which I could build an initrd, but I don't know if I should have expected that to appear somewhere via Docker or otherwise, or should be managing it myself?

https://github.com/linuxkit/lcow is archived as of March 2020, so I have similar questions about a kernel flow to go with the OpenGCS initrd. Is there any chance of that being replaced with, say, https://github.com/microsoft/WSL2-Linux-Kernel, or do they have sufficiently conflicting needs to make that infeasible? It seems like they are using the same underlying VM Platform system, but that might be unwarranted conflation.

SInce I mention the WSL2 kernel, is there any consideration of moving the servicing of C:\Program Files\Linux Containers (or at least its contents) via Windows Update, like C:\Windows\System32\lxss\tools\kernel now is?

[katiewasnothere]

I believe Docker LCOW is what uses and owns C:\Program Files\Linux Containers. We no longer use that for cri-containerd (see here for the directory we do use). Since Docker LCOW is deprecated, we haven't done any work there to update how the files you mentioned are managed or created or anything.

We have no plans to distribute opengcs or any of the other files mentioned from our side. You can however still use the opengcs project to make your own gcs to be used for LCOW. See the gh actions workflow for an example.

Side note: we're working to move the opengcs project into the hcsshim repo (see microsoft/hcsshim#973). Nothing about the above should change other than where the code is located.

[TBBle]

I was looking at that exact piece of code when trying to self-answer this question, but assumed the LinuxBootFiles sub-dir was for debugging or bundling, and that the default expectation would remain the last line, filepath.Join(os.Getenv("ProgramFiles"), "Linux Containers").

I'm happy to be answered with "It's Docker's problem". The prompt for the exploration was a discussion about LCOW v2 and Docker migrating to containerd on Windows and hence perhaps getting non-deprecated LCOW via Containerd.

If I understand correctly, cri-containerd is not expecting to share that directory but be bundled with the necessary boot files, similar to the containerd/runhcs shim relationship. I see that there's an annotation io.microsoft.virtualmachine.lcow.bootfilesrootpath to override the default, so it may be not a bundler responsiblity, but a user/distributor responsibilty?

I see no existing setup in the containerd repo for providing default Linux boot files, and assume Docker as a bundler of containerd won't care about this until (at minimum) they have containerd non-experimentally on Windows, and want to have undeprecated LCOW support via that.

[dcantah]

Finding where it's actually assigned the default was a bit annoying, but it's here in the old vendored in opengcs: https://github.com/moby/moby/blob/7f0fb3eccfab58fcda732d9463856a254afb0221/vendor/github.com/Microsoft/opengcs/client/config.go#L84

With the graphdriver comments giving a small nod to it: https://github.com/moby/moby/blob/7b9275c0da707b030e62c96b679a976f31f929d3/daemon/graphdriver/lcow/lcow.go#L31