/ and /usr have minimum sizes defined (1 GiB and 2 GiB respectively).
When /usr is not defined, the minimum size of /usr gets added to the
minimum size for /.
This new test runs through a few scenarios and checks whether the sizes
fit.
This tests that the clampFSSize() function ensures all user-defined
mountpoints are at least 1 GiB.
Added a blueprint with < 1 GiB minsizes to test this.
Testing all blueprints in TestCreatePartitionTable() now.
Currently, we only specify a minimum size for
- `/` (1 GiB), and
- `/usr` (2 GiB).
This ensures that
- a separate `/usr` partition is at least 2 GiB,
- `/` is always at least 1 GiB,
- if `/usr` it not a separate partition, `/` is at least 3 GiB.
We could (or should), in the future, make it possible for image types to
override this mapping as part of their default config, for example, if
an image type by default requires a larger `/usr`.
Makes the test values more readable (without needing comments).
Some values in the default partition table were fixed, e.g., cases where
we had `Size: 1024000, // 500 MB`.
When the partition table did not have a boot partition, we created it
but then _unconditionally_ returned, which meant that we did not create
the LVM skeleton and wrap the root partition. Properly handle this case
and also re-initialize the `rootPath` in this case since we change the
underlying `Partition[]` array in `PartitionTable` object. Add an extra
blueprint with only one customization which exposes this bug.
Co-Authored-By: Achilleas Koutsou <achilleas@koutsou.net>
New function that ensures that a partition can hold the total sum of all
the required sizes of specific directories on the partition. The
function sums the required directory sizes grouped by their mountpoint
and then resizes the entity path of that Mountable.
Use the Extended Bootloader Partition GUID for `/boot`, instead of the
Linux filesystem data GUID. This is useful for autodetection of a
partition purpose based on its GUID without reading the `/etc/fstab`
first.
Ensure that when creating mountpoints, e.g. when converting the
partitions layout to LVM, the `/boot` partition get the proper GUID
assigned.
Regenerate RHEL-90 and centos-9 image test cases.
Related to https://bugzilla.redhat.com/show_bug.cgi?id=2057231
This is only required in RHEL9.0, but best practice is to always pin these things
down. Also increases uniformity between distros.
Simplify a bit the volid generator by making it require `rand.Rand` rather than
`io.Reader`, and hence eliminating the need for error handling.
In LUKSContainer and LVMLogicalVolume we neglected to clone the Payload
which means we would modify the base PartitionTable when manipulating
the clone.
Whenever we create a new mountpoint due to a user customization,
ensure the layout uses LVM, i.e. convert plain layouts to it, if
needed. It uses the existing lvm-ification code but enhances it
so that we also create a `/boot` partition in case it does not
yet exist.
Adjust the existing tests that assumed we can not create more
than 4 partitions on mbr layouts, since that is now not true
anymore.
Re-introduce the VolumeContainer interface but with a different
meaning: it is supposed to be implemented by all container that
contain volumes and as a result have themselves a size, like eg
LVM2, LUKS2 and PartitionTable (the latter is not yet included).
The sole method on the interface for now is MetadataSize, which
should return the metadata for the container itself.
Use that new `VolumeContainer.MetadataSize` method when we up-
date the sizes of elements in `resizeEntitybranch`.
Add a new parameter `lvmify` to `NewPartitionTable` that, if set to
`true`, will cause the root partition to be wrapped in LVM in case
it is not in a LVM volume group. Set this to `false` for now so no
actual change should happen anywhere. Layouts where the root is
directly on a LUKS container are not yet supported.
Add tests for this.
Add support for building images for the Azure marketplace: add a
new image type "azure-rhui" that can be used to build images
tailored to the Azure marketplace.
Add two sample manifests for 8.5 and 8.6, but note that even the
8.5 is using the 8.6 distro definitions. Also no image-info is
included since `image-info` cannot (yet) handle LVM setups and
the azure marketplace images use the LVM setup.
When creating a new logical volume via the `CreateVolume` method,
the logical volume name was left blank. Generate an name based
on the mountpoint.
We will detect collisions for names and will try to correct them
by attaching a suffix. We do give up after 100 attempts though.
Add a simple test for it.
This commit fixes#2347 by ensuring that a minimum
size of 1GB is set for all file systems. The only
exception to this is the `/usr` which is set to 2GB,
since this was the only mountpoint that was previously
being checked.
Add a few test partition tables with well known configurations, like
LVM, LVM on top of LVM and Btrfs in addition to the plain layout that
is currently used in most partition tables. Add very basic checks,
such as that `NewPartitionTable` works and we have approximately the
correct size.
Co-Authored-By: Christian Kellner <christian@kellner.me>
Partition.Payload now supports every type of disk.Entity which enables
creating PartitionTables with LUKS, LVM, and Btrfs. \o/
Co-Authored-By: Achilleas Koutsou <achilleas@koutsou.net>
Implement `PartitionTable.ContainsMountpoint` via `entityPath` instead
of `FindFileSystemForMountpoint`; `entityPath` is the more generic
variant of `FindFileSystemForMountpoint` and will work with anything
that implements `Mountable`.
Co-Authored-By: Achilleas Koutsou <achilleas@koutsou.net>
This is for all entities that have a uniquely identifiable via a UUID.
Currently the interface only contains a single function, GenUUID(),
that should generate a new UUID via a random source (`rand.Rand`).
NB: Partitions are uniquely identifiable if and only if the layout is
GPT.
Co-Authored-By: Achilleas Koutsou <achilleas@koutsou.net>
Uses the new interfaces and supports all the different kinds of
filesystem configurations that we added.
Clones the base PartitionTable before modifying it.
Co-Authored-By: Christian Kellner <christian@kellner.me>
Eventually partition.Payload will be an Entity, so we need to use
more generic functions that work on the interfaces.
Co-Authored-By: Christian Kellner <christian@kellner.me>
Starts from an Entity (typically the PartitionTable) and searches for a
target (Mountpoint), returning a slice of all the entities that lead to
the Mountable with the given Mountpoint (in reverse order).
Co-Authored-By: Christian Kellner <christian@kellner.me>
Add a new enumerator method to `PartitioTable` that allows the
caller to visit all entities inside a partition table.
Co-Authored-By: Achilleas Koutsou <achilleas@koutsou.net>
All disk.Entitity types now implement Clone() which should return a
deep copy of the same object. Add the Clone() method to the entity
interface. The return type is Entity, but callers can assume it's
safe to convert back to the original type.
Co-Authored-By: Christian Kellner <christian@kellner.me>
