fix(layout): skip the no-op grow when already at max - #343
Merged
Merged
Conversation
Collaborator
Author
|
This should fix kairos CI being red. |
mudler
approved these changes
Sep 24, 2026
The idempotent path made ExpandLastPartition succeed when the partition
already spanned the rest of the disk, but the function still fell
through to ReReadPartitionTable, udevadm trigger and
DefaultGrowFsToMax.GrowFSToMax. The last one ephemeral-mounts the
partition, calls unshare(CLONE_NEWNS) and mount("/", MS_REC|MS_PRIVATE,
...) on the current namespace, issues EXT4_IOC_RESIZE_FS for a no-op
resize, and unmounts. This runs on the rootfs stage inside the
initramfs at the same time as the initramfs is laying down the mount
tree the rest of the boot depends on, so the two compete and the boot
ends up short of the mounts it needs.
Return early once we know there is nothing to do. Already-at-max means
the partition table needs no rewrite, so udev has no new event to see,
and the filesystem already spans its partition. Downstream is
unchanged on the real-expand path.
The "Expanding twice" spec pinned the grow count at two, since the
previous behaviour was to still call GrowFSToMax on the second boot.
The no-op path no longer touches the filesystem, so the count is one.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Signed-off-by: Dimitris Karakasilis <dimitris@karakasilis.me>
jimmykarily
force-pushed
the
fix-broken-partitioning
branch
from
September 24, 2026 08:12
185b5df to
4726737
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The idempotent path made ExpandLastPartition succeed when the partition already spanned the rest of the disk, but the function still fell through to ReReadPartitionTable, udevadm trigger and DefaultGrowFsToMax.GrowFSToMax. The last one ephemeral-mounts the partition, calls unshare(CLONE_NEWNS) and mount("/", MS_REC|MS_PRIVATE, ...) on the current namespace, issues EXT4_IOC_RESIZE_FS for a no-op resize, and unmounts. On the rootfs stage inside the initramfs that runs at the same time as the initramfs is laying down the mount tree the rest of the boot depends on, so the two compete and the boot ends up short of the mounts it needs.
Return early once we know there is nothing to do. Already-at-max means the partition table needs no rewrite, so udev has no new event to see, and the filesystem already spans its partition. Downstream is unchanged on the real-expand path.