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

Attachment: signature.asc
Description: PGP signature

Reply via email to