<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 5, 2023 at 9:56 AM Lennart Poettering <<a href="mailto:lennart@poettering.net">lennart@poettering.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On So, 04.06.23 14:25, Valentin David (<a href="mailto:valentin.david@canonical.com" target="_blank">valentin.david@canonical.com</a>) wrote:<br>
<br>
> I have been trying to create a root partition from initrd with<br>
> systemd-repart. The repart.d file for this partition is as follow:<br>
><br>
> [Partition]<br>
> Type=root<br>
> Label=root<br>
> Encrypt=tpm2<br>
> Format=ext4<br>
> FactoryReset=yes<br>
><br>
> I am just using systemd-repart.service in initrd, without modification<br>
> (that is, it finds the disk from /sysusr/usr). Even though this is working,<br>
> the problem I have is that it takes a very long time for the partition to<br>
> be created. Looking at the logs, it spends most of time in the<br>
> reencryption.<br>
<br>
reencryption? We don't do any reencrytion really. i.e. we do not<br>
actually support anything like "cryptsetup reencrypt" at all. All we<br>
do is the equivalent of "cryptsetup luksFormat". Are you suggesting<br>
that repart is slower at formatting a block device via LUKS than<br>
invoking cryptsetup directly would be? I'd find that very surprising...<br></blockquote><div><br></div><div>This is what it looks like in src/partition/repart.c. <span class="gmail-pl-en">Function partition_encrypt calls </span><span class="gmail-pl-c1">sym_crypt_reencrypt_init_by_passphrase and then </span><span class="gmail-pl-c1">sym_crypt_reencrypt. And </span><span class="gmail-pl-c1">make_filesystem is called before </span><span class="gmail-pl-en">partition_encrypt. So it must reencrypt since mkfs was called before.<br></span></div><div><span class="gmail-pl-c1"><br></span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> For 11GB partition on a VM, it takes more than 2 minutes. On the bare metal<br>
> with a 512 GB nvme disk, it has been running for 3 hours. And it is still<br>
> not finished.<br>
<br>
This is really strange. The LUKS formatting should just write a<br>
superlock onto the disk, which is just a couple of sectors, and should<br>
barely take any time.<br>
<br>
Or are you saying "mke2fs" takes that long?<br>
<br>
Note that we specify lazy_itable_init=1 during formatting ext4, hence<br>
it should actually be super fast too...<br></blockquote><div><br></div><div>No. mkfs was done. In the logs it was all about reencryption. See <a href="https://gitlab.gnome.org/-/snippets/5809/raw/main/snippetfile1.txt">https://gitlab.gnome.org/-/snippets/5809/raw/main/snippetfile1.txt</a></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> I do not think cryptsetup reencryption supports holes. Is it normal to have<br>
> a full reencryption of a disk that was just initialized with mkfs.ext4? If<br>
> so, could we at least move the effective reencryption after<br>
> systemd-repart.service, so that the rest of the system can continue to boot?<br>
><br>
> I am running:<br>
> systemd 253.4 running in system mode (+PAM +AUDIT +SELINUX +APPARMOR +IMA<br>
> +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2<br>
> +IDN2 -IDN -IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 +PWQUALITY +P11KIT<br>
> -QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMM<br>
> ON +UTMP +SYSVINIT default-hierarchy=unified)<br>
><br>
> Cryptsetup: v2.6.1<br>
<br>
I am a bit puzzled by this. WOuld be good to figure out what actually<br>
is so slow here? formatting luks? formatting ext4? discarding?<br>
<br>
Lennart<br>
<br>
--<br>
Lennart Poettering, Berlin<br>
</blockquote></div></div>