I haven’t look at cryptsetup. What is the purpose? Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________ From: Cyril Brulebois <k...@debian.org> Sent: Thursday, February 16, 2023 14:21 To: 1028...@bugs.debian.org <1028...@bugs.debian.org> Cc: cryptse...@packages.debian.org <cryptse...@packages.debian.org> Subject: Bug#1028250: debian-installer: broken cryptsetup support cc += cryptsetup maintainers (hi, long time no see!) Cyril Brulebois <k...@debian.org> (2023-01-09): > Cyril Brulebois <k...@debian.org> (2023-01-08): > > 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. > > 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. 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 (k...@debian.org) <https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
