This testcase tested for a / size of 1 GiB but better is to test for a
minimal size of 4 GiB which is the actual lower limit when the required
sizes are added together.
These RequiredSizes are a map that is passed on to the partition table
logic which had hardcoded defaults. This makes it possible to define
either no RequiredSizes (`nil`) or empty RequiredSizes which means no
further constraint checks or partition resizes will be done.
Move the `CheckMountpoints()` implementation to `blueprint` package,
since it does not operate on any data structures from the `disk`.
Move the default mountpoint allow list policy definition to the
`pathpolicy` package.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
The `PathPolicies` implements a generic concept that can be fit on more
use cases than just mountpoints. Another one would be a policy for
creating custom files and directories in the image. Having the
implementation in the `disk` package and using data structures from the
`disk` and `blueprint` packages makes it impossible to use it for any
additional BP customization due to a circular dependencies that always
occurs.
Split out the implementation into a separate package `pathpolicy` as the
first step.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
After introducing Go 1.18 to a project, it's required by law to convert at
least one method to a generic one.
Everyone hates IntToPtr, StringToPtr, BoolToPtr and Uint64ToPtr, so let's
convert them to the ultimate generic ToPtr one.
Signed-off-by: Ondřej Budai <ondrej@budai.cz>
When the size of a logical volume is not aligned to the extent size of
the volume group, LVM2 will automatically align it by rounding up[1]:
Rounding up size to full physical extent 29.80 GiB
Rounding up size to full physical extent <3.82 GiB
Since we don't take that into account when we create a new volume or
set the size of an existing one, the size for the whole volume group
will be short by that amount and thus the creation of the last volume
will fail:
Volume group <uuid> has insufficient free space (975 extents): 977 required.
To fix this a new `AlignUp` method is added to the `MountpointCreator`
creator interface. It will align a given size to the requirements of
the implementing container, like e.g. `LVMVolumeGroup`. It is then
used by a new `alignEntityBranch` which takes a size and walks the
entity path, calling `AlignUp` for all entities that implement said
`MountpointCreator` interface; thus the resulting size should fullfil
the alignment requirement for all elements in the path.
NB: `PartitionTable` already had an `AlignUp` method.
Add a corresponding test.
[1]: 8686657664/lib/metadata/metadata.c (L1072)
Co-authored-by: Achilleas Koutsou <achilleas@koutsou.net>
Extract a `CreateLogicalVolume` method from `CreateMountpoint`
and implement the latter via the former. This makes it possible
to create a Logical Volume for an existing payload.
The `LVMVolumeGroup.Clone()` method could end up dereferencing a `nil`
pointer in the `lv` variable, if there would be a `nil` logical volume
in the LVM volume group. Such situation would be an error of its own.
There is no point in checking if the cloned logical volume is not `nil`
and casting it to another variable. The logic should check if the cloned
logical volume is `nil` and panic in such situation. The following code
can then cast the clone to a different variable without issues and there
is no risk of dereferencing a `nil` pointer.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
The `PartitionTable.Clone()` method could end up dereferencing a `nil`
pointer in the `part` variable, if there would be a `nil` partition in
the partition table. Such situation would be an error of its own.
There is no point in checking if the cloned partition is not `nil` and
casting it to another variable. The logic should check if the cloned
partition is `nil` and panic in such situation. The following code can
then cast the clone to a different variable without issues and there is
no risk of dereferencing a `nil` pointer.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
Extract the application into a utility method on `PartitionTable`.
In order for it to be usable for the first and second pass it does
take a `create` argument that controlls whether new partitons will
be created or return.
Since the LVM support was added to all distros, our disk
related code is adaptive, i.e. we will set the correct BLS
and grub2 prefix if there a `boot` partiton is present in
the layout after all customizations happen, which includes
LVMification.
One thing that was not yet fully working was layouts that
do not yet have a `/boot` partition but allow LVMification.
In that case `NewPartitionTable` and if `/boot` was the
first (or only) customization, would LVMify the partition
which in turn would create the `/boot` partition; but after
`newPT.ensureLVM()` the call to `newPT.createFilesystem`
with `/boot` would try to create another `/boot` mountpoint.
In order to deal with this situation correctly we are now
using a two phase approach: 1) enlarge existing mountpoints
and collect new ones. 2) if there are new ones and LMVify
was allowed, switch to LVM layout. Do a second pass and now
create or enlarge existing partitions, handling `/boot` in
the process.
Replace the simple allow list of paths with the more sophisticated
path policies. It enables us to e.g. allow one path but not any
sub-path. This will be useful for `/boot` where we want to allow
its customization but not any sub-path because that might actually
break booting.
Build a new path policy struct, ased on the new path trie struct.
It is designed to be able to store policies for paths. A Check
method can then be used to look up the policy for a given path
based on the defined policies.
Add a simple implementation of a path trie structure that can be
used to look up assoicated data for any given path. The constructor
will build the trie from a dict of paths to associated data. Later
modification is currently not support. Add tests for it creation
and lookup.
/ 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>
