Since EAPI=7 was supported, portage can no longer use different
ROOT and SYSROOT values. This adjusts the paths so that the first
phase builds cross-toolchains under /usr/${CHOST}, then the native
toolchains are built under /build/${BOARD} (as was being done
previously). Now that the cross-toolchain development files can't
be used when building the native toolchain, the headers and libs
are stupidly copied into the board root to be used used and then
overwritten by the board packages as they are built. Since this is
all done in a chroot, these changes shouldn't affect the SDK host.
This will run on ESXi 6.0 and above, and all non-EOL versions of Fusion
and Workstation.
Also enable a few useful VMX features (HPET; CPU and memory hotplug) that
are added by VMware Workstation 14.1.1's Change Hardware Compatibility
wizard. Correspondingly, enable CPU/memory hotplug in the OVF; omit
HPET because there's no obvious way to enable it.
It's been deprecated since QEMU 0.12. Fixes warning on QEMU startup:
qemu-system-x86_64: -net nic,vlan=0,model=virtio: 'vlan' is deprecated. Please use 'netdev' instead.
This is the same story as the others: our images will fail the GLSA
checks as long as we build old Go versions. However, this one will
fail for any version less than 1.10.1 now.
Setting `$VM_CDROM` in the qemu script does not work as expected when
installing Container Linux from the given bootable CDROM image. That's
probably because qemu-system-x86_64 expects another boot option `-boot
order=d` to be able to boot from the given CDROM drive. Let's specify
specify a `-boot` as well as `-drive` option for the given CDROM drive.
This is the same case as the previous one. Our Go 1.8 package has
the fix, but none of the older unsupported versions do. Since we
have multiple installed versions and this says anything less than
Go 1.9 is vulnerable, we have to whitelist it until all older
versions of Go are removed from the OS.
It provides no value when it works, and it's randomly causing
failures to build toolchains due to permissions problems after
certain releases. This also requires taking it out of FEATURES in
the portage profile (which is the SDK profile by default).
Test Jenkins runs of SDK and toolchains jobs both ran in the same
time as with ccache enabled.
Normally toolchains packages are prevented from upgrading. This
drops that restriction and explicitly removes old versions so that
conflicting tool profiles are not accidentally used.
This reverts commit 20975049b3.
This reverts commit 7f058d61a1.
Reverting because of bug 2284 [1] where grub will sometimes fail due to
memory corruption. This is _not_ the cause of the bug, and the bug can
even be reproduced with this reversion, but it seems to occur less when
not using fat32.
[1] https://github.com/coreos/bugs/issues/2284
mkfs.vfat was defaulting to FAT16 based on the size of the partition.
The UEFI spec (2.7 errata A, section 13.3) implies that only FAT32 is
necessarily supported on the ESP, and we've received a report of
hardware that doesn't recognize FAT16.
We handle Go differently than Gentoo, so our 1.8.4 package includes
the same security fixes. When all packages are built with Go 1.9,
the older Go packages shouldn't be installed anymore, so this line
can be dropped.
This omits the toolchain packages' version-pinning flag for the
binutils package while it is being upgraded. It also removes older
versions installed in parallel that cause unwanted rebuilds.
When stable has the upgraded version, this can be reverted.
This includes the source package of all torcx packages that are
installed on disk, including cases where multiple versions of the
same package are available.
This moves the default symlinking logic into build image as well.
This assumes that a torcx store is available locally with all images
referenced in the torcx manifest.
This is accomplished with a highly-indented double-for-loop, but I think
it's still decently readable.
Torcx is special in that it wishes to be uploaded under a prefixed
directory (torcx), typically wishes to be downloaded from there, but
ultimately wants to be downloaded from a location without that prefix.
In fact, I expect during a normal release process, it will be uploaded
with that prefix to the build bucket, copied without that prefix to the
final bucket (during pre-release), and then finally downloaded without
the prefix.
I think this set of variables ends up being the cleanest way to
represent this complexity.
This just sets the code file size to the var file size, so it gets
zero-padding without having to pipe commands together.
From: David Michael <david.michael@coreos.com>
[Rebased]
Signed-off-by: Geoff Levand <geoff@infradead.org>
This reverts the vagrant image back to using oem-vagrant because we
don't want to break the existing images. It moves the new,
Ignition-powered virtualbox flavor of vagrant into a new image.
This changes the oem-package for vagrant to vagrant-virtualbox,
which uses ignition instead of cloud-clonfig and sets the oem id
to "virtualbox" so that ignition can handle the machine correctly
This adds the option --torcx_store to specify the path to a
directory containing torcx images to be baked into the OS image. A
blank string can be given instead of a path to restore the previous
behavior and leave an empty vendor store.
The default value is the default path created by build_torcx_store,
which is used when build_packages updates torcx images. This means
that the current pattern "./build_packages && ./build_image prod"
should result in a fully updated OS image with all torcx images
available in the vendor store.
When OVA template is not being used, the default dhcp value yes will
trigger cloud-init to generate a 00-.network file, which will break
network connectivity Intermittently. Please see the details here:
https://github.com/coreos/bugs/issues/1802#issuecomment-297847614
When building dev images, the PORTAGE_BINHOST value during build
time is written to the image's make.conf. This breaks the default
binary package setup, since Jenkins is using gs:// URLs for signed
package verification and authenticated downloads, and the make.conf
doesn't inherit the GS_* variables to handle those schemes.
This should be reverted when signed packages are properly supported
by default in the dev images.
This changes the format from:
sys-apps/systemd-212-r8::coreos GPL-2 LGPL-2.1 MIT public-domain
to a JSON structure:
[
{
"project": "sys-apps/systemd-212-r8::coreos",
"license": ["GPL-2", "LGPL-2.1", "MIT", "public-domain"]
}
]
We don't have to worry about the changing format because the previous
format was never published. This is designed to match the
bill-of-materials [1] format so that it can be consumed by the site.
[1]: https://github.com/coreos/license-bill-of-materials
INFO build_oem_aci: Writing coreos_oem_gce_aci_stage_packages.txt
awk: cmd. line:1: fatal: cannot open file `/build/amd64-usr/var/db/pkg//DEPEND' for reading (No such file or directory)
INFO build_oem_aci: Writing coreos_oem_gce_aci_stage_licenses.txt
awk: cmd. line:1: fatal: cannot open file `/build/amd64-usr/var/db/pkg//DEPEND' for reading (No such file or directory)
We've always generated these license manifests (detailing which ebuilds
are covered by which license), but never published them. This adds these
manifests to the list of published files so that they are publicly
available.
os-release is requested in bug reports, and knowing which board
the problem occurred on is often helpful.
Signed-off-by: Geoff Levand <geoff@infradead.org>
Detect first boot based on the existence of a coreos/first_boot file
in the EFI partition, and set "coreos.first_boot=detected" command line
argument when found. We use "detected" rather than "1" so the initramfs
knows that it should mount the ESP and delete the file. This lets us
defer clearing the first-boot flag until Ignition has run successfully,
without having to change the disk GUID after filesystems are mounted.
Continue detecting the first-boot disk GUID and adding the command-line
argument to randomize it, since we still want unique disk GUIDs
regardless of Ignition.
This is useful for emerges that are meant for incomplete rootfs's, such
as ACI building emerges. There are cases where the #! check is expected
to fail while doing those.
This reverts commit a7ffba9a9f.
The build_image script can build multiple formats. When our
releases and automated builds are creating developer containers and
production images from the same command, the verity flag would be
disabled while building the container and remain disabled when building
the production image. This resulted in no verity in all our builds.
Allow "coreos-install -o vmware_raw" to install Container Linux with
the vmware OEM.
Use base DISK_LAYOUT to reduce the minimum disk size.
Fixescoreos/bugs#359.
They're not in the root fs, but they are in the initramfs. Handle this
by augmenting the package list with packages that are both
- build dependencies of coreos-kernel, and
- configured to cause rebuilds of coreos-kernel when their sub-slot
changes.
To clean things up and prepare for arrm64 support move
all the enable_rootfs_verification processing into one
location and add some comments.
Signed-off-by: Geoff Levand <geoff@infradead.org>
To make verity work both enable_rootfs_verification and enable_verity
need to be set. Without one verity just gets half enabled. Remove
the enable_verity flag and do the full verity setup when
enable_rootfs_verification is set.
Signed-off-by: Geoff Levand <geoff@infradead.org>
The disable_read_write variable was just a copy of FLAGS_enable_rootfs_verification,
so to make things less confusing just use FLAGS_enable_rootfs_verification.
Signed-off-by: Geoff Levand <geoff@infradead.org>
Add a new grub variable extra_options, the contents of which is
added to the linux command line. Use extra_options to set
the ACPI options needed for arm64.
Signed-off-by: Geoff Levand <geoff@infradead.org>
Two new image types have been added:
1. parallels - this produces VM images with extension pvm.tgz that can be loaded directly into Parallels Desktop
2. vagrant_parallels - this produces a Vagrant box that works with parallels vagrant provider (http://parallels.github.io/vagrant-parallels/)
Just like vmdk and others we rely on qemu-img to convert raw images. Support for Parallels disk images was added to qemu-img in version 2.4.
I also removed the box files from the actual image since there are not needed in /usr/share/oem.
Signed-off-by: Bassam Tabbara <bassam.tabbara@quantum.com>
The ACI root is created by reusing the create_prod_image function
to install a base meta-package. It then runs a script to customize
the file structure as required by agent software (if necessary),
writes a manifest file from a supplied template, and then packages
it all into a tar file.
The Xen loader in GRUB never received support for our hacky scheme of
adding the verity hash to the kernel cmdline. Disable till that's fixed.
Partially reverts 2016567 and 533b1b9.
Consolidates two very similar flags into one and fix an issue where
verity could get enabled in the GRUB config when rootfs verification was
turned off (e.g. on arm64 which cannot use verity yet).
workaround for bootstrap_sdk on an Ubuntu host where /dev/shm is a
symlink to /run/shm. Since we mount the hosts /dev (for losetup) this
interferes with building python 2.7. The workaround is to disable the
/dev/shm during python builds. A longer term fix would be to not mount
the hosts /dev. Thanks for marineam for suggesting the fix on IRC.
If the gptprio.next command fails to give us something to boot we
shouldn't try! In order to diagnose why the failure happened halt
immediately so the user can see the error message.
Once we've built the packages, verify against the Gentoo Linux Security
Advisories to ensure that we're not shipping anything with known
vulnerabilities.
Instead of patching portage to support the `disabled` flag now we just
patch it to leave the `[gentoo]` section out of the default repos.conf.
Follow up to 585275b268
PROD_IMAGE is a flag that indicates a production image should be
built, and will be set for dev builds if the user specifies that
both dev and prod images should be built. build_image was
incorrectly using the PROD_IMAGE variable to conditionaly do some
setup depending on the image type.
Add a new variable IMAGE_BUILD_TYPE that can be tested for the type
of image currently being built and replace the PROD_IMAGE usage.
Signed-off-by: Geoff Levand <geoff@infradead.org>
A bunch of packages install PAM configuration fragments in /etc. Rather than
modify them all to install into /usr/lib, just move the entire directory at
image build time.
We need to ship some PCR measurements alongside images in order to make it
easier for admins to provide an appropriate policy. Add some tooling to
generate the appropriate hashes during build, pack those into a zip file
and upload it.
profile is already set up to source /usr/share/baselayout/profile.env
but it never has because I forgot to add this line during the migration
to amd64-usr images. Sure took us a while to notice that one... :(
This resolves two issues:
- Large dependencies are *never* built during image_to_vm,
build_packages must now handle that.
- Since build_packages can't resonably do the oem-* packages (they all
conflict with eachother) we do want to build them from the ebuild.
This is now enforced so a old binpkg is never used. This resolves
confusing issues people have always had while when editing oem
ebuilds but getting a stale build instead.
Allows build_image to be used without first running build_packages.
Note: setup_board --force is required before build_packages will work
properly after doing this since baselayout won't be installed otherwise.
- May be sourced early, so explicitly die if source fails.
- Add a function for getting the latest version of a package.
- Read PROVIDES metadata using portageq, enabling data to be read from
binary packages in addition to installed packages. The performance
issue is not an issue here and needed to support empty build roots.
Most vm images have an expanded root partiton to make them practical to
use as-is. Some deployments may not want such a large root, putting most
storage on other volumes.
This variable was semi-deprecated ages ago so `version.txt` could follow
a similar variable naming pattern to `os-release`. Finally drop usage of
it here in favor of `$COREOS_VERSION`.
The one-liner `[[ -z ${PIPESTATUS[*]#0} ]]` no longer works because the
expansion still includes spaces even if all the values are zero. Somehow
that didn't matter in bash 4.2 but it does mater in 4.3 to be consistent
with the general behavior of variables in [[ tests.
The console often contains very useful information in the event of a
hard crash, in such situations there's no ability to unblank the console
via keypress because the kernel won't handle the interrupt.
Since CoreOS is a server/cluster operating system, there won't generally
be monitors connected benefitting from a blanked console. Disabling the
blanking altogether allows the frame buffer contents to always be
visible, even when the kernel can't handle keypresses.
