grub_install: Add LOOP_NO_UDEV for builds in a container

[cgwalters]

A lot of the SDK instructions seem to assume you're in a "classic" Linux login
session. I use Fedora Atomic Workstation and do all of my development in "dev
containers" (currently docker, in the process of switching to podman).

In my setup the /dev setup is separate and won't pick up udev changes.
(Ideally I'd filter out a lot of host devices, that's another issue)

Anyone in a similar situation (which I assume would also include trying
to do the SDK build inside a Docker container on CoreOS) can do:
env LOOP_NO_UDEV=1 ./build_images.sh
to have it manually set up the partition mounts.

Loopback mounts with containers in general are ugly since they're not
namespaced.

A whole better solution to this IMO is to use something like
http://libguestfs.org/ which basically spawns a VM, although it doesn't support
grub2. So we'd really have to do instead something like what Fedora does with
using Anaconda. Or the "helper VM" could probably just be an existing CoreOS
qcow2.

[euank]

As you point out, the SDK instructions do assume use of a normal login shell on a reasonably modern Linux.

This specific change doesn't seem very intrusive, but I suspect there may be other places in the sdk+tooling that are also broken (e.g. running qemu tests with kola produces network namespaces and may mess up).

The bigger issue though is the question of whether we want to support the use-case of running the SDK in a container. Until now, the answer has been implicitly "no" because afaik no one asked or tried.

I think answering that question makes it easier to figure out whether it makes sense for us to take this or for you to carry it.

I personally think it makes sense to begin to support it. This is in no small part because there's been discussion in the past about moving our non-release build/testing workloads onto Kubernetes, which would certainly be easier if the sdk runs well in a container.

cc @dm0-, do you have an opinion either on this patch or on the broader question of whether we should start supporting use of the sdk in a container?

Anyone in a similar situation (which I assume would also include trying
to do the SDK build inside a Docker container on CoreOS)

As a bit of an aside, cork create and cork enter work outside of a container on CL just fine, which is how we run our automated builds now

[dm0-]

Some stylistic suggestions, but it looks okay to me. Also, the udev rules put the disk group on the device node if we want to be fully compatible, but I don't think anything in this use case would care about that difference.

[dm0-]

These scripts are already full of bashisms, so we might as well cut out unnecessary processes: LOOPNUM=${LOOP_DEV#/dev/loop}

[dm0-]

p=$(< ${d}/partition)

[dm0-]

dev=$(< ${d}/dev)

[dm0-]

For additional cleanliness, maybe have a shopt -s nullglob for this loop? That way if something crazy happens that breaks this pattern, the rest of the script still functions normally when it checks for a nonexistent device node. (This "library" script is only executed standalone rather than sourced, so a shopt shouldn't affect anything else.)

[dm0-]

@euank I am in favor of supporting SDKs in a container--specifically shipping the SDK chroot directory as a container more than running cork from inside some other container. We'd need to figure out how to handle the user mapping (or maybe just give up on it and always using core) and have optional volume mounts for passing in GCS creds, Git configuration, keyrings, agent sockets, and whatever else cork does. Having a signed non-persistent SDK would be nice for our CI where we only want to run it once and upload the produced artifacts, and I'm sure there are some users who would prefer to be able to use their existing container setup rather than run our cork binary that has no other use on their systems.