It is no longer necessary to include these as they are explicitly built
with --onlydeps in build_sysext_packages().
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
* 2 CPUs instead of 1 like QEMU.
* 2GB RAM instead of 1GB like QEMU.
* ICH9 chipset instead of PIIX3.
* virtio storage controller instead of IDE.
* VMware SVGA display adapter instead of VBoxVGA.
* USB tablet pointer instead of PS/2 mouse.
* UEFI instead of BIOS.
* UTC clock instead of local.
We don't enable any of the DRM drivers for any of VirtualBox's display
adapters, so it uses efifb regardless, but apparently VMSVGA is best for
Linux guests.
For UEFI, VirtualBox actually uses EDK2. It also supports Secure Boot,
but I haven't tested that.
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
We currently publish separate metadata for each provider, VirtualBox and
Parallels, but you're supposed to combine these and let Vagrant choose
the provider.
Rewriting an existing output file is a little weird, but this use of jq
makes it relatively safe.
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
The CoreOS support we have been carrying was merged upstream years ago.
The network configuration still needs special handling because our
cloud-init is called coreos-cloudinit, breaking the detection.
Flatcar's documentation used to point users at coreos-vagrant. This is
long dead and used the old Ignition VirtualBox support, which no longer
works. Rather than revive that, we can capture the essence of what
coreos-vagrant did in our base Vagrantfile.
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
common-oem-files was a giant hack. oem-release can now be easily be
generated from metadata embedded in the sysext image itself. grub.cfg is
often just a couple of lines, so there's no point in having all this
complex logic around generating it, especially when that logic has some
exceptions anyway. It's far easier to just explicitly store each variant
under build_library/oem. The list of OEMs is now generated by looking
for coreos-base/oem-*/*.ebuild.
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
It turns out we haven't even been building this for years because of a
CI bug. There's no point in reviving it now.
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
This allows the VirtualBox image to actually boot. It broke when
upstream Ignition changed how the VirtualBox support works.
VirtualBox supports arm64 these days, so we could enable this in the
common config, but we don't currently produce an arm64 VirtualBox image,
and I don't propose that we start now.
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
These extension-release.d fields are equivalent to their non-SYSEXT
os-release counterparts. SYSEXT_ID is taken from the sysext's name as
given to build_sysext. SYSEXT_NAME, SYSEXT_VERSION_ID, and
SYSEXT_HOME_URL are taken from the package if only one is given.
SYSEXT_NAME is the new name for the OEM_NAME variable.
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
Having a USE flag per OEM is unnecessary when we only really need to
know whether the package will be installed in an OEM sysext or not. A
single USE flag could do this, but our existing flatcar_target() helper
avoids the complexity of binpkg-multi-instance. The flag names were also
prone to conflicts (e.g. qemu) and we don't currently make use of them
anyway.
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
It is no longer necessary to build the meta packages from source as they
are now covered by build_packages.
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
Regenerate manifest of `sys-kernel/dracut` to fix build issues like
below that started happening since changes of the upstream repo name.
```
!!! Fetched file: dracut-109.tar.gz VERIFY FAILED!
!!! Reason: Filesize does not match recorded size
!!! Got: 556060
!!! Expected: 556054
```
Signed-off-by: Dongsu Park <dongsu@dpark.io>
This is to give ci-automation a chance to scavenge the logs that are
stored in the tmp directory.
Signed-off-by: Krzesimir Nowak <knowak@microsoft.com>
This searches for portage logs and configure logs after a build, and
uploads them to bincache. This is currently only done for SDK builds,
SDK container builds and package builds. This probably could be
extended to catch logs for sysext builds, but this was annoying to
implement, IIRC.
Signed-off-by: Krzesimir Nowak <knowak@microsoft.com>
This was introduced to see if it can help us pinpoint some weird
issues we used to have when suddenly we were not able to create a
directory or stuff like that. It was actually never useful, and is
always annoying to scroll through this output to see the actual error
that caused the build to fail.
Signed-off-by: Krzesimir Nowak <knowak@microsoft.com>
