It’s not recommended to clone a live machine. There are ways to do it, but few are safe, and all are much more difficult than using an SD card reader (or hard disk bay) if you have any other choice.
Hi All,
Im new to jetson and new to linux.
I am trying to backup my SD card to an image so I can recover to it if my nano config gets messed up.
I have tried the following:
- Shut down nano
- Remove 64GB micro SD card
- Put micro SD into full size SD adapter with write protect on
- Put adapter into laptop
- sudo dd if=/dev/sdb of=clone_image.bin bs=80M
it says it succeeds.
Then to restore:
- using identical (same make and model) 64GB micro SD in full size adapter on same laptop
- sudo dd if=clone_image.bin of=/dev/sdb bs=80M
and it says it succeeds
but then with the new SD in the nano, the nano never boots. No errors, no console messages, the HDMI monitor never even wakes up.
I assumed the 2nd SD card would not need to be formatted before restore, but just in case I have tried formatting as ext4, NTFS, and FAT before restore, but all have failed in the same way.
I also tried restoring the .img with etcher, but it also appeared to succeed yet would not boot.
What could I be doing wrong?
Related questions: If I use
sudo create-jetson-nano-sd-card-image.sh -o some-image-filename.img
- Will that include all changes, installations, config, and code that I have made?
- Do I run the command from the nano, or from a laptop?
- If i follow instructions to jetson-nano-run-from-usb-drive/ can i expect better luck backing up and restoring?
Thanks
If you just want to clone the image, dd should work. It might be the very large block size parameter that is the issue.
https://stackoverflow.com/questions/6161823/dd-how-to-calculate-optimal-blocksize
Dd does not actually verify anything, FYI. So you must do it manually or use another tool (etcher can). Less chance of accidentally overwriting something important that way as well. Backups made this way or with dd are only suitable if restored onto the same Nano. Otherwise you may have network issues.
create-jetson-nano-sd-card-image.sh is intended to master a new card image from the rootfs, kernel, etc in the Linux_for_Tegra folder (from scratch, not from an existing Nano). If you need to clone a nano I would recommend instead:
- use the history command to examine your bash history copy and paste what you need to get the system into the same state into a new script.
- run the script on a stock or custom image, either manually, on first boot, or (advanced) using qemu on a rootfs. You can use the create SD card script for this after making the necessary customizations to the rootfs.
Then you have an image you can flash onto any device that is unique where it needs to be (ssh keys, machine-id, other network stuff) and yet still has the customizations you need such as custom software. If you’re not concerned with deploying on multiple Nanos, however, direct cloning of the card has few downsides.
thanks MDEGANS,
i first cloned with no block size parameter. It used the default (512?) and took 6+ hours and maxed out at 3M/sec. But same results - no boot.
i tried the 80M later and it topped out at about 70M/sec. My card is rated at 60M/sec. So that seemed ok.
That left me thinking i was not properly backing up a boot partition.
I wish NVIDIA or someone knowledgeable would create an image with boot time script to install:
- Latest jetpack
- latest compatible ubuntu updates
- latest compatible cuda, tensorflow, and all other common software
- working vnc server and rdp server
- expansion of partitions to consume whatever space is available on any size SD
- and some fool proof way of backing up a golden SD
It seems like the forums are full of questions where people want those things but are having lots of difficulties, like me.
hello mikezzs,
please access Jetson Nano Developer Kit SD Card Image via Jetson Download Center.
you may also refer to Write Image to the microSD Card for the steps to prepare your microSD card for Nano.
BTW,
for the image backing up.
dd commands should works if you just want to clone the image, but you should always note that dd did not handle verification actually.
thanks