Join Log in
Score:-1
ihorc avatar Server

dd the entire SD card to one partition on HDD

cn flag
ihorc

This particular question is related to Raspberry Pi, but in fact, this is a general question.

So, I have an SD card with RPI system running on it consisting of two partitions:

Disk /dev/mmcblk0: 59.5 GiB, 63864569856 bytes, 124735488 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: 0xf4481065

Device         Boot  Start       End   Sectors  Size Id Type
/dev/mmcblk0p1        8192    532479    524288  256M  c W95 FAT32 (LBA)
/dev/mmcblk0p2      532480 124735487 124203008 59.2G 83 Linux

Also, I have an external HDD connected which works as a data storage now consisting of four partitions:

Disk /dev/sda: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: EZRZ-00Z5HB0    
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 9E92BCDF-4CF7-4ECE-ABCD-5B6794FE747E

Device          Start        End    Sectors   Size Type
/dev/sda1        2048  125831167  125829120    60G Linux filesystem
/dev/sda2   125831168  754976767  629145600   300G Linux filesystem
/dev/sda3   754976768 2331002879 1576026112 751.5G Linux filesystem
/dev/sda4  2331002880 3907028991 1576026112 751.5G Linux filesystem

What I want to do is to move my RPI system from the SD card to the first partition of the HDD. Can I use the following command to clone the entire SD card (two partitions) to the first partition of the HDD?

dd if=/dev/mmcblk0 of=/dev/sda1 ...

As the destination partition is a bit larger (124735488 vs 125829120 sectors) I expect that the first HDD partition will be split by two (boot and root) and all the others sda2, sda3, etc. will remain intact. So after this operation, I will be able to boot from the HDD instead of the SD card (of course after checking all the UUIDs which may change after the migration).

It should be okay AFAIK, but I have no possibility to test this process currently. So want to double-check everything and be 100% sure to not mess up the entire system.

upd. Yes, I understand that the sda1 content will be destroyed permanently.

86
0 + 0
dd
hdd
Score:2
Nikita Kipriyanov avatar Server
za flag
Nikita Kipriyanov

Paritions are not expected to have partitions themselves. This is "one layer" system, not the "tree". The partition won't be magically "split by two", even though it would contain a valid partition table. The kernel won't automatically set up special block devices corresponding to those subpartitions. So, while you certainly can dump the whole partitioned device sector-by-sector to anything, you have to do additional manual actions to access the data on those "subpartitions" (I mean, you'll need a manual partition table interpretation and loop devices setup).

Having said that, the command you showed may only destroy data on /dev/sda1. It won't touch sda2, sda3 and so on. You won't mess anything on them, even if your sda1 isn't large enough to accept the full size of the SD card; in that case dd will stop with an error when it encounter the end of the sda1. But your partitioning seem to not suffer from this.

0 + 0
ihorc avatar
cn flag
ihorc
But `dd` command copies raw blocks, so it works "one layer" below partitions. Thus it does not even know which partition(s) it copies. So, in my understanding, it will take all the SD card blocks and place them in the sda1-marked sectors of HDD. Also, as it works with raw blocks, so no need to make any partitioning before `dd`. It will be re-written anyway. The purpose of specifying destination partition is just to specify the range it can write to. This is the same as `dd` to img file and then write img to a partition. Am I wrong?
0
Reply
Nikita Kipriyanov avatar
za flag
Nikita Kipriyanov
You are right. I said exactly same thing, "you can dump the whole partitioned device sector-by-sector to anything". So I explained you won't be able to say boot from this HDD, because while the data will be there, the system **will not create special devices** with raw file systems to mount. It won't interpret a partition table within the partition.
0
Reply
ihorc avatar
cn flag
ihorc
So, the only available solution, in this case, is to split sda1 manually (to sda1 and sda5, for example), then `dd` two partitions respectively? `mmcblk0p1->sda1` and `mmcblk0p2->sda5`?
0
Reply
Nikita Kipriyanov avatar
za flag
Nikita Kipriyanov
Honestly, I never tried to boot Raspberry Pi from other than SD card. If it can boot from a partition on USB HDD (I believe this is what you have), then yes, that will work. But notice the root filesystem location is stored in the `cmdline.txt`, so don't forget to adjust that. And keep in mind USB HDD has way bigger latency than SD card, so the system may display slower disk performance.
0
Reply
Ginnungagap avatar
gu flag
Ginnungagap
RaspberryPi can't boot from HDD, it will always read the boot partition from an SD card. The best you can do is move your root partition to HDD, leaving /boot on the SD card.
0
Reply
ihorc avatar
cn flag
ihorc
That's not true. You may find a lot of guides on how to move a Raspberry Pi system from an SD card to an external HDD/SSD. There is even a separate setting that is responsible for boot priority https://docs.nextcloudpi.com/en/rpi4-chnage-boot-order. Or `sudo rpi-eeprom-config` if you prefer command line. And, you might be surprised, there is even Network Boot mode. At least this is true for RPI4 with the latest rpi-eeprom bootloader version, don't know for others.
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.