Also remove CVE-2024-41946.patch as it no longer applies as ruby 3.3.5 containers rubygem-rexml 3.3.6, where CVE-2024-41946 is already fixed
Signed-off-by: Saul Paredes <saulparedes@microsoft.com>
The change #10804 (Toolkit: Add missing flock calls) seems to have caused a problem where on Ubuntu 22.04 build hosts, the partition info isn't populated quickly enough after partition creation and formatting. So, the `lsblk` call might return missing information. Adding a `partprobe` call before the `lsblk` call seems to fix the problem.
Since we pull secure boot patches from Fedora's grub2, we should include their SBAT entries into our Azure Linux grub2 SBAT.
Signed-off-by: Chris Co <chrco@microsoft.com>
The change #10804 (Toolkit: Add missing flock calls) seems to have caused a problem where on Ubuntu 22.04 build hosts, the partition info isn't populated quickly enough after partition creation and formatting. So, the `lsblk` call might return missing information. Adding a `partprobe` call before the `lsblk` call seems to fix the problem.
Currently, the size of outputted VHDX files can be substantially larger than VHD or qcow2 files. This behavior occurs because `qemu-img` dynamically sets the block-size based on the size of the disk. And larger blocks sizes means the file format is less space efficient, which results in a larger image file.
This change sets the block-size to 2 MiB for VHDX files. This matches the `qemu-img` defaults for VHD and QCOW2.
For reference, Windows seems to use a default block-size of 1 MiB for VHDX files.
In change #10789, the `imagecustomizerapi.FileSystem` type had an internal field added called `PartitionId` which is filled in by the API validity checks.
ISO to ISO customization supports cracking open the squashfs file and modifying the Live-OS. However, to do this, a temporary OS image must be created. This creation logic uses the `imagecustomizerapi.FileSystem` type but the code wasn't updated to ensure the `PartitionId` field has a value.
Change the verity config from a single item to a list of items. This is being done so that it is easier to add support for other verity partitions (e.g. /usr) in the future. However, this change restricts the verity API to only the root partition (`/`).
In addition, move the verity config from `.os` to `.storage`. This is being done for alignment with the Trident API. But is also probably a more morally correct place for verity to be placed.
As a side effect, this change removes support for enabling verity on a base image that somehow had all the correct partitions to support verity but didn't actually have verity enabled. None of our base images are like this. So, it is expected that no user ever made use of this functionality. This functionality could be re-added in the future. It was omitted from this change to avoid adding additional complexity.
After creating a partition, the toolkit must wait for the partition device to be created (under /dev). However, the naming scheme of partitions is inconsistent, with both `/dev/<name>XX` and `/dev/<name>pXX` being used, depending on the device driver. So, the toolkit checks for both.
However, a problem occurs when the device name itself ends in a digit. If the disk device path is say `/dev/loop1`, then `/dev/loop11` is also a valid disk device path. For such disks, the `/dev/<name>pXX` form must be used for partitions.
While the toolkit prioritizes `/dev/loop1p1` over `/dev/loop11`, if the `/dev/loop1p1` device doesn't exist yet and `/dev/loop11` is in use, then the toolkit may pick the wrong device path for the partition.
This change fixes this by ignoring the `/dev/<name>XX` variant if the disk device path ends in a digit.
When making changes to partitions or filesystems, it is recommended to take a file lock over the disk block device as this informs the host OS that you are making changes and that it should avoid scanning or changing the device until you are done. While most of the relevant operations are covered, there a few places that are missing the lock. For example, when calling `mkfs` or `resize2fs`.