0

I have a 32 Gb SD card with my OS on it (Raspberry Pi OS Buster) and I wish to make a backup using standard dd, using sudo dd if=/dev/sdb of=/mnt/toshiba2tb/pi20211217.img bs=1M

The source SD card seems perfectly fine under lsblk --fs

db
├─sdb1      vfat   RECOVERY 796F-5014
├─sdb2
├─sdb5      ext4   SETTINGS 3b129a7c-44fe-4062-8819-2be9ec66edea
├─sdb6      vfat   boot     3830-AECC
└─sdb7      ext4   root     92847503-3b1f-4e22-9fa0-f6794b8fed0c

Once the image is done I copy it with dd onto a (brand) new card sudo dd if=/mnt/toshiba2tb/pi20211217.img of=/dev/sdb bs=1M, and I obtain a different partition table, which does not even boot the RPi

sdb
├─sdb1      vfat   RECOVERY 796F-5014
└─sdb2

fdisk confirms and reports and absurd 2T partition ... what is going on?

$ sudo fdisk -l /dev/sdb
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).
Disk /dev/sdb: 29.7 GiB, 31914983424 bytes, 62333952 sectors
Disk model: LRWM04U
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x000edc50

Device     Boot      Start        End    Sectors  Size Id Type
/dev/sdb1             8192    3781250    3773059  1.8G  e W95 FAT16 (LBA)
/dev/sdb2          3781251   60751871   56970621 27.2G  5 Extended
/dev/sdb5       4298748546 8593715840 4294967295    2T ff BBT

More info from sudo /sbin/fdisk -l /mnt/toshiba2tb/pi20211217.img

$ sudo /sbin/fdisk -l /mnt/toshiba2tb/pi20211217.img
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).
Disk /mnt/toshiba2tb/pi20211217.img: 29 GiB, 31104958464 bytes, 60751872 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
Disklabel type: dos
Disk identifier: 0x000edc50

Device                          Boot      Start        End    Sectors  Size Id Type
/mnt/toshiba2tb/pi20211217.img1            8192    3781250    3773059  1.8G  e W95 FAT16 (LBA)
/mnt/toshiba2tb/pi20211217.img2         3781251   60751871   56970621 27.2G  5 Extended
/mnt/toshiba2tb/pi20211217.img5      4298748546 8593715840 4294967295    2T ff BBT

I have also tried dd_rescue into a new image file, which seems to till the end without errors.

$ sudo dd_rescue /dev/sdb /mnt/toshiba2tb/pi20211217.rescue.img
dd_rescue: (info) expect to copy 30375936kB from /dev/sdb
dd_rescue: (info): ipos:  30375936.0k, opos:  30375936.0k, xferd:  30375936.0k
                   errs:      0, errxfer:         0.0k, succxfer:  30375936.0k
             +curr.rate:    10374kB/s, avg.rate:    20375kB/s, avg.load: 21.2%
             >----------------------------------------.<  99%  ETA:  0:00:00
dd_rescue: (info): read /dev/sdb (30375936.0k): EOF
dd_rescue: (info): Summary for /dev/sdb -> /mnt/toshiba2tb/pi20211217.rescue.img:
dd_rescue: (info): ipos:  30375936.0k, opos:  30375936.0k, xferd:  30375936.0k
                   errs:      0, errxfer:         0.0k, succxfer:  30375936.0k
             +curr.rate:        0kB/s, avg.rate:    20312kB/s, avg.load: 21.1%
             >----------------------------------------.<  99%  ETA:  0:00:00

Unfortunately the file obtained still shows signs of corruption

$ sudo /sbin/fdisk -l /mnt/toshiba2tb/pi20211217.rescue.img
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).
Disk /mnt/toshiba2tb/pi20211217.rescue.img: 29 GiB, 31104958464 bytes, 60751872 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
Disklabel type: dos
Disk identifier: 0x000edc50

Device                                 Boot      Start        End    Sectors  Size Id Type
/mnt/toshiba2tb/pi20211217.rescue.img1            8192    3781250    3773059  1.8G  e W95 FAT16 (LBA)
/mnt/toshiba2tb/pi20211217.rescue.img2         3781251   60751871   56970621 27.2G  5 Extended
/mnt/toshiba2tb/pi20211217.rescue.img5      4298748546 8593715840 4294967295    2T ff BBT

Just for a check I did flash this image and it has the same problem as all other images that the boot does not find the "settings" partition and hangs there forever ...

Assuming it may have been just a partition table issue I have dumped the partition table of the original SD into a file using sfdisk -d /dev/sdb > pi.partitiontable. It prints out something sensible

$ cat  pi.partitiontable
label: dos
label-id: 0x000edc50
device: /dev/sdb
unit: sectors

/dev/sdb1 : start=        8192, size=     3773059, type=e
/dev/sdb2 : start=     3781251, size=    56970621, type=5
/dev/sdb5 : start=     3784704, size=       65534, type=83
/dev/sdb6 : start=     3850240, size=      147454, type=c
/dev/sdb7 : start=     3997696, size=    56754176, type=83

Then I have copied this partition table onto the newly copied SD card $ sudo sfdisk /dev/sdb < pi.partitiontable which gave

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).
Checking that no-one is using this disk right now ... OK

Disk /dev/sdb: 29.7 GiB, 31914983424 bytes, 62333952 sectors
Disk model: LRWM04U
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x000edc50

Old situation:

Device     Boot      Start        End    Sectors  Size Id Type
/dev/sdb1             8192    3781250    3773059  1.8G  e W95 FAT16 (LBA)
/dev/sdb2          3781251   60751871   56970621 27.2G  5 Extended
/dev/sdb5       4298748546 8593715840 4294967295    2T ff BBT

>>> Script header accepted.                                                                                                                                                                            >>> Script header accepted.
>>> Script header accepted.
>>> Script header accepted.
>>> Created a new DOS disklabel with disk identifier 0x000edc50.
/dev/sdb1: Created a new partition 1 of type 'W95 FAT16 (LBA)' and of size 1.8 GiB.
Partition #1 contains a vfat signature.
/dev/sdb2: Created a new partition 2 of type 'Extended' and of size 27.2 GiB.
/dev/sdb3: Created a new partition 5 of type 'Linux' and of size 32 MiB.
/dev/sdb6: Sector 3850240 is already allocated.
Created a new partition 6 of type 'W95 FAT32 (LBA)' and of size 72 MiB.
/dev/sdb7: Sector 3997696 is already allocated.
Created a new partition 7 of type 'Linux' and of size 27.1 GiB.
/dev/sdb8: Done.

New situation:
Disklabel type: dos
Disk identifier: 0x000edc50

Device     Boot   Start      End  Sectors  Size Id Type
/dev/sdb1          8192  3781250  3773059  1.8G  e W95 FAT16 (LBA)
/dev/sdb2       3781251 60751871 56970621 27.2G  5 Extended
/dev/sdb5       3784704  3850237    65534   32M 83 Linux
/dev/sdb6       3852286  3999739   147454   72M  c W95 FAT32 (LBA)
/dev/sdb7       4001788 60751871 56750084 27.1G 83 Linux

The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.

With this card the boot complains of a settings partition being corrupt, hence asks to reinstall the OS. This is different from the previous error and may be due to (I am guessing) some misalignment or slight incompatibility of the partition table I took from the old card and copied onto the new one. Still I am wondering if this approach can work, maybe with some tweak of the partition table ...

10
  • that's not just raspberry pi OS is it, looks like a NOOBS disk (not saying that's the issue)
    – Bravo
    Dec 17, 2021 at 9:15
  • @StephenKitt good point, I was assuming the file to be ok, but maybe there is the culprit. Have a look at the output of fdisk on the image file. Please note that I have attempted this already many times writing the image in Mac OS and Linux, changed the SD card reader too.
    – Rho Phi
    Dec 17, 2021 at 12:19
  • Is the [original] SD still working as a boot drive (to run Linux in your RPi)? If not, you can try to repair the partition table with Testdisk. How is this thread related to your other question with the statement "FYI now the RPi does not boot anymore from this card"? If you cannot repair the partition table and/or file system, you may still be able to recover files with PhotoRec from cgsecurity.org. - Then install a fresh operating system.
    – sudodus
    Dec 18, 2021 at 11:16
  • 1
    @sudodus The other question is about another SD card. Both of them seem to have problems, and if you want to add to the mix, even the file on which I had stored an image of the other SD card seems to be corrupted on the hard drive where I stored it, which is why I have not yet proceeded to copy and restore the partition table of that other SD card. Moral is: "You do not have a backup until you use it".
    – Rho Phi
    Dec 18, 2021 at 12:54
  • 1
    Are any of the filesystems on sdb mounted at the point you make the copy? Dec 18, 2021 at 20:56

3 Answers 3

1

The fdisk -l output on your image shows that your image is bad; you can write it to however many SD cards you want, using any card reader, and you’ll always get a bad result.

You need to re-read the image, preferably with a tool which will tell you explicitly when the card can’t be read properly; e.g.

ddrescue /dev/sdb /mnt/toshiba2tb/pi20211217.img
5
  • it says no errors, still the file I created with it has the same problem as before. I have added details on in the original question.
    – Rho Phi
    Dec 17, 2021 at 22:28
  • I have tried to restore the image created this way and of course it does not work once I put it on the RPi because the "settings" partition cannot be found
    – Rho Phi
    Dec 18, 2021 at 20:40
  • I tried to copy the partition table from the working SD and copy it into a file using sfdisk. I got a sensible ASCI file, as far as I can see. I have tried to put that partition table on the cloned SD but it did not work. I am adding details in the original question.
    – Rho Phi
    Dec 18, 2021 at 20:42
  • By they way I think this is the answer, I was getting a different card because the copy with dd (and dd_rescue) fail to produce a faithful image.
    – Rho Phi
    Dec 18, 2021 at 20:51
  • I might open an new question on how to obtain a faithful copy ...
    – Rho Phi
    Dec 18, 2021 at 20:51
0

The number of sectors on sdb5 is 4294967295 = 0xffffffff, and partition type ID is also 0xff. There's also the Invalid flag 0xffff of EBR (for partition 5) will be corrected by w(rite) error message.

This looks like a write error on the SD card: somehow the actual data bytes that should have been there have been replaced by all-ones bytes.

The claimed size of the second card is:

Disk /dev/sdb: 29.7 GiB, 31914983424 bytes, 62333952 sectors

You might want to use the f3 tools of the Fight Flash Fraud project to verify the actual capacity of the second card.

If your card is fake, the errors might be caused by the extended partition table being located beyond the actual capacity of the card's flash chip, in an empty address space that is not actually covered by any flash chip and so is not actually useful for storing any data. Attempts to read such address space often produce only all-ones bytes. Any data written into such an address space is instantly lost.

Fake memory cards often claim to have way more storage capacity than they actually have. The storage at the very beginning of the card works normally, making it look like the card works for casual testing. But once you attempt to use more of the capacity, the card will either start to produce errors, or more insidiously just ignore the errors and return nonsensical data instead.

In your case, the fact that the extended partition table at block # 3781251 (i.e. located about 1.9 GB from the beginning of the card) got corrupted might mean the fake card actually has less than 2 GiB of actual storage capacity, although it claims to have 29.7 GiB.

1
  • The additional information elicited by Stephen Kitt's comment proves that the problem existed before the destination disk got involved
    – Ben Voigt
    Dec 17, 2021 at 16:19
0

SD cards and USB pendrives with a specified nominal size, for example

32 GB = 10^9 * 32 / 2^30 GiB approx= 29.8 GiB

have various sizes near the nominal size. Some drives are slightly bigger, and some drives are slightly smaller (undersized yes, but not criminally much too small).

Unfortunately, there are also frauds, drives that are much smaller than the nominal size.

  • A serious problem when cloning is that you cannot clone a drive, that has partitions that use the whole drive, to a drive that is slightly smaller. The target drive must have at least the same size at the byte level, as seen for example by

    lsblk -b
    
  • When the drives have exactly the same size cloning is straightforward.

  • When cloning to a bigger drive is straightforward, if there is an MSDOS partition table (sometimes called MBR). In that case you can increase the size of the 'last' partition to use the unallocated drive space.

  • When cloning to a bigger drive you need an extra operation, if there is a GUID partition table (GPT). There should be a backup partition table at the tail end of the drive, and it can be fixed with gdisk. This can be automated with the shellscript gpt-fix. This fix is built into mkusb when cloning image files. After this fix you can increase the size of the 'last' partition to use the unallocated drive space.

So before giving up on the target drive, please check the sizes, and if possible, get a target drive that is not smaller than the original one. An alternative is to shrink the last partition on the original drive, so that it will fit within the size of the target drive. You can use gparted for this purpose.

And if GPT, fix the backup partition table.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .