Raspberry Pi 3 Model B won't boot but SD Card and board are fine

Question

my Rpi has worked fine for a while but recently it stopped booting, only the red led is on while the green ACT one is not. I'm sure board is fine because I put another SD card from another Rpi and it works just fine. I'm positive the card is fine because I flashed it with a brand new Rpi image and that works too. At this point I don't want to loose all my settings so I connected the card to my laptop and created an image using dd. I formatted the card and reflashed it with with my .img file but without success. I did a fsck and found a bad magic number problem a tried a procedure similare to this https://www.linode.com/community/questions/20599/how-do-i-fix-a-bad-magic-number-in-super-block-error but did not work either.

Is there any other way I could spot where the problem lies?

From fdisk:

Device     Boot  Start      End  Sectors  Size Id Type
/dev/sdb1         8192   137215   129024   63M  c W95 FAT32 (LBA)
/dev/sdb2       137216 30318591 30181376 14,4G 83 Linux

Output of fsck

fsck from util-linux 2.31.1 e2fsck 1.44.1 (24-Mar-2018) fsck.ext2: No medium found while trying to open /dev/sdb

The superblock could not be read or does not describe a valid ext2/ext3/ext4 filesystem. If the device is valid and it really contains an ext2/ext3/ext4 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock: e2fsck -b 8193 or e2fsck -b 32768

Here's the output of dosfsck on the boot partition:

sudo dosfsck /dev/sdb1 fsck.fat 4.1 (2017-01-24) 0x25: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.

1. Remove dirty bit
2. No action ?

Answer 1

I read through your question rather quickly, but from my reading I'd have to guess that there was a problem with your SD card, and re-flashing it has corrected whatever the problem was.

I don't know how to fix your magic number fault. As a guess, a file on your /boot drive was deleted or corrupted. Is the file /boot/bootcode.bin still on the SD card? (Ref boot sequence). You may be able to compare the .img file you created with your current working image file, but that's a guess; this search may provide other clues.

I'm only answering here in an effort to offer an idea for data recovery, and to suggest you add a couple of things to your lessons learned from this episode.

Lessons to be learned:

1. Always have a good, reliable backup before disaster strikes. Here's my preferred backup solution FWIW.

2. Don't use dd - there are more reliable solutions, and there are faster solutions that don't copy gigabytes of unused space on your SD card.

3. Always have a spare SD card.

Data recovery:

You may be able to recover most or all of your files from the un-bootable SD card - or its dd-created image. This assumes your dd-created image is usable, you can write it to a USB card, and can mount it from your now-running system. If you're unfamiliar, this overview may help:

$ sudo mkdir /mnt/recovery/boot
$ sudo mkdir /mnt/recovery/root 
# you can manually `mount` the two filesystems, or add them to `/etc/fstab`

# in /etc/fstab: 

# mount / & /boot partitions for SD card from another system - a conventional fstab config:
# NOTE: these UUIDs for RPi 3B+ buster uSD card
UUID=592B-C92C /mnt/sdpi/boot vfat ro,user,nofail 0 0
UUID=706944a6-7d0f-4a45-9f8c-7fb07375e9f7 /mnt/sdpi/root ext4 ro,user,nofail 0 0

With all of that done, you can now mount your old SD card via USB:

$ sudo mount -av

I'd like to take this opportunity to reinforce the utility of having spare SD card(s). Instead of having to write your dd-copied-image to a thumb drive, you could use something like this, and simply pop it in your RPi's USB drive - so much easier!

Once mounted, you'll be able to assess what you've got to work with. If it looks good, you can cp or rsync your files from the old to the new SD card.

Addendum:

The OP has asked about diagnostics on the SD card. I'm not sure diagnostics will be of much use under the circumstances, but everyone should be aware of what is available. Many of the details are covered in other Q&A here, so I'll try to link those & summarize briefly:

1. Keeping up with fsck: By default, fsck is run each time your system boots, and a log entry is made. This answer has some information that may help you track what's been going on. For a live system the last item in this answer will probably yield the most information: journalctl -u systemd-fsck*. However - if you can mount & access the filesystem on your failed/corrupted SD card, you will have to review the "native" logs at var/log/syslog (zgrep is your friend for the compressed logs).

2. This Q&A may be more interesting and informative. In particular the scathing comments from goldilocks < :) LOL > finally registered on me wrt filesystem vs media/device. After all of the dust settled, one possibly predictive log entry to watch for is this: print_req_error (ref OP's Q). One way to get at that is this command: journalctl -u print_req_error | less. On my RPi 4's SanDisk SD card (the oldest I have), this is the output I see:

-- Logs begin at Thu 2019-02-14 04:11:59 CST, end at Tue 2022-05-03 20:10:43 CDT. -- -- No entries --

     Consequently, I'm feeling good so far. 

3. If you want to run fsck on your failed/corrupted SD card, you may also do that, but I am in the camp that believes that is largely a waste of time and effort. Here's a step-by-step for running fsck

4. I'll close with this Q&A on the /lost+found folder from the U&L SE. I suspect this is not relevant to your case because on RPi, the files being used to boot are not in your root ext4 filesystem, but rather in your FAT32 /boot filesystem - which has no /lost+found folder.