So it appears that whilst xts.ko is present in the image-modules with the 3.2 kernel, it's not part of the crypto-modules-udeb for 3.2 based kernels and thus is not present on images that use 3.2 crypto-modules-udeb.
So the following combinations work:
boot hwe stack kernels, yet install 3.2 or any hwe kernel onto the target system encrypted with xts by default
The following combination does not work:
boot 3.2 stack kernel, and install encrypted 3.2 or any hwe kernel onto the target system encrypted with xts by default.
Release note workaround:
Using manual partitioning manually specify previous default IV initialisation vector aes-cbc.
Possibly we could specify that in the default preseed.
I would not want to revert partman-crypto change from using xts back to aes-cbc by default.
Ideally i'd like 3.2 crypto-udeb to contain xts.ko module. Adding linux package bug task. As then this bug would be properly resolved for 3.2 booted d-i.
So it appears that whilst xts.ko is present in the image-modules with the 3.2 kernel, it's not part of the crypto-modules-udeb for 3.2 based kernels and thus is not present on images that use 3.2 crypto- modules- udeb.
So the following combinations work:
boot hwe stack kernels, yet install 3.2 or any hwe kernel onto the target system encrypted with xts by default
The following combination does not work:
boot 3.2 stack kernel, and install encrypted 3.2 or any hwe kernel onto the target system encrypted with xts by default.
Release note workaround:
Using manual partitioning manually specify previous default IV initialisation vector aes-cbc.
Possibly we could specify that in the default preseed.
I would not want to revert partman-crypto change from using xts back to aes-cbc by default.
Ideally i'd like 3.2 crypto-udeb to contain xts.ko module. Adding linux package bug task. As then this bug would be properly resolved for 3.2 booted d-i.
Release team, please advice on further action.