qemu-secex: improve localbuild #3927
Conversation
nikita-dubrovskii
force-pushed
the
genprotimg_vm
branch
2 times, most recently
from
086ce1e to
4b2ae8e
Compare
nikita-dubrovskii
changed the title
nikita-dubrovskii
force-pushed
the
genprotimg_vm
branch
4 times, most recently
from
6ffe317 to
d2d497a
Compare
nikita-dubrovskii
changed the title
nikita-dubrovskii
force-pushed
the
genprotimg_vm
branch
from
f349993 to
6150a01
Compare
|
hey @nikita-dubrovskii - if possible can we hold this until #3930 merges? There are a bunch of changes in there, including moving code in buildextend-metal around quite a bit and I'd prefer not to have to do merges conflict resolution for all of those commits. |
No worries, this can wait. Mind a review? |
The other PR merged now. You'll need to put this logic inside |
nikita-dubrovskii
force-pushed
the
genprotimg_vm
branch
4 times, most recently
from
d389014 to
4827d87
Compare
I'm trying to figure out why it was trying to mount on first boot with the units that existed before this change.. Does |
It doesn't. As i got from docs - generator with condition(s) should be used. |
nikita-dubrovskii
force-pushed
the
genprotimg_vm
branch
2 times, most recently
from
e2b527b to
c3fe4cb
Compare
ssh access to the VM is not required, was here just for debug purposes.
Cannot recall the reason why script was under '/etc', so removing this weird path.
We use CoreOS as base system for the FakeSecureVM, unfortunately it's not possible to generate 'sdboot' image during `firstboot`, because ignition checks for unique `boot` labeled fs, but added as a disk qemu-secex.qcow2 image has its onw 'boot' partition.
This fixes an issue when during firstboot system tried to mount genprotimg partition.
Automatically generates genprotimgvm during build, when official one is not available and/or there is no so-called "IBM Universal Hostkey". Main goal is to support local/custom build of qemu-secex target. Assuming there is a valid hostkey (/srv/secex-hostkey), it'd possible to generate coreos.qemu-secex.qcow2 just by running: ``` cosa cmd-buildextend-secex ``` If later there is a need to build some other variant, previously generated genprotimgvm could be used again: ``` cosa buildextend-secex --force --genprotimgvm path/to/fake-secure-vm.qcow2 ```
nikita-dubrovskii
force-pushed
the
genprotimg_vm
branch
from
c3fe4cb to
4cdb9b6
Compare
| Type=ext4 | ||
| Options=rw,noatime | ||
| EOF | ||
| ln -sf "../var-build.mount" "${UNIT_DIR}/default.target.wants/" | ||
| systemd: | ||
| units: | ||
| - name: [email protected] |
There was a problem hiding this comment.
feel free to delete this if you want.. in my earlier code review comment I was just saying that if we do delete it lets put it in a separate commit with a reason even if that reason is "make it more like the ubuntu VM that is used to generate secex artifacts".
| Type=ext4 | ||
| Options=rw,noatime | ||
| EOF | ||
| ln -sf "../var-build.mount" "${UNIT_DIR}/default.target.wants/" |
There was a problem hiding this comment.
Optional/wondering:
I'm guessing it wouldn't work to put this unit also in the systemd section of the butane along with genprotimg.service, but with both of them enabled false and then here we just
| ln -sf "../var-build.mount" "${UNIT_DIR}/default.target.wants/" | |
| ln -sf "../var-build.mount" "${UNIT_DIR}/default.target.wants/" | |
| ln -sf "../genprotimg.service "${UNIT_DIR}/default.target.wants/" |
and thats pretty much all the generator does.
Automatically generates
genprotimgvmduring build, when official one is not available and/or there isno so-called "IBM Universal Hostkey". Main goal is to support local/custom build of
qemu-secextarget.Assuming there is a valid hostkey, now it's possible to generate
coreos.qemu-secex.qcow2just by running:If later there is a need to build some other variant, user can use previously generated
genprotimgvm: