syslinux is still used, but only for the ISO with isohybrid and a
different configuration.
Xen now uses the newer pvgrub, which chainloads into GRUB 2.
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
We want to sign and verify kernel load scripts with GRUB, but it only
supports GPG signatures for plain text files.
To avoid needing to manage another key in Azure Key Vault for official
builds, the existing key has been converted, keeping the start and end
dates from the existing certificate.
For unofficial builds, it is awkward to convert plain PEM files into GPG
keys, but there is no need to use the same key in this case anyway, so a
new key has been created. Being publicly visible, it has no expiry date.
Two new scripts have been added to generate official and unofficial keys
and certificates. The README has been rewritten with details on how to
use these scripts and what each file is actually for.
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
We now need the official shim vendor certificate present in the SDK when
building the kernel so that it can be inserted and used to verify the
verity root hash and signed sysexts.
While we're at it, copy the official signing certificate from Azure Key
Vault so that we don't need to fetch it every time, simplifying the
signing code.
This change also partly deals with the eventual expiration of our shim
vendor certificate. We cannot simply replace the shim with one
containing just the new certificate because it needs to be able to boot
kernels from older releases. We therefore now keep all the certificates
in the coreos-sb-keys package as separate dated PEM files that then get
combined into a single DER ESL that the shim build expects. Note that
the shim does not check certificate expiry dates. It is therefore also
no longer necessary to manually convert the certificate to DER format.
The problem of actually upgrading the shim on user systems remains.
Each certificate in the DER ESL requires an owner GUID. We previous used
a zero GUID for the DB certificates, but these were only used for
testing. I have therefore now generated a static GUID for Flatcar that
we should use going forwards.
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
I thought cpio was always creating the output directory automatically,
but it was silently failing. It would only extract the next rootfs when
run a subsequent time.
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
The final part of the script differed only the name of the qemu binary
to execute and in network device driver (virtio-net-pci on amd64 vs
virtio-net-device on arm64). virtio-net-pci seems to be working also
on arm64, so simplify the code to avoid repetition.
There's no need to differentiate between amd64 and arm64 boards here
any more. This also adds bootindex=1 option to the -device flag, so we
can pass more secondary disks without affecting the boot order.
This version writes fewer temporary files and tries cpio multiple times
for concatenated archives again.
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
I couldn't take it anymore! The launcher script could not handle paths
outside the script's own directory, and it was driving me crazy. Now
only the default values are relative to the script's directory. Given
paths are relative to the current directory and absolute paths work as
you would expect.
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
On Linux >= 6.10, the first rootfs is an extra ghost rootfs of 336K,
that has a corrupted CPIO.
To overcome this issue, do not fail on `cpio --extract`.
Setting a profile in a newly created sysroot when building native
toolchains broke after an eselect update. Apparently eselect gets the
path to the coreos-overlay repository and then prefixes it with
ROOT. Since ROOT was set to /build/<arch>-usr, the resulting patch was
wrong. Fix this by telling eselect where to find our make.profile
symlink in new sysroot by setting PORTAGE_CONFIGROOT to
/build/<arch>-usr and where to find our profiles by setting ROOT (and
SYSROOT, because it must match ROOT) to /.
This change removes the legacy_boot flag from the EFI system partition.
We already have a BIOS boot partition which should offer compatibility with
legacy bios systems.
Signed-off-by: Gabriel Adrian Samfira <gsamfira@cloudbasesolutions.com>
Mentions of virtual/rust in some scripts were replaced with
dev-lang/rust-bin. These were usually about skipping the update/build
of the package, and these already contained dev-lang/rust, so added
the -bin variant for completeness.
docs: Add entrance to the changelog about the fix
Update changelog/changes/2025-01-15-qemu-startup-script-comma-fix.md
Co-authored-by: Mathieu Tortuyaux <mathieu.tortuyaux@gmail.com>
I know I recently deduplicated the code between extract_update and
generate_update recently, but now that generate_update will sometimes be
called at a later time, I've realised that it is compressing and
uploading the partition twice.
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
We would normally remove these for an official build so that the signed
versions can be uploaded later. However, we are not doing that signing
until we pass the shim review.
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
Apparently `local -x FOO` does not locally export an already existing
variable, but rather does some whole weird lot of nothing - it shadows
an existing variable with a new unset one, but it won't export it
until it gets assigned.
We previously did the AKV signing in the image job but temporarily
nobbled that code path while we completed the shim review.
Now the AKV signing has been split out into a separate job that will
only be invoked once changes to the jenkins-os repo have been merged.
The only thing we now need to nobble here is copying the signed shim. In
the meantime, we copy the unsigned shim instead. Revert this commit once
the shim review is complete.
We only want to do the signing in Azure, not the whole image job. This
new job downloads the unsigned image, signs it, and replaces it.
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
The --extract_update option used to do exactly that, just extract the
USR-A partition for updates and no more. Now it does the same thing as
--generate_update, except it names the file flatcar_test_update.gz
rather than flatcar_production_update.gz. --generate_update is never
actually used because official update payloads are manually generated
with the generate_payload script later on.
Resolve this confusion by deduplicating the common code between them.
Any update payload produced during this stage of the build is only
useful for testing, so change --generate_update to always create
flatcar_test_update.gz. --generate_update now implies --extract_update
and both are enabled by default.
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
