Re: cryptsetup - No key available with passphrase

Hi Michael,

thank you very much for the ramfs idea and your input.
I would have done this next (and I still might) but it could be that I
found the issue.

I'm running more detailed tests now.
This Github issue[1] made me run a memtest and that did show errors,
but those errors went away as soon as I enabled the AMD EXPO mode to
overclock the memory.
It's the next rabbit hole I'm looking at now. But using that
overclocked memory I am able to run all the commands from this thread
successfully (at least when I tried it just now, I'll reset everything
and will try again).
Next test was disabling the EXPO mode again and it still worked and
memtest shows no errors. That is weird.
I _did_ update the BIOS yesterday. All PC components are brand new....
it worked before the BIOS update, the problems started after the BIOS
update but because there were a few hours in between I didn't make the
connection until now.

I have to admit: I did not think about memory as being a potential
problem but it makes sense that cryptsetup/LUKS/dm-crypt need a lot of
memory for some of the operations.

I'll update here should I find more.
For now I hope I have a stable configuration.

Thank you both for your help and sorry for raising this unrelated
issue - cryptsetup was probably just so early in the installation
phase, other steps would probably have failed later as well.
I can't think of anything cryptsetup could  have done to prevent this.

Cheers,
Lars


[1] <https://github.com/systemd/systemd/issues/14927#issuecomment-636415564>


On Thu, Mar 2, 2023 at 10:55 PM Michael Kjörling <[email protected]> wrote:
>
> On 2 Mar 2023 21:34 +0100, from [email protected] (Lars Francke):
> > I honestly don't understand what the problem could be. All of this did
> > work last week and it did work _once_ earlier today for some reason.
> > I checked smartctl to make sure that the hard drive is not reporting
> > any errors and it doesn't
>
> SMART data unfortunately is not always conclusive; particularly, it's
> not always conclusive in indicating the _absence_ of a problem. Plain
> and simple, storage devices _lie_, some more than others.
>
> I would try again, but this time creating the LUKS container using a
> file in a ramfs (not tmpfs, which is allowed to be swapped out) as
> backing store, possibly mapped to a loopback device. Doing so will
> eliminate persistent storage from the equation.
>
> If that works, then my suspicion would be on the drive itself.
>
> If that doesn't work either, then there's likely something problematic
> about the software stack, at which point exact versions of everything
> becomes interesting. Kernel, cryptsetup, libcryptsetup, ...
>
> --
> Michael Kjörling                     🔗 https://michael.kjorling.se
> “Remember when, on the Internet, nobody cared that you were a dog?”
>
>