overlay.d/05core: support booting ISO completely from RAM

[dustymabe]

It has been presented to us a use case where the user wants to actually "install" directly to the same device that was used to boot the live ISO image (i.e. the ISO was written to a block device and then booted from). The way the ISO boots today it mounts the ISO at /run/media/iso and then mounts the CoreOS rootfs from a file under that mountpoint. In this scenario /run/media/iso will be busy and can't be unmounted because the root filesystem of the live running system depends on it.

We can adjust the strategy slightly to get a system that runs completely from memory (similar to live PXE systems) by just copying the file out of /run/media/iso and into memory before doing the rootfs mount, which will allow /run/media/iso to be unmounted before the installation commences.

This patchset adds a new coreos.liveiso.fromram option to allow requesting this new behavior. We could consider making this new behavior the default, but we'd need to consider the new RAM requirements. For example, before this change on a 2G FCOS system the usage after booting looks like:

[core@localhost ~]$ free -m
               total        used        free      shared  buff/cache   available
Mem:            1953         163        1286         125         503        1519
Swap:              0           0           0

With this change (and the coreos.liveiso.fromram kernel arguemnt
specified) the usage looks like:

[core@localhost ~]$ free -m
               total        used        free      shared  buff/cache   available
Mem:            1953         173         688         808        1091         824
Swap:              0           0           0

The usage would scale with the size of the rootfs. i.e. RHCOS is larger so the memory requirements would be larger too.

[dustymabe]

tests for this over in coreos/coreos-assembler#3555

[cgwalters]

In theory too what we could do is make the whole thing dynamic using something like devicemapper - basically we only need to move ourself to RAM when we go to do an install. So we could e.g. set up devicemapper raid in raid1 backed just by the ISO originally.

Then when we want to run coreos-installer, we create the ramfs and add it to the raid, then wait for the raid to sync, then unplug the disk.

Or maybe dm switch ?

But...dunno, maybe a kernel argument is just simpler.

[cgwalters]

An interesting thing here is this becomes an API we need to maintain ~forever...but so far I don't think our initramfs glue has really had any public APIs? And hence there's no explicit place to document this in this repo, we'd need to add it to fedora-coreos-docs.

[dustymabe]

An interesting thing here is this becomes an API we need to maintain ~forever...but so far I don't think our initramfs glue has really had any public APIs? And hence there's no explicit place to document this in this repo, we'd need to add it to fedora-coreos-docs.

I imagine we'd document it wherever coreos.live.rootfs_url is documented.

[dustymabe]

In theory too what we could do is make the whole thing dynamic using something like devicemapper - basically we only need to move ourself to RAM when we go to do an install. So we could e.g. set up devicemapper raid in raid1 backed just by the ISO originally.

Then when we want to run coreos-installer, we create the ramfs and add it to the raid, then wait for the raid to sync, then unplug the disk.

Or maybe dm switch ?

But...dunno, maybe a kernel argument is just simpler.

Yeah. In this kernel arg scenario coreos-installer itself doesn't need to know or care, which I think makes things more simple.

When it comes to modifying coreos-installer, I think we should still do the kexec option in coreos/coreos-installer#791. However, this PR would still have the benefit of not having to do a second "install" boot to get to a fully "fromram" system.

[dustymabe]

ok did a new push with the one requested deletion. I also rebased on top of latest testing-devel to get a full test run on top of the changes from #2543