I was running my system (compiling the 4.12 kernel) when it halted an hour ago. The screen was entirely grey, the keyboard wouldn't respond. Music kept playing for about 1 minute. After waiting a little more, I had no choice but to do a hard reset. Now it won't boot.

My root partition is F2FS on top of LUKS. After typing the LUKS password, the following error message appears:

[f2fs_do_mount:] Can't find valid checkpoint

I booted the Arch Linux ISO image and did:

cryptsetup open /dev/sda3 csystem
fsck.f2fs /dev/mapper/csystem

FSCK fails with the same message "Can't find valid checkpoint".

Tried fsck with -a and -f switches, still didn't work.

Am I hopelessly screwed?

  • You may be able to use photorec to recover some data on dev/mapper/csystem - although if you have a backup, restoring from that would be a better way to go. (This is not an answer because it does not address the issue in f2fs - which I know very little about)
    – davidgo
    Jul 4 '17 at 4:29
  • @davidgo Thanks for the recommendation, I'll try it
    – Marc.2377
    Jul 4 '17 at 23:28
  • @alecxs I followed that thread but am failing to see an useful relation. Got any comments to add?
    – Marc.2377
    Mar 15 at 20:22
  • Well, that's totally unrelated to the issue at hand, buuuut, let it be, I guess.
    – Marc.2377
    Mar 16 at 0:45

I contacted Jaegeuk Kim, lead developer and F2FS maintainer, both personally and via the mailing list. I eventually provided SSH access to a VM containing an image of the failed F2FS partition (after decryption). He took some time to analyse it but the result was inconclusive. The checkpoint area hexdump looked like encrypted data, but we were positive the image was decrypted (because I could recover files with photorec and also the strings command showed a lot of useful stuff). Ultimately, the superblock area also evidenced the image was decrypted, but the checkpoint was garbage.

One of my last messages was:

If these are in fact encrypted data, the only explanation I can think of is a major malfunction in the dm-crypt layer in the kernel, when the system crashed due to a (probably) hardware bug.


Am I hopelessly screwed?

Unfortunately, yes.

Mr. Kim told me this was the first instance of this kind he had run across, and to ping him again if it would happen a second time. But I decided to play it safer and have been using EXT4 ever since. (This was on August 2017.)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.