0

Wanting to reinstall the Raspberry Pi OS on my RaspberryPi5 (64-bit quad-core Cortex-A76 8GB LPDDR4X SDRAM),

I did the following:

dd if=/dev/zero of=/dev/mmcblk0 bs=1M status=progress 

Then I created a new GPT partition table with GPT and added a new partition with n Pressed w to save changes and proceded to make filesystem:

mkfs.ext4 /dev/mmcblk0p1

Then I flashed My SD card with rpi-imager.

After placing the sd card in raspberry pi and powering it on I get a welcome screen with a picture, Welcome to Raspberry Pi Os, at then

BusyBox v*** (Debian  *** ) built-in shell (ash)
Enter 'help' for a list of built-in commands.
(initramfs)

I don't remember the version numbers, hence ***. At first I thought that perhaps the sd card is corrupted but I have run badblocks -w /dev/mmcblk0 and got no output. I noticed that rpi-imager created more partitions than I originally created as evidenced by lsblk -t:

NAME        ALIGNMENT MIN-IO OPT-IO PHY-SEC LOG-SEC ROTA SCHED RQ-SIZE  RA WSAME
mmcblk0             0    512      0     512     512    0 bfq       128 128    0B
├─mmcblk0p1         0    512      0     512     512    0 bfq       128 128    0B
└─mmcblk0p2         0    512      0     512     512    0 bfq       128 128    0B

What is happening here? I have tried using just dd instead of rpi-imager but that has not solved the issue.

5
  • 2
    What was the intended purpose of the dd operation, and creating the new partition table before flashing your SD card? RPi imager will erase everything in the process of doing what it does. I also wonder about lsblk -t... what's your intent in exploring "block-device topology" w/ the -t option... may try -f instead? Finally , try e2fsck -c instead of badblocks.
    – Seamus
    Commented May 3 at 16:41
  • @Seamus I wanted to make sure that one cannot recover any of my private keys, hence the dd operation - am not familiar with rpi-imager and wasn't sure if it would do that for me ... Apologies for the verobosity of lsblk -t - there is no excuse for it.
    – John Smith
    Commented May 3 at 17:32
  • 2
    Ditto most of what Seamus said; WRT badblocks vs e2fsck, the first one checks the hardware integrity at a low level (and I am not sure that it is actually useful with SD cards). The latter checks the integrity of a filesystem. Point being, badblocks could report everything is fine despite the fact that the fs is corrupt or even complete garbage; it does not know anything about filesystems. If this happened with a fresh install, I would just flash the card again. If it happens again, try a different (preferrably different brand) card.
    – goldilocks
    Commented May 3 at 18:07
  • @goldilocks I solved the issue with e2fsck -c /dev/mmcblk0p2 by agreeing to optimized when prompted. I modified the question including the output of e2fsck in response to your worthy comment.
    – John Smith
    Commented Jun 3 at 16:22
  • 1
    If you have time please turn that into an answer (you should be able to accept your own answer after 24 hours if not right away, although you get no points for that).
    – goldilocks
    Commented Jun 4 at 13:01

2 Answers 2

1

Redownload a fresh copy of the OS image, then rewrite it to the card.

All the partitioning/formatting was a waste of time that just will cause the card to wear out a little sooner: writing an image to the card overwrites everything on it anyway.

1

Following the advice of @goldilocks I solved the issue with e2fsck -c /dev/mmcblk0p2 by agreeing to optimize when prompted:

Checking for bad blocks (read-only test):   0.00% done, 0:00 elapsed. (0/0/0 errdone                                                 
rootfs: Updating bad block inode.
Pass 1: Checking inodes, blocks, and sizes
Inode 1403 extent tree (at level 2) could be narrower.  Optimise<y>? yes
Inode 58312 extent tree (at level 2) could be narrower.  Optimise<y>? yes
Inode 58316 extent tree (at level 1) could be narrower.  Optimise<y>? yes
Inode 58383 extent tree (at level 1) could be narrower.  Optimise<y>? yes
Inode 58385 extent tree (at level 1) could be narrower.  Optimise<y>? yes
Inode 58387 extent tree (at level 2) could be narrower.  Optimise<y>? yes
Inode 58389 extent tree (at level 2) could be narrower.  Optimise<y>? yes
Inode 58392 extent tree (at level 2) could be narrower.  Optimise<y>? yes
Inode 58927 extent tree (at level 1) could be narrower.  Optimise<y>? yes
Pass 1E: Optimising extent trees
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
rootfs: ***** FILESYSTEM WAS MODIFIED *****
rootfs: 60731/136000 files (0.2% non-contiguous), 432253/543744 blocks

Only /dev/mmcblk0p2 and not /dev/mmcblk0p1 could be given as the argument to e2fsck as it does not work with partitions that are not of ext* type. All this I've done after flushing the card with rpi-imager and it solved my issue.

2
  • 1
    Worth noting WRT -c: Whether or not this accomplishes anything w/ SD cards is subject to debate, but in any case, the "Updating of the bad block inode" certainly won't do anything good and may create a minor(?) problem if it does find something, because the block addresses provided by the SD card, unlike on traditional disks, are virtual and dynamic, meaning while block 123 will always be block 123 to the filesystem, the actual physical block it occupies is subject to arbitrary change without the OS (and, hence, the filesystem) knowing or needing to know...
    – goldilocks
    Commented Jun 6 at 15:01
  • 1
    ...That's is the nature of the medium. So if that block is listed as "bad", it was only so when fsck ran -- although part of the reason using -c/badblocks is likely mostly pointless in the first place is that SD cards manage this themselves; if those tools do find such the card is likely trash/worn out, the issue is not just a few unusable (fake) addresses. Note the fixes done above do not have anything to do with -c and would have been done without it.
    – goldilocks
    Commented Jun 6 at 15:01

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.