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>
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.
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.
Instead of hard coding a padding of 100 sectors for all layouts, i.e.
MBR and GTP, adjust the needed space depending on the layout: for MBR
we don't need to reserve any space at all since it does not have a
secondary header. For GTP we reserve 33 sectors, as indicated in the
UEFI specific, which allows for the header itself and up to 128 entries.
To not modify the layout of already released distributions, like RHEL
8.4 and 8.5, a new member called `ExtraPadding` is added to `Partition
Table` and then used in the corresponding layouts to preserve the
existing padding of 100.
The method assert.GreaterOrEqual(t, a, b) asserts that a >= b,
but the arguments were (expected, actual), which is the wrong
way around since we want to assure that the actual size is at
least the expected size, i.e. actual >= expected and thus the
argument should be (actual, expected).
The partition table size (pt.Size) is in sectors while our checks and
customizations are in bytes, so we need to convert when comparing.
Co-Authored-By: Achilleas Koutsou <achilleas@koutsou.net>
Apply the minimum size specified in the file system customizations
also to existing partitions. Specifically, this now allows to set
a minimum size also for the root partition.
Allow the sector size to be specified on the partition table level by
introducing a new `SectorSize` field. Modify the conversion helpers
to use that new field with a fallback to default sector size in case
the field is `0`.
Add simple helper methods that convert between bytes and sectors. This
is a method of `PartitionTable`, since the sector size can in theory
be per partition table and this prepares for that case.
