Add support for osmet packing #1244
Conversation
jlebon
changed the title
|
I have a follow-up to this which is to tweak Another big followup to this I started on is running |
|
Is it safe to say we're waiting for this |
|
Yup, exactly! (BTW, I actually hadn't realized you could link to a specific file in the logs, that's neat!) |
src/osmet-pack
Outdated
| set -- "$@" "${TMPDIR}/coreos-installer" | ||
| fi | ||
|
|
||
| runvm -drive "if=virtio,id=coreos,format=raw,readonly=on,file=${img_src}" -- \ |
There was a problem hiding this comment.
I was thinking about this runvm stuff recently and I realized that we could actually switch to a two-phased system where we first build qemu/metal image, and then all runvm tasks after that simply boot that image with an Ignition config - making us much more self-hosting.
(The downside of this is that for RHCOS we can't use 9p but that problem will really, hopefully soon be solved with virtiofs).
There was a problem hiding this comment.
To elaborate on this, we wouldn't have a runvm API internally distinct from buildextend-qemu.
There was a problem hiding this comment.
Would be interesting. One thing we lose though is that supermin automatically imports all the packages from the build environment. Obviously we could do something similar with Ignition/a systemd service fetching the files we want, but it's nice that it works transparently with supermin.
It would be a good fit for osmet though since we normally want to use the coreos-installer from the FCOS node in that case. So in the developer case, we only have to upload the custom coreos-installer really.
A lot of our code wants things like `/dev/disk/by-X`. Extracted from coreos#1244
A lot of our code wants things like `/dev/disk/by-X`. Extracted from #1244
For coreos#1244, I want to use `serial=osmet` on the disk to mark which one is the source disk containing the metal image instead of relying on `index=N`. However, to use `serial=osmet`, I have to use a separate `-device` arg instead of the implied one from `if=virtio`, and it seems like doing that causes qemu to give those disks higher priority such that e.g. it gets `/dev/vda`, which throws off supermin. Let's switch over all our disks to use `-drive ... -device ...`. While we're here, only rely on `index=N` for the supermin root itself, since we can't use udev symlinks in the kernel cmdline. The cache disk too doesn't need an index, we use the LABEL instead already.
|
OK, this now requires #1398! |
jlebon
force-pushed
the
pr/osmet
branch
2 times, most recently
from
4d5caf5 to
35a62a3
Compare
|
OK, as mentioned in coreos/coreos-installer#187 (comment), we now have a The second commit adds a new testiso scenario: So once this is in, I'll update coreos/coreos-installer#187 to use |
For coreos#1244, I want to use `serial=osmet` on the disk to mark which one is the source disk containing the metal image instead of relying on `index=N`. However, to use `serial=osmet`, I have to use a separate `-device` arg instead of the implied one from `if=virtio`, and it seems like doing that causes qemu to give those disks higher priority such that e.g. it gets `/dev/vda`, which throws off supermin. Let's switch over all our disks to use `-drive ... -device ...`. While we're here, only rely on `index=N` for the supermin root itself, since we can't use udev symlinks in the kernel cmdline. The cache disk too doesn't need an index, we use the LABEL instead already.
For #1244, I want to use `serial=osmet` on the disk to mark which one is the source disk containing the metal image instead of relying on `index=N`. However, to use `serial=osmet`, I have to use a separate `-device` arg instead of the implied one from `if=virtio`, and it seems like doing that causes qemu to give those disks higher priority such that e.g. it gets `/dev/vda`, which throws off supermin. Let's switch over all our disks to use `-drive ... -device ...`. While we're here, only rely on `index=N` for the supermin root itself, since we can't use udev symlinks in the kernel cmdline. The cache disk too doesn't need an index, we use the LABEL instead already.
This is the server side required for osmet packing: coreos/coreos-installer#187 We run `osmet pack` when creating the live ISO and include the osmet binary as part of the CPIO containing the root squashfs. One thing to note is that the metal image is now always required before building the live ISO. This is because the whole point of osmet is to efficiently pack the metal image. Since osmet obsoletes the `fulliso` artifact, this PR also removes support for it.
Add a new `iso-offline-install` scenario which tests the osmet path. In this path, we completely turn off networking to the host (`-nic none`). We pass `--offline` to force coreos-installer to use the osmet path. In the future, we should be able to omit this entirely, which will test that coreos-installer correctly defaults to osmet when not provided another image source. As mentioned in the comment, this might become the default behaviour of `iso-install` in the future once osmet is fully baked in.
|
OK, this is ready to go now! Tested succesfully with coreos/coreos-installer#187: |
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: cgwalters, jlebon The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
This is the server side required for osmet packing:
coreos/coreos-installer#187
We run
osmet packwhen creating the live ISO and include the osmetbinary as part of the CPIO containing the root squashfs.
One thing to note is that the metal image is now always required before
building the live ISO. This is because the whole point of osmet is to
efficiently pack the metal image.
Since osmet obsoletes the
fullisoartifact, this PR also removessupport for it.