fcos translate.go: add warn on small or constrained root partition#378
fcos translate.go: add warn on small or constrained root partition#378prestist merged 2 commits intocoreos:mainfrom
Conversation
df3fd2e to
166e0d5
Compare
b95add4 to
98397ca
Compare
8a4a4c3 to
50f80a6
Compare
50f80a6 to
8882e58
Compare
74876cc to
78f8481
Compare
78f8481 to
530a65e
Compare
|
The first commit message says fcos v0_7_exp but there is no v0_7_exp directory. May be this should be fcos v1_7_exp? |
|
Minor: Typo in commit message body: "contstraints" should be "constraints" |
|
|
||
| // In the boot_device.mirror case, nothing specifies partition numbers | ||
| // so match existing partitions only when `wipeTable` is false | ||
| if !util.IsTrue(disk.WipeTable) { |
There was a problem hiding this comment.
Trying to understand this wipetable change. The previous code only checked reserved partlabels when wipeTable is false. The current change now runs the root validation even when wipeTable is true. I guess it is intentional.
There was a problem hiding this comment.
Yeah it was intentional the root partition size validation needs to happen regardless of wipeTable, because:
-
Even when wipeTable is true (creating a fresh partition table), users can still specify
partitions that trap the root partition - this is exactly the scenario we want to warn about -
The wipeTable check only applies to the "reserved partlabel validation" (checking that
BIOS-BOOT is partition 1, root is partition 4, etc.). That validation should only run
when wipeTable is false because we're matching existing partitions. -
The root size/constraint validation is orthogonal to whether we're wiping the table -
it's about warning users before they create a configuration that won't have enough space
for OS updates.
7aa0707 to
2641b14
Compare
|
Fixed both issues! I've rebased and updated the commit messages:
|
b910184 to
f042937
Compare
Nope that was an oversite, due to the latest stabilization and the age of this pr. |
|
If you want to test it locally you can do this: 1. Checkout and Build
# Checkout the PR
gh pr checkout 378
# Build butane
./build
2. Manual Testing Scenarios
The PR adds two warnings for root partition issues:
⚠️ Warning 1: Root Too Small (< 8 GiB)
cat > test-small.bu << 'EOF'
variant: fcos
version: 1.7.0
storage:
disks:
- device: /dev/vda
wipe_table: false
partitions:
- number: 4
label: root
size_mib: 5000
EOF
./bin/amd64/butane < test-small.bu
Result: warning: root should have 8GiB of space assigned ✅
⚠️ Warning 2: Root Constrained by Auto-Positioned Partition
cat > test-constrained.bu << 'EOF'
variant: fcos
version: 1.7.0
storage:
disks:
- device: /dev/vda
partitions:
- number: 4
label: root
size_mib: 0
- number: 5
label: data
start_mib: 0
EOF
./bin/amd64/butane < test-constrained.bu
Result: warning: root partition cannot expand; it is set to fill available space but is followed by an auto-positioned partition ✅
✅ No Warning: 8 GiB or larger
cat > test-ok.bu << 'EOF'
variant: fcos
version: 1.7.0
storage:
disks:
- device: /dev/vda
wipe_table: false
partitions:
- number: 4
label: root
size_mib: 8192
EOF
./bin/amd64/butane --strict < test-ok.bu # No warnings
|
f042937 to
1521b20
Compare
| nextStart = *nextPartition.StartMiB | ||
| } | ||
| // If this partition starts before the current "next", it's closer to root | ||
| if (apStart > 0 && apStart < nextStart) || (nextStart == 0 && apStart > 0) { |
There was a problem hiding this comment.
The condition here causes an explicitly positioned partition to replace an auto-positioned one as the "nearest" candidate but the auto-positioned partition is the one that actually constrains root right?
There was a problem hiding this comment.
oooof, okay; yees you are right; Let me update the code to account for this.
1521b20 to
7e3ec1a
Compare
|
@aaradhak Good catch! You're right - the previous logic missed when both an auto-positioned and an explicitly positioned partition were present, the "find nearest" would prefer the explicit partitions, effectively hiding the auto-positioned partition that actually constrains root. The startMiB of any following partition. If this is unspecified (0) and the root sizeMiB is also unspecified, then the following partition will prevent the root partition from growing at all, and we should warn. Instead of trying to determine which partition is physically "nearest" to root (which we can't reliably do without knowing disk size and sgdisk's placement heuristics), we now simply check: if root is auto-sized AND any other partition on the disk has startMiB unspecified, warn. I also added a test case for this scenario (auto-positioned partition with an explicit one also present). |
Fixes: coreos#211, the root partition needs a certain amount of space, with recent changes butane has the opportunity to warn when those expectations are not met. Warn if root partition sizeMiB is explicitly less than 8GiB, or if root is set to fill available space and any other partition on the disk is auto-positioned (startMiB == 0 or nil), which would prevent root from expanding. Applied to FCOS versions v1_3 through v1_8_exp.
Add test cases for: - Root partition constrained by disk position (not partition number) - Root partition with auto-positioned following partition (StartMiB=0) - Root partition NOT constrained when next partition has explicit StartMiB - Root partition constrained by auto-positioned partition even when an explicit partition is also present - Root partition size validation (too small, exactly 8GiB) Applied to FCOS versions v1_3 through v1_8_exp.
7e3ec1a to
a063fa1
Compare
#211
Note I somehow dropped the '1' in the version for FCOS in the commit messages.. but before I update the commit structure lets make sure we are happy with the functional changes. Look at the first 2 commits, i.e the exp changes this is basically propagated to all versions back to 1_3 as you can see later with the fixup commits. Once approved I will merge the fixup commits with a rename to the commits to be inclusive of the changes!