The sdcard of my raspberry 3 crashed a few weeks ago. I am trying to restore the raspbian system on another sdcard of the same capacity using a backup image of the sdcard created before the crash.

Using a Lubuntu virtual box hosted on my windows 10 computer, I am entering this command line in the terminal

gunzip --stdout ./backup_file.gz | sudo dd bs=4M of=/dev/sdb

as propose the website enter link description here. sdb is the sdcard. The copy takes some time (~10h) but it is a 64GB sd card, so it's normal I think. The process is finishing without any error.

My problem is that when I insert the sdcard back in the raspberry pi and turn it on, nothing append : the two lights of the pi are turned on together, they are not blanking at all, and nothing append after. No signal is sent to the HDMI cable neither.

What I already tried without success :

  • Taking an older backup file
  • Taking another sd card
  • Taking another raspberry pi 3

Do you have any idea of what is going on ? Thank you in advance for your help.


EDIT1 : for information, I have created the backup image of the raspberry pi 3 while it was still ok using this command line : sudo dd bs=4M if=/dev/mmcblk0 | gzip > /media/pi/USBkey/backup_file.gz


EDIT2 : After the restore operation, I can't visualize the result in gparted. I am getting this error : Invalid partition table on /dev/sdb -- wrong signature ffff.


EDIT3 : I think that there is a partition problem when copying the image on a new sdcard. Indeed, using sfdisk :

  • Exploring the partitions of the backup image sudo sfdisk -l <PATH_TO_IMAGE> :

    Disque backup-20170201 : 58,2 GiB, 62537072640 octets, 122142720 secteurs
    Unités : sectors of 1 * 512 = 512 octets
    Sector size (logical/physical): 512 bytes / 512 bytes
    I/O size (minimum/optimal): 512 bytes / 512 bytes
    Disklabel type: dos
    Disk identifier: 0xd94ffdb3
    
    Périphérique      Amorçage  Start       Fin  Secteurs  Size Id Type
    backup-20170201p1            2048    251953    249906  122M  e W95 FAT16         (LBA)
    backup-20170201p2          251954 122142719 121890766 58,1G  5 Étendue
    backup-20170201p5          253952    319485     65534   32M 83 Linux
    backup-20170201p6          319488    454655    135168   66M  c W95 FAT32 (LBA)
    backup-20170201p7          458752 122142719 121683968   58G 83 Linux
    
  • Exploring the partitions of the sdcard sudo sfdisk -l <PATH_TO_SDCARD> :

    Ignoring extra data in partition table 5.
    Ignoring extra data in partition table 5.
    Ignoring extra data in partition table 5.
    Invalid flag 0xffff of EBR (for partition 5) will be corrected by w(rite).
    Disque /dev/sdb : 59,6 GiB, 64021856256 octets, 125042688 secteurs
    Unités : sectors of 1 * 512 = 512 octets
    Sector size (logical/physical): 512 bytes / 512 bytes
    I/O size (minimum/optimal): 512 bytes / 512 bytes
    Disklabel type: dos
    Disk identifier: 0xd94ffdb3
    
    Périphérique Amorçage      Start        Fin   Secteurs  Size Id Type
    /dev/sdb1                   2048     251953     249906  122M  e W95 FAT16 (LBA)
    /dev/sdb2                 251954  122142719  121890766 58,1G  5 Étendue
    /dev/sdb5             4295219249 8590186543 4294967295    2T ff BBT
    

How can I solve that ?


  • 1
    Check the newly flashed SD with gparted, it's good at finding errors (it may be that your old SD had different geometry, for example) – user400344 Mar 21 '17 at 7:27
  • @user400344 Do you mean geometry as in CHS? This doesn't exist on SD cards. – Dmitry Grigoryev Mar 21 '17 at 16:23
  • You need to enter the commands you entered NOT a link to a website, which you may or may not have followed correctly. If you ran the tar command suggested you DID NOT backup your image. – Milliways Mar 22 '17 at 4:33
  • See EDIT1 of my original post – qcha Mar 22 '17 at 7:56
  • Please do not stick "SOLVED" onto a question title, this is already clearly indicated by the interface when you accept an answer. Also do not post answers inside questions. I have removed the relevant bits and added them to the accepted answer. This is not a discussion forum. Please take the tour to understand better how the site works. – goldilocks Mar 23 '17 at 10:13
up vote 1 down vote accepted

tryout win32 disk imager with windows system along with a card reader which read the sd card and stores to the addressed memory location. (https://sourceforge.net/projects/win32diskimager/)

  1. Prepare the sd card using SD Card Formatter
  2. Uncompress the image file *.gz
  3. Write the image on the sdcard using Win32 Disk Imager
  • @qcha sure, you'll have to uncompress it first. – Dmitry Grigoryev Mar 22 '17 at 8:36

Try plugging your SD card in your Linux PC (or mount it if it's plugged already): you should be able to see the root partition contents. If you don't, there is a problem with your backup (a good practice would be to restore your system from a backup when you make one, then you know you really have a backup).

Another thing you should have though of when making your backup with

sudo dd bs=4M if=/dev/mmcblk0 | gzip > /media/pi/USBkey/backup_file.gz

is to remount your root read-only beforehand (did you?). If a write on /dev/mmcblk0 happens while your backup command is running, your backup may end up to be inconsistent. A safe and simple alternative is to backup your SD card using a PC.

Also, double-check that dd runs without errors, perhaps post a message you get at the end. No two SD cards have exactly the same size, and if your new card is a little bit smaller than the old one, you may be writing incomplete image on it, which will fail to mount.

  • Thank you for your answer. Indeed, I regret not having tested before the restoring process :/ .. I have added in my original post information about the partitions of the image and of the sdcard after the copy. There are indeed some problems, but I don't know how to solve them.. – qcha Mar 22 '17 at 7:52
  • As you can see, the sdcard is slightly bigger than the backup image. And there is no any error at the end of the dd operation. – qcha Mar 22 '17 at 7:54
  • @qcha Thanks for the info you added. It's not normal that the partition table on the SD card is not the same as in the image file. Maybe virtualbox screwed it up. Since you're on Windows, try using win32diskimager as @MVA suggested and see if that helps. – Dmitry Grigoryev Mar 22 '17 at 8:35

The problem appears to be that you are gunzipping the contents of a disk (potentially only one) to a disk that may or may not have been formatted correctly.

When you use dd, you are duplicating the a disk, for example from loop device (a *.img file) to the block device /dev/diskX. The image in this case would define the disk geometry and dd would essentially create the partitions and lay the files down at the block level.

In your case, you may not have a gzip of the block devices, but the root filesystem instead. In this case, /dev/diskX must be partitioned to boot, root and swap and your tarball is likely root with boot mounted at /boot.

You need to check if the gzip contents are files that reside on a disk or a partitioned disk image itself. You can extract the contents to check.

If the contents are a root filesystem you may just need to format the SD card as boot root and swap. Then mount the root, on /mnt/root of your host, and mount the boot partition at /mnt/root/boot. Now extract your backup on the mounted and formatted SD card root partion with boot mounted at /boot (so your kernel and necessary boot files are places on that parition. Unmount /mnt/root/boot and /mnt/root and try to boot off the device again.

I recommend looking up the proper partitioning of the SD card for the RPi first, IIRC the boot device will be FAT32 and the root device will need to be EXT4 or another journaled (or non-journaled) filesystem

  • dd doesn't need a loop device, it happily works with regular files. You only need a loop device if you want to mount individual partitions. – Dmitry Grigoryev Mar 21 '17 at 16:48
  • Thank you for you answer. I have added in my original post some new information about the partitions of the image and of the sdcard after the copy. It seems indeed that there is a problem there. In fact you are proposing to make the copy partition by partition ? – qcha Mar 22 '17 at 7:51

Your Answer

 
discard

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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