0

My ubuntu 21 hanged and after rebooting, it was not able to boot up. The current message is this one. fsck error Tried to use fsck with -y and -f and none of them fixes the partition. It happened with the raspberry pi 4 100.

Improve this question
1
  • Tried to use fsck with -y and -f - how did you do this on a system that doesn't even boot?
    – Bravo
    Commented Jul 28, 2021 at 7:02

1 Answer 1

Reset to default
3

In general, this is an indication of a dying sd card.

What happens is, that fsck tries to recover the journal, tries to write the superblock, but then finds that the superblock is not updated.

If you have important work on this Pi, you should dd the partition to a hard drive and try some forensics on it. The partition table seems OK, so there seems no need to dd the whole card.

It may be, that the card will boot after being let alone for a few hours, but even if that is the case, you should replace the card.

You may also have some luck with e2fsck -fccky, which means:

   -f    Force checking even if the file system seems clean.

   -c    This option causes e2fsck to use badblocks(8) program to do
         a read-only scan of the device in order to find any bad blocks.
         If any bad blocks are found, they are added to the bad block
         inode to prevent them from being allocated to a file or direc‐
         tory.  If this option is specified twice, then the bad block scan
         will be done using a non-destructive read-write test.

   -k    When combined with the -c option, any existing bad blocks in the
         bad blocks list are preserved, and any new bad blocks found by
         running badblocks(8) will be added to the existing bad blocks
         list.

   -y    Assume an answer of `yes' to all questions; allows e2fsck to be
         used non-interactively. This option may not be specified at the
         same time as the -n or -p options.

But I would buy a new sd card.

Improve this answer
4
  • I would not use -c on an SD card -- it can take a long time, and it's ineffective because SD card addresses are virtual and dynamic, meaning "block 1234" will not always refer to the same physical block; unlike old spinning disks, the physical layout is completely opaque to the OS even if various tools don't recognize this. Fsck can still fix errors in place though. Also note: If the card is new (hence should not be "dying"), they can be defective such that they die young.
    – goldilocks ♦
    Commented Jul 28, 2021 at 11:44
  • @goldilocks If you do a non-destructive read-write test, and if there is sufficient spare on the sd-card, the sd card might re-allocate the bad blocks (no guarantee!). The -cc works for the sd-card, sometimes. I agree that it will take a long time. I also agree that a single -c is useless.
    – Ljm Dullaart
    Commented Jul 28, 2021 at 13:42
  • Lemme try this again: The operating system does not have access to actual physical block addresses on the SD card. But badblocks requires such in order to work to re-allocate or blacklist addresses. The SD card controller (an MC in the card) maps physical addresses to virtual ones, again dynamically, meaning they are subject to change and the OS has no insight into this.
    – goldilocks ♦
    Commented Jul 29, 2021 at 14:24
  • Comments are not for extended discussion; this conversation has been moved to chat.
    – goldilocks ♦
    Commented Jul 29, 2021 at 14:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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