- Package:
- debian-installer
- Source:
- debian-installer
- Description:
- Debian Installer documentation
- Submitter:
- Cyril Brulebois
- Date:
- 2023-04-21 21:27:03 UTC
- Severity:
- normal
Package: debian-installer Severity: serious Justification: not releasable Hi, I'm seeing at least two problems with cryptsetup while testing daily builds: - with 6.1.0-1 (currently getting into the archive), my very usual 1G RAM / 5G storage setup can no longer get an automated encrypted LVM setup created: cryptsetup triggers the OOMK while creating the encrypted storage; that doesn't happen with 6.0.0-6. Not sure cryptsetup itself is the culprit, it might just be more components or heavier components on the kernel side, pushing memory to the limit. - with either kernel (and 1G RAM for 6.0.0-6, 2G RAM for 6.1.0-1 due to the first point), I cannot boot into the installed system: I'm not getting the LVM passphrase prompt, and the root device is therefore missing. I haven't investigated either issue, and I'm not sure when I'll be able to. Help welcome. The first point could be waved aside with an errata entry; the second point is going to be a blocker for the next release. Cheers,
Cyril Brulebois <kibi@debian.org> (2023-01-08): Trying to investigate the second one, I cannot replicate my earlier results, with either a clean unstable daily build using 6.1.0-1 or with D-I Bookworm Alpha 1; and besides cryptsetup uploads in early December, I must admit a quick look around didn't suggest anything obvious that could explain what I were getting… Bad luck, maybe; lowering severity accordingly for the time being. Cheers,
Debian Bug Tracking System <owner@bugs.debian.org> (2023-01-09): No, that bug isn't found in that version. We wouldn't have released d-i with such an obvious issue. Cheers,
cc += cryptsetup maintainers (hi, long time no see!) Cyril Brulebois <kibi@debian.org> (2023-01-09): Testing d-i built against testing udebs again, I can replicate this issue now. I suppose this might be some component getting bigger over time, and pushing the limit somehow. And the various builds I tried back in January might have been tiptoeing around that limit… Looking at `free` with this netboot-gtk mini.iso build, inside kvm, with 1G RAM, `used` is ~100M, `free` is 500+ M, and yet, cryptsetup gets OOMK'd. Is cryptsetup being stupid and miscomputing RAM requirements for that setup? (ISTR LUKS2 means heavier computation, tweaked depending on hardware, but I haven't followed that closely.) The memory pressure at this particular point of the installation process seems quite low, so crashing with free at 50% feels very wrong to me… Cheers,
I haven’t look at cryptsetup. What is the purpose? Get Outlook for iOS<https://aka.ms/o0ukef> Testing d-i built against testing udebs again, I can replicate this issue now. I suppose this might be some component getting bigger over time, and pushing the limit somehow. And the various builds I tried back in January might have been tiptoeing around that limit… Looking at `free` with this netboot-gtk mini.iso build, inside kvm, with 1G RAM, `used` is ~100M, `free` is 500+ M, and yet, cryptsetup gets OOMK'd. Is cryptsetup being stupid and miscomputing RAM requirements for that setup? (ISTR LUKS2 means heavier computation, tweaked depending on hardware, but I haven't followed that closely.) The memory pressure at this particular point of the installation process seems quite low, so crashing with free at 50% feels very wrong to me… Cheers, -- Cyril Brulebois (kibi@debian.org) <https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
Hi kibi! By default the PBKDF benchmark caps the memory cost at 1GiB or half of the physical memory, whichever is smaller. So indeed with 1G RAM and ~50% free one might trigger the OOM killer. A workaround is to pass `--pbkdf-memory` with a suitable value (256M should be more than enough in that case) on memory-constrained systems, but cryptsetup should arguably adjust the memory cost on its own. Reported the issue upstream at https://gitlab.com/cryptsetup/cryptsetup/-/issues/802 . But that's only for the first point. Do you have a reproducer for the second point? Tried https://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/debian-testing-amd64-netinst.iso in a VM with 2G RAM [0] and chose the “encrypted LVM” scheme (both on the graphical and text install); the system refused to boot because the initramfs image contained an older e2fsck (“/dev/mapper/debian--vg-root has unsupported feature(s): FEATURE_C12”), however there was no problem after upgrading to sid at finish-install stage (and in both cases I could map the device, so neither bookworm's cryptsetup nor the kernel is at fault AFAICT). Cheers
Hi Guilhem, Guilhem Moulin <guilhem@debian.org> (2023-02-18): Thanks! I'm so sorry, I forgot I was hitting two separate issues at that time. The one I can reproduce right now is the first one (OOMK), the second one might have been some side effect of my mixing packages together… I can definitely install with -m 1.1G (or higher), and also log into the installed system. Retitling to make all of this clearer. Cheers,
Hi kibi, In https://bugs.debian.org/1032235#107 elbrus (CC'ed) asked for a t-p-u upload of cryptsetup to fix a potential major regression should bookworm's src:argon2 ever be rebuilt with the bookworm toolchain. The version currently in sid, 2:2.6.1-3, also includes 2 upstream patches to mitigate #1028250. (“Mitigate”, because it only reduces the memory cost of the PBKDF on memory-constrained systems without swap. This only buys time, and Milan argued that such systems are better off using a non-memory hard PBKDF. I might propose a partman-crypto patch to that effect, but I guess it's too late for bookworm at this point.) 2:2.6.1-3 (sid) and 2:2.6.1-1 (testing) differs as such: https://salsa.debian.org/cryptsetup-team/cryptsetup/-/compare/debian%2F2%252.6.1-1...debian%2F2%252.6.1-3 Would you rather have us exclude these backported upstream patches from the t-p-u upload or should we leave them in? Concretely these patches set the maximum memory cost at ~256M on a system with 1G RAM, so in practice the memory pressure never exceeds 75% during installation (tested with d-i bookworm alpha 2 with updated src:cryptsetup udebs, graphical install). Cheers
Hi Guilhem, Guilhem Moulin <guilhem@debian.org> (2023-03-26): Sorry, I haven't been able to follow upstream/downstream discussions too closely, but I do appreciate everything that's been happening on that front. I'm happy to have the patches included, and I can definitely live with possible temporary regressions (should that happen) that might arise from having them. Thanks for your help, as always. Cheers,
Hi again, Cyril Brulebois <kibi@debian.org> (2023-03-26): Pre-upload testing shows that the situation seems unchanged with 2:2.6.1-3~deb12u1: encrypted LVM still OOMK's with otherwise default options in the installer, when the VM is started with `kvm -m 1G`; that's fine with `kvm -m 1.2G` so at least it didn't seem to regress from the previous d-i release, and I've decided to continue d-i preps accordingly. Cheers,
Hi kibi, Ah right, reopened the upstream issue but forgot to follow-up here :-( https://gitlab.com/cryptsetup/cryptsetup/-/issues/802#note_1328592911 As I wrote in the upstream BTS the patch appears to be incomplete, AFAICT it helps in the PBKDF benchmark but just like you I also noticed it still sometimes fails while running the keyslot key derivation. Unfortunately I only found that out *after* uploading ~deb12u1… It was premature to think one could remove the errata from the bookworm d-i, but at least I'm quite confident that does not make the OOMK issue worse: it solves it at early stage but but it sometimes still trigger later. From a user perspective, I guess it's best to stick to the errata for now (at least for the graphical installer; in text mode 1G RAM appear to be enough according to my tests). Depending on what upstream comes up with we might suggest to fix that via s-p-u later. Thanks to you, elbrus, an other Release Team members for everything!
Hi kibi, AFAICT the issue is now fully fixed upstream: on systems without swap the memory cost won't exceed half the amount of free memory during PBKDF benchmarking. I can think of the following next steps (list probably not exhaustive): * Don't do anything: ship 2:2.6.1-3~deb12u1 in bookworm and leave the DI errata in place. The downside is that the PBKDF needs roughly half of the physical memory, so the OOM killer might trigger if the rest of the system uses close to the other half. Moreover this not future proof, as memory requirement increases along releases. (That said the issue has been present since 2 releases and there is nothing we can do about existing volumes. Concretely, that means low-memory Bookworm rescue systems will likely OOM when trying to luksOpen an existing LUKS2 volume in graphical mode.) * Wait for upstream to release 2.6.2 with fixes for #-1 as well as other bugfixes and upload it, either via t-p-u during the hard freeze or later via s-p-u. In upstream's own words “[the minor release] will take few week because of translation loop etc.” The downside being of course more review work for the release team, as the diff is already rather large: https://gitlab.com/cryptsetup/cryptsetup/-/compare/v2.6.1...main?from_project_id=195655&straight=false * Backport upstream MR !498, let it mature in sid for a few weeks then upload 2:2.6.1-4~deb12u1 via t-p-u. There are only 2 upstream commits to cherry-pick and neither is large nor intrusive; moreover like the commits previously cherry-picked they are no-op on “normal” systems (only systems without swap are affected). For convenience I attach a debdiff for 2:2.6.1-3~deb12u2 and you'll also find binary packages for amd64 at https://people.debian.org/~guilhem/tmp/cryptsetup_2.6.1-3~deb12u2/ Tested: autopkgtests (incl. full upstream test suite), d-i in both graphical and text install on VMs with 1024M RAM (now memory cost won't exceed ~250M resp. ~300M thus leaving plenty of headroom for the rest). Your call :-)
Hi, (Letting Paul and the bug report know about our little chat.) Guilhem Moulin <guilhem@debian.org> (2023-04-20): partitioning, as the swap will only be added/activated after formatting the disk. I'd rather avoid that one for the reasons you mention. Waiting is definitely not needed from my point of view. Since you're happy with that approach, let's go for an upload to unstable for the time being, I'll conduct some tests shortly, and once it's indeed confirmed to work fine, go via t-p-u (because of the same fun as before with some library) so that it can be used for rc3 (if it's ready by then — we haven't really defined when it's going to happen besides “somewhen before end of April”). Cheers,
Hi, Just uploaded 2:2.6.1-4 to sid, and locally prepared a rebuild for bookworm (2:2.6.1-4~deb12u1). Comparing PBKDF benchmark results obtained using default settings (guided “encrypted LVM” partitioning scheme) between the last 3 releases and 1, 2, or 4G RAM (the first luksDump is what I got out of d-i, the second shows benchmark results on the final system — with swap), I get the following parameters (summary at the bottom). Buster (debian-10.12.0-amd64-netinst.iso, text install), 1024M RAM: root@debian:~# cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF PBKDF: argon2i Time cost: 4 Memory: 504962 Threads: 2 root@debian:~# cryptsetup luksConvertKey /dev/vda5 <<<test root@debian:~# cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF PBKDF: argon2i Time cost: 8 Memory: 505350 Threads: 2 Buster (debian-10.12.0-amd64-netinst.iso, text install), 2048M RAM: root@debian:~# cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF PBKDF: argon2i Time cost: 4 Memory: 538914 Threads: 2 root@debian:~# cryptsetup luksConvertKey /dev/vda5 <<<test root@debian:~# cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF PBKDF: argon2i Time cost: 4 Memory: 1021446 Threads: 2 Buster (debian-10.12.0-amd64-netinst.iso, text install), 4096M RAM: root@debian:~# cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF PBKDF: argon2i Time cost: 4 Memory: 533886 Threads: 2 root@debian:~# cryptsetup luksConvertKey /dev/vda5 <<<test root@debian:~# cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF PBKDF: argon2i Time cost: 4 Memory: 1048576 Threads: 2 Bullseye (debian-11.6.0-amd64-netinst.iso, text install), 1024M RAM: root@debian:~# cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF PBKDF: argon2i Time cost: 4 Memory: 499892 Threads: 2 root@debian:~# cryptsetup luksConvertKey /dev/vda5 <<<test root@debian:~# cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF PBKDF: argon2i Time cost: 8 Memory: 499888 Threads: 2 Bullseye (debian-11.6.0-amd64-netinst.iso, text install), 2048M RAM: root@debian:~# cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF PBKDF: argon2i Time cost: 4 Memory: 582804 Threads: 2 root@debian:~# cryptsetup luksConvertKey /dev/vda5 <<<test root@debian:~# cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF PBKDF: argon2i Time cost: 4 Memory: 1015216 Threads: 2 Bullseye (debian-11.6.0-amd64-netinst.iso, text install), 4096M RAM: root@debian:~# cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF PBKDF: argon2i Time cost: 4 Memory: 518981 Threads: 2 root@debian:~# cryptsetup luksConvertKey /dev/vda5 <<<test root@debian:~# cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF PBKDF: argon2i Time cost: 4 Memory: 948373 Threads: 2 Bookworm (debian-bookworm-DI-rc1-amd64-netinst.iso, text install), 1024M RAM: root@debian:~# cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF PBKDF: argon2id Time cost: 5 Memory: 489820 Threads: 2 root@debian:~# cryptsetup luksConvertKey /dev/vda5 <<<test root@debian:~# cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF PBKDF: argon2id Time cost: 8 Memory: 490598 Threads: 2 Bookworm (debian-bookworm-DI-rc1-amd64-netinst.iso, text install), 2048M RAM: root@debian:~# cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF PBKDF: argon2id Time cost: 4 Memory: 553835 Threads: 2 root@debian:~# cryptsetup luksConvertKey /dev/vda5 <<<test root@debian:~# cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF PBKDF: argon2id Time cost: 4 Memory: 1005926 Threads: 2 Bookworm (debian-bookworm-DI-rc1-amd64-netinst.iso, text install), 4096M RAM: root@debian:~# cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF PBKDF: argon2id Time cost: 4 Memory: 546642 Threads: 2 root@debian:~# cryptsetup luksConvertKey /dev/vda5 <<<test root@debian:~# cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF PBKDF: argon2id Time cost: 4 Memory: 1048576 Threads: 2 Bookworm (debian-bookworm-DI-rc1-amd64-netinst.iso + cryptsetup 2:2.6.1-4~deb12u1, graphical install), 1024M RAM: root@debian:~# cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF PBKDF: argon2id Time cost: 10 Memory: 223780 Threads: 2 root@debian:~# cryptsetup luksConvertKey /dev/vda5 <<<test root@debian:~# cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF PBKDF: argon2id Time cost: 8 Memory: 490598 Threads: 2 Bookworm (debian-bookworm-DI-rc1-amd64-netinst.iso + cryptsetup 2:2.6.1-4~deb12u1, text install), 1024M RAM: root@debian:~# cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF PBKDF: argon2id Time cost: 8 Memory: 294302 Threads: 2 root@debian:~# cryptsetup luksConvertKey /dev/vda5 <<<test root@debian:~# cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF PBKDF: argon2id Time cost: 8 Memory: 490598 Threads: 2 Bookworm (debian-bookworm-DI-rc1-amd64-netinst.iso + cryptsetup 2:2.6.1-4~deb12u1, text install), 2048M RAM: root@debian:~# cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF PBKDF: argon2id Time cost: 4 Memory: 590553 Threads: 2 root@debian:~# cryptsetup luksConvertKey /dev/vda5 <<<test root@debian:~# cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF PBKDF: argon2id Time cost: 4 Memory: 1005926 Threads: 2 Bookworm (debian-bookworm-DI-rc1-amd64-netinst.iso + cryptsetup 2:2.6.1-4~deb12u1, text install), 4096M RAM: root@debian:~# cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF PBKDF: argon2id Time cost: 4 Memory: 613826 Threads: 2 root@debian:~# cryptsetup luksConvertKey /dev/vda5 <<<test root@debian:~# cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF PBKDF: argon2id Time cost: 4 Memory: 1048576 Threads: 2 Bottom line: * The upstream patches in the patch-queue (the 2 backported earlier from upstream MR !490 plus the new other two from upstream MR !498) only affect systems with <2G RAM (i.e., those where half the amount of physical memory is lower than DEFAULT_LUKS2_MEMORY_KB). And only those without swap. On such systems the memory cost is set to a lower value at the expense of a higher time cost, which is the intended behavior; it appear to leave enough head-room for the graphical installer to succeed with 1G RAM, so I believe the errata can be removed if the changes makes it to bookworm. * I was surprised to see the memory cost settle at ~550-600M on systems with a decent amount of RAM in d-i. Would have expected to see 1G here just like after running `cryptsetup luksConvertKey` in the normal system. I get a similarily low memory cost after dropping to a rescue shell early in d-i and running `luksFormat` manually: ~ # grep -c ^processor /proc/cpuinfo 6 ~ # free total used free shared buff/cache available Mem: 6062584 107888 5647804 260000 306892 5543168 Swap: 0 0 0 ~ # echo test | cryptsetup luksFormat --debug --batch-mode /dev/sda […] # Running argon2id() benchmark. # PBKDF benchmark: memory cost = 65536, iterations = 4, threads = 4 (took 229 ms) # PBKDF benchmark: memory cost = 71545, iterations = 4, threads = 4 (took 242 ms) # PBKDF benchmark: memory cost = 73910, iterations = 4, threads = 4 (took 249 ms) # PBKDF benchmark: memory cost = 74206, iterations = 4, threads = 4 (took 246 ms) # PBKDF benchmark: memory cost = 75412, iterations = 4, threads = 4 (took 254 ms) # PBKDF benchmark: memory cost = 593795, iterations = 4, threads = 4 (took 3527 ms) # PBKDF benchmark: memory cost = 336713, iterations = 4, threads = 4 (took 1196 ms) # PBKDF benchmark: memory cost = 563065, iterations = 4, threads = 4 (took 2035 ms) # Benchmark returns argon2id() 4 iterations, 563065 memory, 4 threads (for 512-bits key). […] I think what happens here is that compared to the final system d-i is a bit crippled so the 2s threshold is reached earlier in the benchmark. For comparison, running the benchmark in the initramfs shell of the final system (after installation, but also without swap): (initramfs) free total used free shared buff/cache available Mem: 6064140 66752 5797144 56 200244 5675728 Swap: 0 0 0 (initramfs) echo test | cryptsetup luksConvertKey --debug --batch-mode /dev/sda5 […] # Running argon2id() benchmark. # PBKDF benchmark: memory cost = 65536, iterations = 4, threads = 4 (took 94 ms) # PBKDF benchmark: memory cost = 174297, iterations = 4, threads = 4 (took 239 ms) # PBKDF benchmark: memory cost = 182319, iterations = 4, threads = 4 (took 242 ms) # PBKDF benchmark: memory cost = 188346, iterations = 4, threads = 4 (took 243 ms) # PBKDF benchmark: memory cost = 193771, iterations = 4, threads = 4 (took 232 ms) # PBKDF benchmark: memory cost = 208804, iterations = 4, threads = 4 (took 274 ms) # PBKDF benchmark: memory cost = 1048576, iterations = 5, threads = 4 (took 1721 ms) # Benchmark returns argon2id() 5 iterations, 1048576 memory, 4 threads (for 512-bits key). […] And now in the final system fully booted (same result as in initramfs): root@debian:~# free -h total used free shared buff/cache available Mem: 5.8Gi 270Mi 5.6Gi 476Ki 78Mi 5.5Gi Swap: 975Mi 0B 975Mi root@debian:~# cryptsetup luksConvertKey --debug --batch-mode /dev/sda5 <<<test […] # Running argon2id() benchmark. # PBKDF benchmark: memory cost = 65536, iterations = 4, threads = 4 (took 93 ms) # PBKDF benchmark: memory cost = 176172, iterations = 4, threads = 4 (took 248 ms) # PBKDF benchmark: memory cost = 177592, iterations = 4, threads = 4 (took 242 ms) # PBKDF benchmark: memory cost = 183462, iterations = 4, threads = 4 (took 226 ms) # PBKDF benchmark: memory cost = 202944, iterations = 4, threads = 4 (took 274 ms) # PBKDF benchmark: memory cost = 1048576, iterations = 5, threads = 4 (took 1795 ms) # Benchmark returns argon2id() 5 iterations, 1048576 memory, 4 threads (for 512-bits key). […] Never noticed that before, but that's not a regression since buster and bullseye both have the same behavior. (At least in my test VMs; didn't compare on real hardware.) Cheers
Guilhem Moulin <guilhem@debian.org> (2023-04-21): \o/ Looks very good to me, thanks. […] Summing up some out-of-band brainstorming about what “a bit crippled” means, it might just be libargon2-1-udeb's being built without pthread support: https://salsa.debian.org/debian/argon2/-/commit/31225912349933993e49f5007e97630b20465c32 Based on Samuel's feedback on IRC, what used to be true in 2019 might no longer be today; we might try and enable pthread support, and see whether that makes a difference. As noted in https://mjg59.dreamwidth.org/66429.html what happens during installation might not get changed at all during the life of a given system, so if we can somewhat easily improve what happens during installation… :) Cheers,
That seems correct! I just rebuilt argon2 0~20190702+dfsg-2 for bookworm without the NO_THREADS=1 and injected the udeb in the .ISO. The PBKDF benchmark result is as one would expect on a system with 4G RAM: ~ # echo test | cryptsetup luksFormat --debug --batch-mode /dev/vda […] # Running argon2id() benchmark. # PBKDF benchmark: memory cost = 65536, iterations = 4, threads = 2 (took 209 ms) # PBKDF benchmark: memory cost = 78392, iterations = 4, threads = 2 (took 156 ms) # PBKDF benchmark: memory cost = 125628, iterations = 4, threads = 2 (took 242 ms) # PBKDF benchmark: memory cost = 129780, iterations = 4, threads = 2 (took 242 ms) # PBKDF benchmark: memory cost = 134070, iterations = 4, threads = 2 (took 243 ms) # PBKDF benchmark: memory cost = 137932, iterations = 4, threads = 2 (took 253 ms) # Benchmark returns argon2id() 4 iterations, 1048576 memory, 2 threads (for 512-bits key). […] Ack, and given the diff that's probably a worthwhile thing to have in bookworm :-)
libargon2-1-udeb bug filed at #1034696. For the sake of completion, here are updated benchmark results after injecting src:argon2=0~20171227-0.3+deb12u1 (debdiff attached to the aforementioned bug) into the ISO: Bookworm (debian-bookworm-DI-rc1-amd64-netinst.iso + cryptsetup 2:2.6.1-4~deb12u1 + argon2 0~20171227-0.3+deb12u1, graphical install), 1024M RAM: root@debian:~# cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF PBKDF: argon2id Time cost: 19 Memory: 219508 Threads: 2 root@debian:~# cryptsetup luksConvertKey /dev/vda5 <<<test root@debian:~# cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF PBKDF: argon2id Time cost: 8 Memory: 490598 Threads: 2 ## higher memory cost expected: graphical install without swap vs. ## minimal headless target system Bookworm (debian-bookworm-DI-rc1-amd64-netinst.iso + cryptsetup 2:2.6.1-4~deb12u1 + argon2 0~20171227-0.3+deb12u1, text install), 1024M RAM: root@debian:~# cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF PBKDF: argon2id Time cost: 14 Memory: 293158 Threads: 2 root@debian:~# cryptsetup luksConvertKey /dev/vda5 <<<test root@debian:~# cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF PBKDF: argon2id Time cost: 8 Memory: 490598 Threads: 2 ## higher memory cost expected: install without swap vs. minimal headless ## target system Bookworm (debian-bookworm-DI-rc1-amd64-netinst.iso + cryptsetup 2:2.6.1-4~deb12u1 + argon2 0~20171227-0.3+deb12u1, text install), 2048M RAM: root@debian:~# cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF PBKDF: argon2id Time cost: 5 Memory: 801560 Threads: 2 root@debian:~# cryptsetup luksConvertKey /dev/vda5 <<<test root@debian:~# cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF PBKDF: argon2id Time cost: 4 Memory: 1005926 Threads: 2 Bookworm (debian-bookworm-DI-rc1-amd64-netinst.iso + cryptsetup 2:2.6.1-4~deb12u1 + argon2 0~20171227-0.3+deb12u1, text install), 4096M RAM: root@debian:~# cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF PBKDF: argon2id Time cost: 4 Memory: 1048576 Threads: 2 root@debian:~# cryptsetup luksConvertKey /dev/vda5 <<<test root@debian:~# cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF PBKDF: argon2id Time cost: 4 Memory: 1048576 Threads: 2 As one can see the benchmark results are now in line with expectations, both in and outside d-i :-) (For the 2G case setting the memory cost to 1G would actually be viable, but it's a bit lower since the limit is half the amount of available memory rather than “if there is more than 1G RAM available then set the max cost to 1G, otherwise set it to $FREE_MEM/2”.)