Dd

為什麼 dd 給我的 SD 卡與其來源不同？

  • December 18, 2021

我有一個 32 Gb SD 卡，上面有我的作業系統（Raspberry Pi OS Buster），我希望使用 standard 進行備份dd，使用sudo dd if=/dev/sdb of=/mnt/toshiba2tb/pi20211217.img bs=1M

源 SD 卡在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

映像完成後，我將其複製dd到（全新的）新卡上sudo dd if=/mnt/toshiba2tb/pi20211217.img of=/dev/sdb bs=1M，並獲得了一個不同的分區表，它甚至無法啟動 RPi

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

fdisk確認和報告和荒謬2T的劃分……這是怎麼回事？

$ 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

更多資訊來自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

我還嘗試dd_rescue了一個新的圖像文件，它似乎直到最後都沒有錯誤。

$ 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

不幸的是，獲得的文件仍然顯示出損壞的跡象

$ 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

只是為了檢查一下，我確實刷新了這個圖像，它與所有其他圖像存在相同的問題，即引導找不到“設置”分區並永遠掛在那裡……

假設它可能只是一個分區表問題，我已將原始 SD 的分區表轉儲到使用sfdisk -d /dev/sdb > pi.partitiontable. 它列印出一些明智的東西

$ 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

然後我將此分區表複製到新複製的 SD 卡 $ sudo sfdisk /dev/sdb < pi.partitiontable上

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.

使用此卡，啟動會抱怨設置分區已損壞，因此要求重新安裝作業系統。這與之前的錯誤不同，可能是由於（我猜）我從舊卡中取出並複製到新卡上的分區表存在一些錯位或輕微不兼容。我仍然想知道這種方法是否可行，也許需要對分區表進行一些調整……

圖像上的fdisk -l輸出表明您的圖像不好；您可以使用任何讀卡器將其寫入任意數量的 SD 卡，但結果總是很糟糕。

您需要重新讀取圖像，最好使用能夠明確告訴您何時無法正確讀取卡片的工具；例如

ddrescue /dev/sdb /mnt/toshiba2tb/pi20211217.img

上的扇區數sdb5為 4294967295 = 0xffffffff，分區類型 ID 也是 0xff。還有Invalid flag 0xffff of EBR (for partition 5) will be corrected by w(rite)錯誤資訊。

這看起來像是 SD 卡上的寫入錯誤：不知何故，應該存在的實際數據字節已被全 1 字節替換。

第二張卡的聲稱尺寸為：

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

您可能需要使用Fight Flash Fraud 項目的 f3 工具來驗證第二張卡的實際容量。

如果您的卡是假的，則錯誤可能是由於擴展分區表位於卡的快閃記憶體晶片的實際容量之外，位於實際上未被任何快閃記憶體晶片覆蓋的空地址空間中，因此實際上對儲存沒有用處任何數據。嘗試讀取此類地址空間通常只產生全一字節。寫入此類地址空間的任何數據都會立即失去。

假儲存卡通常聲稱擁有比實際更多的儲存容量。卡最開始的儲存工作正常，看起來卡可以用於臨時測試。但是，一旦您嘗試使用更多容量，該卡將開始產生錯誤，或者更陰險地忽略錯誤並返回無意義的數據。

在您的情況下，塊＃3781251（即距卡開頭約 1.9 GB）的擴展分區表已損壞的事實可能意味著假卡實際上具有不到 2 GiB 的實際儲存容量，儘管它聲稱有 29.7 GiB。

引用自：https://unix.stackexchange.com/questions/682822

相關問答

Linux

為什麼掛載ddrescue鏡像時需要設置loop設備？

  • March 18, 2022
檢視問答
Dd

如何恢復 gnu_ddrescue 來擦除硬碟？

  • May 7, 2021
檢視問答
Osx

執行dd。為什麼資源很忙？

  • August 19, 2020
檢視問答
Hard-Disk

如何在清零磁碟時忽略寫入錯誤？

  • May 8, 2020
檢視問答
Linux

作業系統如何知道我們正在使用哪種類型的快閃記憶體

  • August 22, 2019
檢視問答
Data-Recovery

dd / ddrescue 上的多塊讀取中的不可讀塊：它如何處理？

  • November 6, 2018
檢視問答