| Message ID | 20230728143320.3891194-3-stefan-koch@siemens.com (mailing list archive) |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | initramfs-crypt-hook: Fix disk encryption | expand |
On 28.07.23 16:33, Koch, Stefan (DI PA DCP R&D 3) wrote: > This checks and repairs the filesystem first to ensure that > resize2fs will succeed. > > Signed-off-by: Stefan Koch <stefan-koch@siemens.com> > --- > .../initramfs-crypt-hook/files/encrypt_partition.systemd.script | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/recipes-initramfs/initramfs-crypt-hook/files/encrypt_partition.systemd.script b/recipes-initramfs/initramfs-crypt-hook/files/encrypt_partition.systemd.script > index 83c3238..b32b2f2 100644 > --- a/recipes-initramfs/initramfs-crypt-hook/files/encrypt_partition.systemd.script > +++ b/recipes-initramfs/initramfs-crypt-hook/files/encrypt_partition.systemd.script > @@ -87,6 +87,7 @@ reencrypt_existing_partition() { > reduced_size="$(expr "$part_size_blocks" - 65536 )" > reduced_size_in_byte="$(expr "$reduced_size" \* 512)" > reduced_size_in_kb="$(expr "$reduced_size_in_byte" / 1024)K" > + e2fsck -y -f "$1" > if ! resize2fs "$1" "${reduced_size_in_kb}"; then > panic "reencryption of filesystem $1 cannot continue!" > fi Why is that needed? Conceptually, we should start with a clean fs, fresh from the image build, resized on first boot. Jan
On Thu, 2023-08-10 at 12:34 +0200, Jan Kiszka wrote: > On 28.07.23 16:33, Koch, Stefan (DI PA DCP R&D 3) wrote: > > This checks and repairs the filesystem first to ensure that > > resize2fs will succeed. > > > > Signed-off-by: Stefan Koch <stefan-koch@siemens.com> > > --- > > .../initramfs-crypt-hook/files/encrypt_partition.systemd.script | > > 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/recipes-initramfs/initramfs-crypt- > > hook/files/encrypt_partition.systemd.script b/recipes- > > initramfs/initramfs-crypt- > > hook/files/encrypt_partition.systemd.script > > index 83c3238..b32b2f2 100644 > > --- a/recipes-initramfs/initramfs-crypt- > > hook/files/encrypt_partition.systemd.script > > +++ b/recipes-initramfs/initramfs-crypt- > > hook/files/encrypt_partition.systemd.script > > @@ -87,6 +87,7 @@ reencrypt_existing_partition() { > > reduced_size="$(expr "$part_size_blocks" - 65536 )" > > reduced_size_in_byte="$(expr "$reduced_size" \* 512)" > > reduced_size_in_kb="$(expr "$reduced_size_in_byte" / > > 1024)K" > > + e2fsck -y -f "$1" > > if ! resize2fs "$1" "${reduced_size_in_kb}"; then > > panic "reencryption of filesystem $1 cannot > > continue!" > > fi > > Why is that needed? Conceptually, we should start with a clean fs, > fresh > from the image build, resized on first boot. In our case the problem could be setting some modifications with tune2fs at image generation. Additionally I have observed that resize2fs breaks without e2fsck called before, when setting the break= kernel commandline argument, and mounting and unmounting (without forcing, just standard umount, no new data was copied) the partition before disk encryption scripts are running. What is for cases that are using the reencrypt mechanism? The partitions should be in a modified-state by former device usage and just installing a image upgrade that enables disk encryption. > > Jan >
On 14.08.23 13:36, Koch, Stefan (DI PA DCP R&D 3) wrote: > On Thu, 2023-08-10 at 12:34 +0200, Jan Kiszka wrote: >> On 28.07.23 16:33, Koch, Stefan (DI PA DCP R&D 3) wrote: >>> This checks and repairs the filesystem first to ensure that >>> resize2fs will succeed. >>> >>> Signed-off-by: Stefan Koch <stefan-koch@siemens.com> >>> --- >>> .../initramfs-crypt-hook/files/encrypt_partition.systemd.script | >>> 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/recipes-initramfs/initramfs-crypt- >>> hook/files/encrypt_partition.systemd.script b/recipes- >>> initramfs/initramfs-crypt- >>> hook/files/encrypt_partition.systemd.script >>> index 83c3238..b32b2f2 100644 >>> --- a/recipes-initramfs/initramfs-crypt- >>> hook/files/encrypt_partition.systemd.script >>> +++ b/recipes-initramfs/initramfs-crypt- >>> hook/files/encrypt_partition.systemd.script >>> @@ -87,6 +87,7 @@ reencrypt_existing_partition() { >>> reduced_size="$(expr "$part_size_blocks" - 65536 )" >>> reduced_size_in_byte="$(expr "$reduced_size" \* 512)" >>> reduced_size_in_kb="$(expr "$reduced_size_in_byte" / >>> 1024)K" >>> + e2fsck -y -f "$1" >>> if ! resize2fs "$1" "${reduced_size_in_kb}"; then >>> panic "reencryption of filesystem $1 cannot >>> continue!" >>> fi >> >> Why is that needed? Conceptually, we should start with a clean fs, >> fresh >> from the image build, resized on first boot. > > In our case the problem could be setting some modifications with > tune2fs at image generation. Via wic or via custom post-processing? > > Additionally I have observed that resize2fs breaks without e2fsck > called before, when setting the break= kernel commandline argument, and > mounting and unmounting (without forcing, just standard umount, no new > data was copied) the partition before disk encryption scripts are > running. > > What is for cases that are using the reencrypt mechanism? The > partitions should be in a modified-state by former device usage and > just installing a image upgrade that enables disk encryption. > Re-encrypt is so far designed to only run on first boot against a clean disk, not used before. I'm not sure if we have more corner cases lurking behind the corner when we expand that. And we should have test cases for that expansion in isar-cip-core. Quirin, what do you think? Jan
On 8/14/23 13:46, Jan Kiszka wrote: > On 14.08.23 13:36, Koch, Stefan (DI PA DCP R&D 3) wrote: >> On Thu, 2023-08-10 at 12:34 +0200, Jan Kiszka wrote: >>> On 28.07.23 16:33, Koch, Stefan (DI PA DCP R&D 3) wrote: >>>> This checks and repairs the filesystem first to ensure that >>>> resize2fs will succeed. >>>> >>>> Signed-off-by: Stefan Koch <stefan-koch@siemens.com> >>>> --- >>>> .../initramfs-crypt-hook/files/encrypt_partition.systemd.script | >>>> 1 + >>>> 1 file changed, 1 insertion(+) >>>> >>>> diff --git a/recipes-initramfs/initramfs-crypt- >>>> hook/files/encrypt_partition.systemd.script b/recipes- >>>> initramfs/initramfs-crypt- >>>> hook/files/encrypt_partition.systemd.script >>>> index 83c3238..b32b2f2 100644 >>>> --- a/recipes-initramfs/initramfs-crypt- >>>> hook/files/encrypt_partition.systemd.script >>>> +++ b/recipes-initramfs/initramfs-crypt- >>>> hook/files/encrypt_partition.systemd.script >>>> @@ -87,6 +87,7 @@ reencrypt_existing_partition() { >>>> reduced_size="$(expr "$part_size_blocks" - 65536 )" >>>> reduced_size_in_byte="$(expr "$reduced_size" \* 512)" >>>> reduced_size_in_kb="$(expr "$reduced_size_in_byte" / >>>> 1024)K" >>>> + e2fsck -y -f "$1" >>>> if ! resize2fs "$1" "${reduced_size_in_kb}"; then >>>> panic "reencryption of filesystem $1 cannot >>>> continue!" >>>> fi >>> >>> Why is that needed? Conceptually, we should start with a clean fs, >>> fresh >>> from the image build, resized on first boot. >> >> In our case the problem could be setting some modifications with >> tune2fs at image generation. > > Via wic or via custom post-processing? > >> >> Additionally I have observed that resize2fs breaks without e2fsck >> called before, when setting the break= kernel commandline argument, and >> mounting and unmounting (without forcing, just standard umount, no new >> data was copied) the partition before disk encryption scripts are >> running. >> Should the same behavior also occur with the expand partition on first boot? There is also no e2fsck after resize2fs. https://github.com/ilbers/isar/blob/d454381fa90874fb9a8496f9b5980ebda8747945/meta/recipes-support/expand-on-first-boot/files/expand-last-partition.sh#L79 >> What is for cases that are using the reencrypt mechanism? The >> partitions should be in a modified-state by former device usage and >> just installing a image upgrade that enables disk encryption. >> > > Re-encrypt is so far designed to only run on first boot against a clean > disk, not used before. I'm not sure if we have more corner cases lurking > behind the corner when we expand that. And we should have test cases for > that expansion in isar-cip-core. Quirin, what do you think? Re-encryption after modification was until now not in scope. I am sure that there a corner cases. expand on first boot with disk encryption is another issue. Test case are required. Quirin > > Jan >
On Mon, 2023-08-14 at 14:04 +0200, Gylstorff Quirin wrote: > > > On 8/14/23 13:46, Jan Kiszka wrote: > > On 14.08.23 13:36, Koch, Stefan (DI PA DCP R&D 3) wrote: > > > On Thu, 2023-08-10 at 12:34 +0200, Jan Kiszka wrote: > > > > On 28.07.23 16:33, Koch, Stefan (DI PA DCP R&D 3) wrote: > > > > > This checks and repairs the filesystem first to ensure that > > > > > resize2fs will succeed. > > > > > > > > > > Signed-off-by: Stefan Koch <stefan-koch@siemens.com> > > > > > --- > > > > > .../initramfs-crypt- > > > > > hook/files/encrypt_partition.systemd.script | > > > > > 1 + > > > > > 1 file changed, 1 insertion(+) > > > > > > > > > > diff --git a/recipes-initramfs/initramfs-crypt- > > > > > hook/files/encrypt_partition.systemd.script b/recipes- > > > > > initramfs/initramfs-crypt- > > > > > hook/files/encrypt_partition.systemd.script > > > > > index 83c3238..b32b2f2 100644 > > > > > --- a/recipes-initramfs/initramfs-crypt- > > > > > hook/files/encrypt_partition.systemd.script > > > > > +++ b/recipes-initramfs/initramfs-crypt- > > > > > hook/files/encrypt_partition.systemd.script > > > > > @@ -87,6 +87,7 @@ reencrypt_existing_partition() { > > > > > reduced_size="$(expr "$part_size_blocks" - 65536 )" > > > > > reduced_size_in_byte="$(expr "$reduced_size" \* > > > > > 512)" > > > > > reduced_size_in_kb="$(expr "$reduced_size_in_byte" / > > > > > 1024)K" > > > > > + e2fsck -y -f "$1" > > > > > if ! resize2fs "$1" "${reduced_size_in_kb}"; then > > > > > panic "reencryption of filesystem $1 cannot > > > > > continue!" > > > > > fi > > > > > > > > Why is that needed? Conceptually, we should start with a clean > > > > fs, > > > > fresh > > > > from the image build, resized on first boot. > > > > > > In our case the problem could be setting some modifications with > > > tune2fs at image generation. > > > > Via wic or via custom post-processing? Custom post-processing. We cloud add fsck there, too. > > > > > > > > Additionally I have observed that resize2fs breaks without e2fsck > > > called before, when setting the break= kernel commandline > > > argument, and > > > mounting and unmounting (without forcing, just standard umount, > > > no new > > > data was copied) the partition before disk encryption scripts are > > > running. > > > > Should the same behavior also occur with the expand partition on > first > boot? I would think so. > There is also no e2fsck after resize2fs. Needed also before. > > https://github.com/ilbers/isar/blob/d454381fa90874fb9a8496f9b5980ebda8747945/meta/recipes-support/expand-on-first-boot/files/expand-last-partition.sh#L79 > > > > What is for cases that are using the reencrypt mechanism? The > > > partitions should be in a modified-state by former device usage > > > and > > > just installing a image upgrade that enables disk encryption. > > > > > > > Re-encrypt is so far designed to only run on first boot against a > > clean > > disk, not used before. I'm not sure if we have more corner cases > > lurking > > behind the corner when we expand that. And we should have test > > cases for > > that expansion in isar-cip-core. Quirin, what do you think? > > Re-encryption after modification was until now not in scope. I am > sure > that there a corner cases. expand on first boot with disk encryption > is > another issue. > > Test case are required. > > > Quirin > > > > > Jan > > -- Stefan Koch Siemens AG http://www.siemens.com/
diff --git a/recipes-initramfs/initramfs-crypt-hook/files/encrypt_partition.systemd.script b/recipes-initramfs/initramfs-crypt-hook/files/encrypt_partition.systemd.script index 83c3238..b32b2f2 100644 --- a/recipes-initramfs/initramfs-crypt-hook/files/encrypt_partition.systemd.script +++ b/recipes-initramfs/initramfs-crypt-hook/files/encrypt_partition.systemd.script @@ -87,6 +87,7 @@ reencrypt_existing_partition() { reduced_size="$(expr "$part_size_blocks" - 65536 )" reduced_size_in_byte="$(expr "$reduced_size" \* 512)" reduced_size_in_kb="$(expr "$reduced_size_in_byte" / 1024)K" + e2fsck -y -f "$1" if ! resize2fs "$1" "${reduced_size_in_kb}"; then panic "reencryption of filesystem $1 cannot continue!" fi
This checks and repairs the filesystem first to ensure that resize2fs will succeed. Signed-off-by: Stefan Koch <stefan-koch@siemens.com> --- .../initramfs-crypt-hook/files/encrypt_partition.systemd.script | 1 + 1 file changed, 1 insertion(+)