MrOaiki
Posts: 33
Joined: Fri Jun 28, 2013 12:21 am

Bad blocks, yet working

Wed Jul 24, 2013 4:43 pm

When I make a copy of my SD card with dd, it works although it gives me an error when I copy the disk image to another SD card. Both cards work fine. I've been trying to mount the SD card on my Laptop (Linux), but it gives me an error saying "Bad magic number in superblock".

Should I care, when my Raspberry is running as it should? Could this result in problems later on?

sdjf
Posts: 1397
Joined: Fri Mar 16, 2012 5:20 am
Location: California

Re: Bad blocks, yet working

Wed Jul 24, 2013 5:49 pm

Bad magic number in a superblock is not the same thing as bad data blocks. If the file system was created properly, there will be backup superblocks that make up for that.

Which partition is this in, the boot partition or the root file system?

There is a command that will show how many backup superblocks there are in Linux file systems, but I do not remember the name of the command.
FORUM TIP: To view someone's posting history, sign in, click on their user name, then on "Search User's Posts." || Running ArchLinuxArm on Model 2B and 512MB Model B

MrOaiki
Posts: 33
Joined: Fri Jun 28, 2013 12:21 am

Re: Bad blocks, yet working

Wed Jul 24, 2013 5:53 pm

The root, it seems. Would this explain why I can see the boot partition when I put the SD card into my Linux laptop, but when I try to mount the root file system I get an error and can't mount it.

RediJedi
Posts: 45
Joined: Sun Apr 21, 2013 9:56 am

Re: Bad blocks, yet working

Wed Jul 24, 2013 6:20 pm

Hi, I can't say if it will be a problem to carry on using it in the rpi or not, I have had similar problems dd'ing partitions around, so to fix it you could try the following from a linux box, i'm guessing this is a ext4 partition if it isn't post back what it is, and backup your SDcard before you try this just incase.

1, insert your sdcard into the linux box and enter the following.

Code: Select all

 sudo fdisk -l
This will list partitions on your drives, make sure you check this if you plan to follow the rest of this post.

You should have similar to the following output.

Code: Select all

Disk /dev/sda: 250.1 GB, 250059350016 bytes, 488397168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: gpt


#         Start          End    Size  Type            Name
 1         2048     31459327     15G  Linux filesyste 
 2     31459328     73402367     20G  Linux filesyste 
 3           34         2047   1007K  BIOS boot parti 

Disk /dev/sdb: 7948 MB, 7948206080 bytes, 15523840 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x0004f23a

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *        2048      186367       92160    c  W95 FAT32 (LBA)
/dev/sdb2          186368     3667967     1740800   83  Linux
The output shows that my HDD is /dev/sda and the next attached device is my SDcard /dev/sdb.
/dev/sdb has 2 partitions and we want to check the superblocks on the linux partition which is /dev/sdb2.

2, To check the filesystem and find the superblock error enter the following command, replacing xxx with your partition name, in my case /sdb2.

sudo fsck.ext4 -v /dev/xxx

If errors are found and you want to continue to fix them you will need to know where the superblock backups are stored,

3, enter the following command to find them, replacing xxx with your partition name you have just used above.

sudo mke2fs -n /dev/xxx

The superblock backups should be at the bottom of the output.

Code: Select all

    mke2fs 1.42.8 (20-Jun-2013)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
108864 inodes, 435200 blocks
21760 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=448790528
14 block groups
32768 blocks per group, 32768 fragments per group
7776 inodes per group
Superblock backups stored on blocks: 
	32768, 98304, 163840, 229376, 294912
At the bottom of the output are the superblock backups

4, Enter the following command to restore the first superblock from the backup, replacing the 00000 with the first block number(32768 in the above example), and replacing xxx with the the partition number you used in the previous commands.

sudo e2fsck -b 00000 /dev/xxx

That should fix the superblock from the backup, you can try ejecting the card and inserting it again and if the problem still occurs try the above command again but use the second superblock backup and see if that works.

MrOaiki
Posts: 33
Joined: Fri Jun 28, 2013 12:21 am

Re: Bad blocks, yet working

Thu Jul 25, 2013 8:36 am

Thanks. Worked on one of my cards but not the other. How come the Pi can mount the SD card but the computer can't?

RediJedi
Posts: 45
Joined: Sun Apr 21, 2013 9:56 am

Re: Bad blocks, yet working

Thu Jul 25, 2013 2:44 pm

Hi, my thinking is maybe you used dd to write the image over a previous ext4 partition, which shouldn't be a problem but is turning out to be one. And when you insert the sdcard into your linux box, it is running fsck before it mounts the partition whereas the raspberry pi only runs fsck after so many reboots(I think), so it may not have caught the error yet. and as far as I am aware you can't run the file system check(fsck) from the raspberry pi because the partition is mounted, it can only test at boot, or from another linux box without mounting it.
Also on a separate note that maybe related, I wrote Alarmpi(arch) to my SDcard then moved the root folder over to a usb flash drive, I was happy so started again but used my portable hdd. I fired up gparted and inserted the usb flash drive to wipe it for use as a bootable gparted live.

The steps used,
1, create new gpt partition table, that should destroy all data and according to gparted it did.
2, removed and inserted the usb flash, it never mounted as there is nothing on it.
3, dd the gparted live image onto the usb flash.
4, rebooted to test and I get a error saying "recursive partition found" on the gparted live partition(the usb flash drive) it still works but throws errors.

So after some digging around looking for info on "recursive partition found" I came across a post advising to delete the superblocks. I never followed it I just re-partioned with a new gpt and the fun started. After partitioning, ejecting and re-inserting the usb flash, my old arch install came back to life, not all of it just a few folders and the usb label had changed back to archblahblah(I'm thinking superblocks, although it could be a backed up gpt table) so instead I just zero'd the usb flash with dd and that sorted my problem.
My thoughts are that superblocks are a bit more super than they need to be, and ext4 is a pain in the ****(I use f2fs & btrfs now)

If you want to zero the sdcard and write your backup to it, maybe that will fix it but i can't promise it will, the backup itself could be the problem.
Also i wouldn't advise using this command on SDcards or usb flash drives on a regular basis as it will ovewrite everything with zero's and I don't think SDcards/usb flash like that sort of thing.
The usual instructions, replace the xxx with the path to your SDcard/flash drive and double check that it is correct before using the following command.

sudo dd bs=4M if=/dev/zero of=/dev/xxx conv=notrunc

the bs=4M and conv=notrunc are optional.

wait untill it outputs: no room left on device (it will take a while depending on size of card)
then wait until you are returned to the command prompt before ejecting the SDcard/usb flash.

If you get errors about not having a valid partition table on the device use gparted, or some other partitioning software to add a new one, dd the backup onto it and try again.

Edited: the conv=notrunc was somehow truncated, sorry if anybody tried to run it as a command.

Return to “Beginners”