[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1028250: debian-installer: broken cryptsetup support



I haven’t look at cryptsetup.  What is the purpose?
 

From: Cyril Brulebois <kibi@debian.org>
Sent: Thursday, February 16, 2023 14:21
To: 1028250@bugs.debian.org <1028250@bugs.debian.org>
Cc: cryptsetup@packages.debian.org <cryptsetup@packages.debian.org>
Subject: Bug#1028250: debian-installer: broken cryptsetup support
 
cc += cryptsetup maintainers (hi, long time no see!)

Cyril Brulebois <kibi@debian.org> (2023-01-09):
> Cyril Brulebois <kibi@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 (kibi@debian.org) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

Reply to: