growpart: Automatic partition resize prevents unlocking of encrypted root partition

[TheRealFalcon]

From https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1991554:

I modified the Ubuntu Server image so the root partition is encrypted. Since the Raspberry Pi 4b does not have hardware acceleration for AES I use adiantum for encryption. To take full advantage of its advertised performance gains, I used '--sector-size 4096' with cryptsetup. A requirement for this parameter to work is that the containing partition is aligned, at its start and end, to sector counts evenly divisible by 8.

When unlocking the partition, cryptsetup does apperently check if partition boundaries are evenly divisible by 8. On the first boot this is true, for any consecutive it is not. To me it seems cloud-init resizes the root partition (through growpart) to the maximum size possible. Sadly by doing so it interferes with the peculiar alignment requirements of cryptsetup.

It would be great if the root partition could end at an 1MiB boundary after resize.

In order for cloud-init to do this, growpart would need to support ending at a particular boundary, which I currently see no flags to make that happen.

[purpleidea]

zomg

On the first boot this is true, for any consecutive it is not.

Do you mean because after you've run growpart it's no longer divisible by 8?

[purpleidea]

(And what happens, cryptsetup can't unlock???)

[dermotbradley]

I started to investigate this issue some time ago but never got to the point of having a PR to submit.

It would be great if the root partition could end at an 1MiB boundary after resize.

For GPT-partitioned devices when growpart runs it leaves 32 bytes "free" at the end of the device for the backup GPT table, my in-progress fix was to instead align the end of partition on a 1MB (or 1MiB?) boundary but ensuring for GPT devices that at least 32 bytes were still free beyond that partition end.

I'll have to look at my notes to see how far I got with addressing this (I remember at the time doing some testing with both LUKS1 and LUKS2 volumes) and see if I can get a finished PR ready.

[xiachen-rh]

Hello @dermotbradley , do you have any update of your PR? We have a customer who would benefit from this feature, and we look forward to your PR when ready.

[smoser]

This feels basically correct to me. It passes tests here locally.
The idea is just to always make partition sizes 4k aligned. that costs up to 4096-512 bytes in worst case.

diff --git a/bin/growpart b/bin/growpart
index 102f56e..7df2450 100755
--- a/bin/growpart
+++ b/bin/growpart
@@ -398,6 +398,11 @@ resize_sfdisk() {
 		max_end=$((${sector_num} - ${gpt_second_size} - 1))
 	fi
 
+	# make partition sizes always even 4k units
+	local sectors_per_4k=$((4096/sector_size)) max_size4k=""
+	max_size4k=$((((max_end+1-pt_start)/sectors_per_4k)*sectors_per_4k))
+	max_end=$((max_size4k+pt_start-1))
+
 	if [ -n "${free_percent}" ]; then
 		free_percent_sectors=$((sector_num/100*free_percent))
 
@@ -602,6 +607,11 @@ resize_sgdisk() {
 
 	pt_size_bytes=$((${pt_size}*${sector_size}))
 
+	# make partition sizes always even 4k units
+	local sectors_per_4k=$((4096/sector_size)) max_size4k=""
+	max_size4k=$((((pt_max+1-pt_start)/sectors_per_4k)*sectors_per_4k))
+	pt_max=$((max_size4k+pt_start-1))
+
 	debug 1 "${dev}: pt_start=${pt_start} pt_end=${pt_end}" \
 		"pt_size=${pt_size} pt_max=${pt_max} last=${last} pt_size_bytes=${pt_size_bytes}"
 
diff --git a/test/test-growpart-overprovision b/test/test-growpart-overprovision
index 2a4a525..bea7723 100755
--- a/test/test-growpart-overprovision
+++ b/test/test-growpart-overprovision
@@ -59,10 +59,11 @@ enddevice=$(sfdisk --list --unit=S "$img" | grep "Disk $img:" | awk '{print $7}'
 endpart=$(sfdisk --list --unit=S "$img" | grep "$img" | grep -v "Disk" | awk '{print $3}')
 # Subtract the following from disk image end in sectors:
 #   - required number of overprovisioning sectors to leave unused
-#   - 33 sectors (MBR padding for GPT conversion)
+#   - 40 sectors (33 sectors of 512 bytes of MBR padding for GPT conversion
+#                 rounded up for 4k alignment)
 #   - 1 (as sector numbers start from 0)
 # to calculate the expected end of resized partition in sectors.
-expectedendpart=$((enddevice-(enddevice/100*freepercent)-33-1))
+expectedendpart=$((enddevice-(enddevice/100*freepercent)-40-1))
 echo
 if [ $endpart = $expectedendpart ]; then
 	echo "Final partition size matches expected partition size"
diff --git a/test/test-growpart-start-matches-size b/test/test-growpart-start-matches-size
index 5bcc586..bffe61c 100755
--- a/test/test-growpart-start-matches-size
+++ b/test/test-growpart-start-matches-size
@@ -91,5 +91,5 @@ trap cleanup EXIT
 
 # the sfdisk and sgdisk resizers result in slightly different output,
 # because of course they do.
-test_resize sfdisk 1026048 3168223
+test_resize sfdisk 1026048 3168216
 test_resize sgdisk 1026048 3166207

The fact that sgdisk didn't change in that test/test-growpart-overprovision feels not right.

[smoser]

I started to investigate this issue some time ago but never got to the point of having a PR to submit.

It would be great if the root partition could end at an 1MiB boundary after resize.

For GPT-partitioned devices when growpart runs it leaves 32 bytes "free" at the end of the device for the backup GPT table, my in-progress fix was to instead align the end of partition on a 1MB (or 1MiB?) boundary but ensuring for GPT devices that at least 32 bytes were still free beyond that partition end.

Its not 32 bytes, its 33 sectors (see the image here).

The patch i gave aligns at 4k, i think it could be adjusted pretty easy to do 1MiB and that seems fine to me too.

It is what I have done subsequently in disko . There I just aligned on 4MiB boundaries.

[smoser]

generalized and using 1MiB as size unit rather than 4096.

diff --git a/bin/growpart b/bin/growpart
index 102f56e..0274014 100755
--- a/bin/growpart
+++ b/bin/growpart
@@ -398,6 +398,12 @@ resize_sfdisk() {
 		max_end=$((${sector_num} - ${gpt_second_size} - 1))
 	fi
 
+	# make partition sizes always even units of $align bytes.
+	local align=$((1024*1024))
+	local sectors_per_align=$((align/sector_size)) max_size_align=""
+	max_size_align=$((((max_end+1-pt_start)/sectors_per_align)*sectors_per_align))
+	max_end=$((max_size_align+pt_start-1))
+
 	if [ -n "${free_percent}" ]; then
 		free_percent_sectors=$((sector_num/100*free_percent))
 
@@ -602,6 +608,12 @@ resize_sgdisk() {
 
 	pt_size_bytes=$((${pt_size}*${sector_size}))
 
+	# make partition sizes always even units of $align bytes.
+	local align=$((1024*1024))
+	local sectors_per_align=$((align/sector_size)) max_size_align=""
+	max_size_align=$((((pt_max+1-pt_start)/sectors_per_align)*sectors_per_align))
+	pt_max=$((max_size_align+pt_start-1))
+
 	debug 1 "${dev}: pt_start=${pt_start} pt_end=${pt_end}" \
 		"pt_size=${pt_size} pt_max=${pt_max} last=${last} pt_size_bytes=${pt_size_bytes}"
 
diff --git a/test/test-growpart-overprovision b/test/test-growpart-overprovision
index 2a4a525..efa8db8 100755
--- a/test/test-growpart-overprovision
+++ b/test/test-growpart-overprovision
@@ -57,18 +57,12 @@ sfdisk --list --unit=S "$img"
 
 enddevice=$(sfdisk --list --unit=S "$img" | grep "Disk $img:" | awk '{print $7}')
 endpart=$(sfdisk --list --unit=S "$img" | grep "$img" | grep -v "Disk" | awk '{print $3}')
-# Subtract the following from disk image end in sectors:
-#   - required number of overprovisioning sectors to leave unused
-#   - 33 sectors (MBR padding for GPT conversion)
-#   - 1 (as sector numbers start from 0)
-# to calculate the expected end of resized partition in sectors.
-expectedendpart=$((enddevice-(enddevice/100*freepercent)-33-1))
-echo
+expectedendpart=182271
 if [ $endpart = $expectedendpart ]; then
 	echo "Final partition size matches expected partition size"
 	echo
 else
-	echo "ERROR: final partition size of $endpart is different than expected size of $expectedendpart"
+	echo "ERROR: final partition end of $endpart is different than expected end of $expectedendpart"
 	exit 1
 fi
 
diff --git a/test/test-growpart-start-matches-size b/test/test-growpart-start-matches-size
index 5bcc586..b98e668 100755
--- a/test/test-growpart-start-matches-size
+++ b/test/test-growpart-start-matches-size
@@ -91,5 +91,5 @@ trap cleanup EXIT
 
 # the sfdisk and sgdisk resizers result in slightly different output,
 # because of course they do.
-test_resize sfdisk 1026048 3168223
+test_resize sfdisk 1026048 3166208
 test_resize sgdisk 1026048 3166207

someone should take a look at the actual sizes that come out and see if they are actually correct.
The "over provision" test (--free-percent) is kind of weird anyway. should you count the now-unusable 1MiB at the end as part of the free space?