1

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 ?
7
  • Output in comments above is unreadable. Add these to your question using code blocks
    – Dirk
    May 1 at 15:20
  • Welcome. "Add these to your question" here means use the 'Edit' link under the question to edit in information (done). Please take the tour to understand better how the site works.
    – goldilocks
    May 1 at 20:32
  • "I'm positive the card is fine because I flashed it with a brand new Rpi image and that works too" -> That does not really positively prove the card is fine. It would have been good if you had included more details about the procedure you tried, particularly what "did not work" means. Did the fsck throw errors, or did it not but then on reboot the problem was the same? If it threw errors, what were they?
    – goldilocks
    May 1 at 20:52
  • "I formatted the card and reflashed it with with my .img file" -> This is a superstitious exercise (albeit common enough, it seems). The image that's written to the SD card completely overwrites any formatting that was on the card. Ie., it does not matter at all what was on the card before you wrote an image to it, and formatting it or otherwise modifying the content first makes no difference.
    – goldilocks
    May 1 at 20:55
  • My apologies if my question wasn't clear enough. I'm still not convinced the card is not fine. I flashed it (using dd) with a brand new raspbian image and it booted and I logged it so it's not a hardware problem I assume. May 3 at 9:00

1 Answer 1

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!

SD-USB-Adapter

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. 
  1. 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

  2. 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.

4
  • Since I can mount the sdcard on my laptop is there any diagnostic I can still do? The solution looks pretty straightforward to me reflashing it like I did and copy settings and files back but I'd like to give it a try before that process. Thank you in advance. May 3 at 9:23
  • Thanks for the suggestion of image-backup, great tool. May 3 at 10:40
  • @ThomasUkenagashi: "is there any diagnostic I can still do?" Yes - but first, I would like you to read this short piece from the Help section, and do whatever you think best.
    – Seamus
    May 4 at 0:09
  • @ThomasUkenagashi: I've edited my answer in an effort to address your Q re diagnostics.
    – Seamus
    May 4 at 1:56

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.