Hi,Is there a similar Raspberry Pi SD Card Copier software?
I don’t have Jetson yet, but for Pi
I use win32diskimager in windows
On Linux you can copy an entire SD card with dd. If for example on the host PC the SD card shows up as “/dev/mmcblk1” (no “p0” since it is a whole device and not just a partition of a device), one could copy as:
sudo dd if=/dev/mmcblk1 of=clone_of_sd.img bs=512
Restore, if you had another SD card of the same size at “/dev/mmcblk2”:
sudo dd if=clone_of_sd.img of=/dev/mmcblk2 bs=512
Note that the “bs=512” doesn’t change the clone, but does change the speed. You might be able to use “bs=4096” or even higher for a faster clone/restore.
The restored SD would be a 100% exact copy of the other SD. Possibly gdisk and/or gparted could be used to edit if the restored disk is larger than the image.
Is it possible to do this straight from the Nano? I have a 64GB SD Card, and I plan to copy everything into a 128GB SD Card. I have a USB Card reader that I can plug into the Nano. What do I run?
Generally, no on the booted card, because the filesystems would change by the time the backup would finish. Your cloned image would be invalid. You could use the nano to clone one sd card to another but you would need 2 usb SD card readers and a third as card to boot off. In such cases you might as well use a laptop/desktop go accomplish the task. All that being said, don’t clone images unless it’s for restoration go the same devics. You will have major network and security issues if you try to deploy this way.
In practice, yes, you can totally clone the currently mounted image. When you next want to boot it, the file system will be “dirty” (as if the computer crashed at the time of the clone,) but that’s usually OK. If you need to expand the existing card to a bigger card to use instead, you can do this.
Assuming the USB SDCard writer put the target card on /dev/sda:
$ sudo bash
# sync
# sync
# dd if=/dev/mmcblk0 of=/dev/sda bs=1024k status=progress
#
Note that “bs=512” will take all day. You want a larger block size, for sure! bs=1024k is generally OK; going larger doesn’t usually lead to any faster throughput.
Once you remove the old card and boot from the new card, you will want to extend the partition of the main file system, and you’ll also want to use resize2fs to actually extend that file system.
As mdegans correctly says, booting two different devices from the same cloned disk without additional preparation (hostname, ssh key, potentially update software-defined MAC address, update static IP addresses, etc) may cause trouble.
An alternative is to prepare the bigger card as normal, and run it/expand its file system, and then boot from the smaller card, and copy all files over to the bigger card from the root partition. You’d want to mount the target on some point (for example, /mnt/target) and copy using something like:
$ sudo bash
# cd /
# find . -xdev -depth -print | cpio o | (cd /mnt/target && cpio i)
# umouht /mnt/target
#
This will copy all files from the root file system onto the root-of-new-card as mounted on /mnt/target.
This will make a “clean” file system, without the dirty-snapshot problem, but it will still need the per-host data changes if you intend to run a second device with this copy.
In practice, yes, you can totally clone the currently mounted image.
The other dog is right. You can do it, and you can probably usually get away with it… but things can also go wrong, and if something does in this case can be very hard to debug. Imho it should only be used as an option of last resort. However, there are ways of unmounting your partitions on a live system and safely cloning the disk.
To unmount the root partition, you can try switching to the emergency runlevel (sudo systemctl isolate emergency.target), if it works on nano, before running dd, but if you see no display on screen after, you will have to switch from hdmi to DP (or vice versa, i forget which doesn’t work). Once in emergency mode, you may be able to run the other dog’s dd commands 100% safely if dd is available (i think it is, iirc).
Please note that emergency mode will turn all services off, including networking, so this needs to be done locally. If emergency mode doesn’t work, you can try rescue.target or multi-user.target instead of emergency.target. While those still leave the root partition mounted, there should be less disk activity than with Wayland and Unity running. Those failing, you can attempt to make a chroot in ram, pivot_root to it, unmount the old partitions, and clone the entire disk, but that’s some pretty advanced voodoo when it’s as easy as it is to pop out the sd card.
In practice, yes, you can totally clone the currently mounted image. When you next want to boot it, the file system will be “dirty” (as if the computer crashed at the time of the clone,) but that’s usually OK. If you need to expand the existing card to a bigger card to use instead, you can do this.
Assuming the USB SDCard writer put the target card on /dev/sda:
$ sudo bash # sync # sync # dd if=/dev/mmcblk0 of=/dev/sda bs=1024k status=progress #
Note that “bs=512” will take all day. You want a larger block size, for sure! bs=1024k is generally OK; going larger doesn’t usually lead to any faster throughput.
Once you remove the old card and boot from the new card, you will want to extend the partition of the main file system, and you’ll also want to use resize2fs to actually extend that file system.
As mdegans correctly says, booting two different devices from the same cloned disk without additional preparation (hostname, ssh key, potentially update software-defined MAC address, update static IP addresses, etc) may cause trouble.
An alternative is to prepare the bigger card as normal, and run it/expand its file system, and then boot from the smaller card, and copy all files over to the bigger card from the root partition. You’d want to mount the target on some point (for example, /mnt/target) and copy using something like:
$ sudo bash # cd / # find . -xdev -depth -print | cpio o | (cd /mnt/target && cpio i) # umouht /mnt/target #
This will copy all files from the root file system onto the root-of-new-card as mounted on /mnt/target.
This will make a “clean” file system, without the dirty-snapshot problem, but it will still need the per-host data changes if you intend to run a second device with this copy.
This works in so far as duplicating the 64GB (old card) to the 128GB (new card). However, it does only use 64GB, and it didn’t expand. I know you said that I have to expand the file system, but I don’t know how, and it’s beyond my current skillset on how to.
Is it okay for you to outline the steps on how to do so? Thank you.
EDIT:
I noticed that my /dev/mmcblk0 has the remaining 64GB and is Unallocated Space, and my /dev/mmcblk0p1 has the 64GB Cloned from the old card (64GB). I’m assuming right now that I need to expand mmcblk0p1 into mmcblk0 to get the full 126GB? Is that correct? How do I do that?
To resize to the extents of the disk, it should just be:
resize2fs /dev/mmcblk0p1
edit: forgot the partition. thanks Snarky
To resize to the extents of the disk, it should just be:
The way I’ve done it, I’ve always had to resize the partition to be bigger first (using gdisk or gparted or whatever)
Then, once the partition is bigger, I can sudo resize2fs /dev/partition-name
The man page for resize2fs says:
The resize2fs program does not manipulate the size of partitions. If you wish to enlarge a filesystem, you must make sure you can expand the size of the underlying partition first.
Also, the partition name is unlikely to be just /dev/mmcblk0, because that’s the full disk with partition table.
On a standard NVIDIA image, the root file system lives on /dev/mmcblk0p1 and, luckily, that partition is mapped to the end of the device, so you should be able to just resize the partition in gdisk, write/quite gdisk, and then run resize2fs.
Default layout on 64 GB disk of the NVIDIA image:
Number Start (sector) End (sector) Size Code Name
1 24576 124735454 59.5 GiB 8300 APP
2 2048 2303 128.0 KiB 8300 TBC
3 4096 4991 448.0 KiB 8300 RP1
4 6144 7295 576.0 KiB 8300 EBT
5 8192 8319 64.0 KiB 8300 WB0
6 10240 10623 192.0 KiB 8300 BPF
7 12288 13439 576.0 KiB 8300 TOS
8 14336 14463 64.0 KiB 8300 EKS
9 16384 17663 640.0 KiB 8300 LNX
10 18432 19327 448.0 KiB 8300 DTB
11 20480 20735 128.0 KiB 8300 RP4
12 22528 22687 80.0 KiB 8300 BMP
Printed using “sudo gdisk /dev/mmcblk0” followed by the “p” command.
Snarky is right. I did forget a few steps. You may be able to just run this script (but backup your files beforehand). This is what’s run on first boot by Nvidia’s stock image to accomplish the job. It’s in /etc/systemd/resizefs.sh on the image but it self deletes on first boot so you won’t find it on your Nano. It can be found in L4T/rootfs/etc/… as well if you have sdk manager installed.
#!/bin/bash
# Copyright (c) 2019, NVIDIA CORPORATION. All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions
# are met:
# * Redistributions of source code must retain the above copyright
# notice, this list of conditions and the following disclaimer.
# * Redistributions in binary form must reproduce the above copyright
# notice, this list of conditions and the following disclaimer in the
# documentation and/or other materials provided with the distribution.
# * Neither the name of NVIDIA CORPORATION nor the names of its
# contributors may be used to endorse or promote products derived
# from this software without specific prior written permission.
#
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS ``AS IS'' AND ANY
# EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
# PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
# CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
# EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
# PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
# PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY
# OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
# This is a script to resize partition and filesystem on the root partition
# This will consume all un-allocated sapce on SD card after boot.
set -e
function cleanup()
{
# Delete nvresizefs.sh, nvresizefs.service and its symlink
rm "/etc/systemd/nvresizefs.sh"
rm "/etc/systemd/system/nvresizefs.service"
rm "/etc/systemd/system/multi-user.target.wants/nvresizefs.service"
}
if [ -e "/proc/device-tree/model" ]; then
model="$(tr -d '
#!/bin/bash
Copyright (c) 2019, NVIDIA CORPORATION. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
* Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
* Neither the name of NVIDIA CORPORATION nor the names of its
contributors may be used to endorse or promote products derived
from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS ``AS IS’’ AND ANY
EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY
OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
This is a script to resize partition and filesystem on the root partition
This will consume all un-allocated sapce on SD card after boot.
set -e
function cleanup()
{
# Delete nvresizefs.sh, nvresizefs.service and its symlink
rm “/etc/systemd/nvresizefs.sh”
rm “/etc/systemd/system/nvresizefs.service”
rm “/etc/systemd/system/multi-user.target.wants/nvresizefs.service”
}
if [ -e “/proc/device-tree/model” ]; then
model=“$(tr -d ‘\0’ < /proc/device-tree/model)”
fi
if [ “${model}” != “jetson-nano” ]; then
cleanup
exit 0
fi
Move backup GPT header to end of disk
sgdisk --move-second-header /dev/mmcblk0
Get root partition name i.e partition No. 1
partition_name=“$(sgdisk -i 1 /dev/mmcblk0 |
grep “Partition name” | cut -d' -f2)”
partition_type=“$(sgdisk -i 1 /dev/mmcblk0 |
grep “Partition GUID code:” | cut -d’ ’ -f4)”
partition_uuid=“$(sgdisk -i 1 /dev/mmcblk0 |
grep “Partition unique GUID:” | cut -d’ ’ -f4)”
Get start sector of the root partition
start_sector=“$(cat /sys/block/mmcblk0/mmcblk0p1/start)”
Delete and re-create the root partition
This will resize the root partition.
sgdisk -d 1 -n 1:“${start_sector}”:0 -c 1:“${partition_name}”
-t 1:“${partition_type}” -u 1:“${partition_uuid}” /dev/mmcblk0
Inform kernel and OS about change in partitin table and root
partition size
partprobe /dev/mmcblk0
Resize filesystem on root partition to consume all un-allocated
space on disk
resize2fs /dev/mmcblk0p1
Clean up
cleanup
' < /proc/device-tree/model)"
fi
if [ "${model}" != "jetson-nano" ]; then
cleanup
exit 0
fi
# Move backup GPT header to end of disk
sgdisk --move-second-header /dev/mmcblk0
# Get root partition name i.e partition No. 1
partition_name="$(sgdisk -i 1 /dev/mmcblk0 | \
grep "Partition name" | cut -d
I commented out the cleanup function that self deletes. -f2)"
partition_type="$(sgdisk -i 1 /dev/mmcblk0 | \
grep "Partition GUID code:" | cut -d' ' -f4)"
partition_uuid="$(sgdisk -i 1 /dev/mmcblk0 | \
grep "Partition unique GUID:" | cut -d' ' -f4)"
# Get start sector of the root partition
start_sector="$(cat /sys/block/mmcblk0/mmcblk0p1/start)"
# Delete and re-create the root partition
# This will resize the root partition.
sgdisk -d 1 -n 1:"${start_sector}":0 -c 1:"${partition_name}" \
-t 1:"${partition_type}" -u 1:"${partition_uuid}" /dev/mmcblk0
# Inform kernel and OS about change in partitin table and root
# partition size
partprobe /dev/mmcblk0
# Resize filesystem on root partition to consume all un-allocated
# space on disk
resize2fs /dev/mmcblk0p1
# Clean up
# cleanup
I commented out the cleanup function that self deletes.
Just a note for linux users:
sudo fdisk -l
to figure out where is your SD card under /dev/
“sudo gdisk -l” works better since it understands GPT partition schemes, whereas fdisk was intended for older BIOS style partitions (though I think it has been retrofitted and probably works, although possibly only when a protective MBR is present).
Hi everyone. Recently I have tried several ways, including the one above, and win32 disk imager to clone my image. The final result is the same. When it tries to boot, I get spammed with the message
mmcblk0: command error, retrying timeout
mmcblk0: timed out sending r/w cmd command , card status 0xc00b00.
Anyone have any experience with this issue?
mmcblk0: command error, retrying timeout
mmcblk0: timed out sending r/w cmd command , card status 0xc00b00.
This sounds more like a hardware error. Assuming this is an SD card, and you monitor “dmesg --follow
” on a Linux host PC, then plug in the SD card, what do you see in the dmesg
output during the SD insert? Also, is this a regular Nano dev kit, or is a third party carrier board involved?
Sorry for the delay, I haven’t logged in here for a while. Anyway, the SD card itself works, because I built a new image on it and started over, with no problem. I will try backing this one up soon and flashing a copy. I will report back when I do it.