[arch-general] Heads up: After system update, LUKS fails with certain BIOS versions
Hello everyone, My desktop machine didn't shut down cleanly yesterday after I did system upgrades, hanging at closing my dmcrypt devices. I power-cycled after 10 minutes, and today it wouldn't boot, again hanging at the [encrypt]-hook. I tried cryptsetup open, luksOpen, luksDump and isLuks from a fresh 2020-05-01 archiso, all with --debug, with multiple encrypted internal drives, all hanging after printing the header checksum. So I couldn't access any of my drives anymore. dd if=/dev/sdxy of=/dev/null worked fine for all of them, though. I already thought my header got corrupted somehow and my data was lost, until I remembered I had some output in dmesg for several months now: `rdrand gives funky smelling output`. I gave it a shot and updated my BIOS, and hooray, my system booted up just fine. Back in my system, I noticed cryptsetup 2.3.1-1 -> 2.3.1-3 and linux 5.6.7 -> 5.6.8 in yesterday's update. So probably something has changed in that update that causes an issue connected with the old BIOS version. This was definitely not the solution I expected, and therefore I want to share it, as others might be affected as well. My Mainboard is an Asus Prime X470-Pro, CPU is AMD Ryzen 7-3900x. Updating to BIOS v5406 fixed the issue. So if you get similar issues, don't worry, your data might not be lost :) Kind regards, LuKaRo
Am 01.05.20 um 16:56 schrieb LuKaRo:
[...] I tried cryptsetup open, luksOpen, luksDump and isLuks ..., all hanging after printing the header checksum.
May I ask if your headers are --type=luks or luks2?
On 01.05.20 17:32, Markus Schaaf via arch-general wrote:
May I ask if your headers are --type=luks or luks2? Of course. `cryptsetup luksDump` says: Version 2, Epoch 5, all Keyslots are luks2 as well.
participants (2)
-
LuKaRo
-
Markus Schaaf