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>
The `PartitionTable.FindMountable` method is the more generic version of
`PartitionTable.RootFilesystem` which returns a `Mountable` interface,
instead of a specific `Filesystem` object. This commit thus prepares for
the more generic case, like when root is a Btrfs sub-volume.
Co-Authored-By: Christian Kellner <christian@kellner.me>
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>
Replace the old CreateParittionTable() function with the new one called
NewPartitionTable() which works with the new interface types and
supports container-type setups (LUKS, LVM ,and Btrfs).
Changed usage in distro packages to take and carry around a pointer to
the new PartitionTable rather than a concrete type. The
NewPartitionTable() function returns a deep clone of the base
PartitionTable so the new pointer type can be moved and (if necessary)
modified freely without affecting the distro base PT.
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>
Use single NewGrub2StageOptions() and NewGrub2InstStageOptions()
functions from osbuild2 instead of implementing them in distros.
A small option flip is required outside the function for RHEL 8.5 and
RHEL 8.6 to maintain the old behaviour.
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 method to create all necessary stages to create the
devices for a given `PartitionTable`.
Co-Authored-By: Achilleas Koutsou <achilleas@koutsou.net>
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>
This is needed so we can have LVM be contained inside a LUKS
container, which is inside a partition; i.e. multiple devices
are needed to get to the target device.
Co-Authored-By: Achilleas Koutsou <achilleas@koutsou.net>
Use entity based method `ForEachMountable` and `getDevices` to generate
all mounts and devices in a generic way, which then allows for mounts on
arbitrarily nested devices.
Update manifests and image info:
- New device names generated by `pathdot()` to avoid basename
collisions.
- Some partitions are generated in a different order now which changes
the order they appear in the manifest and their UUIDs.
Co-Authored-By: Christian Kellner <christian@kellner.me>
Refactor GenMkfsStages to work with entity based methods so that it is
now able to handle all generic cases of arbitrarily nested devices.
Co-Authored-By: Christian Kellner <christian@kellner.me>
NewLVM2LVDevice should take `LVM2LVDeviceOptions`. Also add a parent
argument to be able to specify the parent device for the LVM2 device.
Co-Authored-By: Christian Kellner <christian@kellner.me>
osbuild, starting with version 31, supports for nesting of devices,
i.e. any device can have a parent device. See osbuild commit 45d0594
Co-Authored-By: Christian Kellner <christian@kellner.me>
Use a single GenCopyFSTreeOptions() function from osbuild2 instead of
implementing it multiple times in distros.
Co-Authored-By: Christian Kellner <christian@kellner.me>
Use a single GenMkfsStages() function from osbuild2 instead of
implementing it multiple times in distros.
Co-Authored-By: Christian Kellner <christian@kellner.me>
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>
Structs to represent a Btrfs file system with subvolumes.
Btrfs implements the following interfaces:
- Entity
- Container
- VolumeContainer
BtrfsSubvolume implements the following interfaces:
- Entity
- Sizeable
- Mountable
Co-Authored-By: Christian Kellner <christian@kellner.me>
Types to represent LVM2 setups with logical volumes being contained
in volume groups.
LVMVolumeGroup implements the following disk interfaces:
- Entity
- Container
- VolumeContainer
LVMLogicalVolume implements the following disk interfaces:
- Entity
- Container
- Sizeable
Co-Authored-By: Christian Kellner <christian@kellner.me>
Representation for the encrypted storage container of the same name.
Implements the following disk interfaces:
- Entity
- Container
Co-Authored-By: Christian Kellner <christian@kellner.me>
In our model a partition table has a size to represent the disk size.
Also each individual partition has a size, so they both implement the
Sizeable interface.
Co-Authored-By: Achilleas Koutsou <achilleas@koutsou.net>
A `PartitionTable` is a container for one or more instances of
`Partition`, which itself might contain a `Filesystem`.
Co-Authored-By: Christian Kellner <christian@kellner.me>
Implement the base type of the new entity system, i.e. `Entity`,
for all relevant components:
- PartitionTable
- Partition
- Filesystem
Co-Authored-By: Achilleas Koutsou <achilleas@koutsou.net>
Add a generic entity data model that can be used to navigate and operate
on any specific disk image layout. Since the latter allows for arbitrary
nesting of different container types, such as LUKS2, LVM2, and with file
systems that can have sub-volumes, the entity model is very generic.
Co-Authored-By: Achilleas Koutsou <achilleas@koutsou.net>
Split up disk.go into smaller more manageable pieces: finish
by moving `Partition` to its own file.
Co-Authored-By: Christian Kellner <christian@kellner.me>
Split up disk.go into smaller more managable pieces: continue
with moving `Filesystem` to its own file.
Co-Authored-By: Christian Kellner <christian@kellner.me>
Split up disk.go into smaller more managable pieces: start with
extracting `PartitionTable` and all its methods to a new file.
Co-Authored-By: Christian Kellner <christian@kellner.me>
Use bytes internally everywhere and convert to sectors only when writing
the options for the stages.
Changed the AlignUp() method to not do the alignment if the input is
already aligned. This changes the behaviour when the size is 0, but
that's not a realistic use case. Updated unit tests to match.
Manifests are unaffected.
Co-Authored-By: Christian Kellner <christian@kellner.me>
Instead of just reserving a fixed amount of sectors for the
partition header and footer, calculate the size of the
header and footer dynamically when the layout is GPT.
Return an error if the maximum numbers of partitions has been
reached and thus creating further partitions would result in
errors.
Currently we limit MBR partition types to 4 as we dont support
logical partitions and GPT layouts to 128. According to the
UEFI specificatio (2.8) a minimum of 16384 bytes are reserved
for the partition entries array. Each entry is 128 bytes wide
thus resulting in at least 128 entries; we choose this to be
the maximum as well for now.
This is needed so that we can do different things depending on the
given layout; this will be used in tests for now only. Only GPT
allows for arbitrary number of partitions and once we assert this
in code we will need to adjust the tests accordingly.
NB: This method might be removed again in the future, once generic
LVM support is added everywhere and the ability to differentiate
between MBR and GPT layouts is not needed anymore.
Do not rely on `distro.imageOptions` having any size information,
i.e. `Size` being `0`. Instead use `imageType.Size()` and the
information in the blueprint customization to calculate the size.
This makes the individual distro definitions idenpendent of the
API entry points that currently calculate the size, e.g.:
internal/cloudapi/v1/v1.go:PostCompose line 184
internal/cloudapi/v2/v2.go:PostCompose line 197
internal/kojiapi/server.go:PostCompose line 135
internal/weldr/api.go:composeHandler line 2289
Align partitions during their re-layout. Specifically, we align the
first partition which removes the need for the hard coded magic
number of 2048, which represents the proper alignment for a grain
size of 1MB given a sector size of 512 (our setup).
NB: Since all our partitions should sizes that are themselves
aligned, i.e. evenly dividable by the default grain (1MB) this
will not actually change any manifest.
Add a utility method that can be used to align data to the next "grain"
which is currently defined as 1 MiB -- the default used by sfdisk.
Add corresponding tests.
