make real installer image

[deitch]

This is an attempt to fix the hack of the installer image.

The way the current installer image works is the following:

1. Build a real rootfs filesystem in a squashfs filesystem file rootfs.img
2. Build a disk image with 3 partitions: INVENTORY, CONFIG and EFI, where EFI contains grub and other things to boot, as well as a cpio.gz file named installer.img
3. Loop mount rootfs.img to root, so we can use our original kernel and initrd inside rootfs.img to boot
4. Expand installer.img, which contains a simple alpine container and installer script, along with container config files, to a specific onboot path, effectively "hacking" the rootfs.img

This "hack" requires knowing exactly where the path is to the container, what numbering to give it, ensuring nothing changes elsewhere. Essentially, it is messy and brittle.

This changes it. It is not perfect, but it is a step forward.

Now, there is an actual pkg/installer, which builds a small container. That container always is part of rootfs.img, and is part of onboot. However, it only runs if the file /opt/install/true exists. /opt/install is bind-mounted from the read-only host filesystem.

The installer image works as follows:

1. Build a real rootfs filesystem in a squashfs filesystem file rootfs.img which includes the installer. changed
2. Build a disk image with 3 partitions: INVENTORY, CONFIG and EFI, where EFI contains grub and other things to boot, as well as a cpio.gz file named installer.img. unchanged
3. Loop mount rootfs.img to root, so we can use our original kernel and initrd inside rootfs.img to boot. unchanged
4. Expand installer.img (unchanged), but the contents are not just a single file /opt/install/true. changed

Because /opt/install is bind-mounted into the installer container, only when run in installer mode will it run the installer. In all other (regular) cases, it just ignores the installer.

What was changed

• pkg/mkimage-raw-efi/Dockerfile has a smaller installer.img
• pkg/installer was created
• images/rootfs.yml.in has an onboot section for installer
• tools/parse-pkgs.sh was updated to support installer

What else needs to be fixed

Several things:

• Makefile references to installer.img, although that should still work
• Usage in installer-net, which may or may not be broken from this and need to be fixed
• Size: is the addition of the installer to every rootfs.img too big? It uses no memory when in regular mode, but still takes some disk space
• The installer image mounts in the debug and pillar container directly, by naming paths. This is more of the same "ugly" that got us here, so that needs to be fixed as well. That is not a holdup for this.

Long term

Long term, we should change the whole thing to have a separate installer image. Rather than "image that contains grub and grub.cfg that knows how to loopback mount from rootfs.img and then hack that installation", it should just have its own kernel and initrd, where the initrd is just the installer.

We should do that next. But as @jsfakian is working on getting the interactive installer working in #4055, and the whole mess of getting it to work as part of the installer image, this is a valid interim step.

Help testing

Whoever can help test this installer, please do.

[deitch]

I am going to see if I can get this to be the future phase soon. What it involves:

1. Separate installer package (already in this PR)
2. Remove /opt/install/true flag from installer package
3. Remove dependencies on /opt/pillar and /opt/debug from installer package
4. Remove installer from rootfs.yml.in
5. In mkimage-raw-efi, create an initrd from the contents of the installer, that
6. Remove rootfs.img from the pkg/eve/installer/grub.cfg (L48)

In theory, that should boot it right up.

The boot process then will be:

• normal EVE: boot as usual (unchanged)
• live EVE: boot as usual (unchanged)
• installer: boot into grub (unchanged), which launches kernel from rootfs.img and initrd via initrd.img from mkimage-raw-efi and installer.img from mkimage-raw-efi. No longer boots rootfs.img.

[deitch]

Update: this now has no dependency on pillar or debug containers. It removed that in a less-than-optimal way. Since this is intended to go away anyways, I just copied over pkg/debug/spec.sh and pkg/pillar/tpmmgr.go. The go program required some mangling to be run locally, but it wasn't worth copying 63MB of zedbox when 11MB will do, especially if it is going away. We would have to do FROM lfedge/eve-pillar: and work the hash out somehow. Not worth it, especially if this is supposed to go away in favour of interactive installer in #4055.

[christoph-zededa]

Please don't copy the Dockerfile into the container

[deitch]

This is all early draft, and will change a lot in the coming days. Don't waste your time on it yet @christoph-zededa

[deitch]

But since you raised it, why not? The final image is FROM scratch anyways?

[christoph-zededa]

Because if you change something in the Dockerfile at the end, the next docker build will start from this COPY instead of from the change in the Dockerfile.

This is all early draft

Yes, forgot about it for a moment ...

[eriknordmark]

Run tests

[deitch]

I am closing this because I do not want CI to be running on it with all of the changes. When ready, I will reopen it.