How to transfer an already installed file system from Jetson AGX xavier to SD card and then boot from SD card?
Do you have a Linux host PC with two SD card readers? Are the two SD cards the same size?
Yes, I have a host PC with two sd card slots.
You did not state if both SD cards are the same size. I will pretend that they are, but you can add details if not. I will also pretend that the source of data shows up as “/dev/sdb”, and the partition on it is “/dev/sdb1”. You might have to adjust. I will assume the recipient is “/dev/sdc”, and that you don’t mind overwriting anything on it.
First, keep devices being read or written with dd unmounted. That’s the “umount” command, and needed since usually SD cards get auto mounted. An example if mount is shown from the “lsblk -f” command:
sudo umount /dev/sdb1
sudo umount /dev/sdc1
To directly copy an entire SD card, including metadata, to become a 100% clone, including partition and volume IDs, so on:
sudo dd if=/dev/sdb of=/dev/sdc bs=100M status=progress
After this “lsblk -f” should show both are identical (other than the “/dev/sdb” versus sdc).
If the recipient is larger than the source, then some space won’t be used. This can be fixed.
If the recipient is smaller than the source, then we cannot directly clone like that, unless the partition in question is the same size. If that’s the case, then we’d clone partition-to-partition instead of entire SD-to-SD. If needed, then I can give you instructions on gdisk to set up partitions. If and only if you will need to set up partitions manually, then in addition to the “lsblk -f” output for each SD card, I’ll need to see the output of:
sudo gdisk -l /dev/sdb
sudo gdisk -l /dev/sdc
(assumes sdb and sdc…adjust for your case)
Incidentally, an easy way to make logs of this:
sudo gdisk -l /dev/sdb 2>&1 | tee log_sdb.txt
sudo gdisk -l /dev/sdc 2>&1 | tee log_sdc.txt
(remember, you don’t need this unless sizes differ such that we have to partition)
Is it possible to clone the root directory using the dd command, then mount it to the Linux_for_Tegra/rootfs directory, and use the jetson-disk-image-creator.sh script to make an image, write it to the sd card and then boot from it?
Something to consider is that you don’t want to use dd with a filesystem which is changing. If the filesystem is mounted, and it is not read-only, you really shouldn’t do this. To some extent it is still possible to get away with this if you are not running any programs, but you will have issues with temporary files and swap files and many things which you do not control. A more proper way to clone a root filesystem, while it runs, is via the rsync utility. This happens to also work over ssh/network if you so desire, so the backup can go to another computer (or it can go to another partition on the same computer). Using recovery mode clone is basically using the equivalent of dd while the operating system is not running and everything is read-only.
Life is much simpler if you can simply mount a read-only source and have an unmounted destination, then direct dd use is not an issue. Mostly it is the read-only source which is needed for simpler and better results.
If you use rsync, then the partition will need to be created as an exact duplicate before you rsync to that partition. Basically rsync does not create a partition, and also does not format; rsync does perfectly preserve files and metadata about them. dd is dumb and just blindly copies every last bit exactly as it sees them (even if the bits change in the middle of copy). Do you want to use rsync? Do you have the destination partition already created as an exact duplicate (or perhaps larger empty partition)?
Yes, I have a larger empty partition, how can I use the rsync command in this case?
I’m going to pretend that the ext4 partition of the Jetson is running, that the source partition is “/”, and that the destination partition is large enough. That destination partition is going to be assumed to be mounted on “/mnt”.
Tips:
- Many copy style or find style commands offer an option to “not cross filesystems”. For “
rsync”, that is the “-x” option (or “--one-file-system”. - Also,
rsynchas another option to “pretend” so you can see messages, but to not actually do anything until you are sure it is correct; that is the “--dry-run” command. -
rsyncis able to store up data first on the destination, and only erase after new content is present (this is the normal behavior). Useful if something goes wrong, but if you don’t have enough space, it won’t work. I’m assuming to use the option “--delete-before”. - Linux, in general, does not use actual user names and group names the way people normally think. In reality, those are numeric IDs, and the “name” is a translation. If the names and permissions are the same on two systems, that isn’t a problem, but in any case where you want to use this for backup and restore on any serious basis, you need to specify
rsyncoption “--numeric-ids”.
My recommended start, with “--dry-run”, using the expected source and destination (this is easily modified to be over ssh):
rsync --dry-run -avczrxl --one-file-system --numeric-ids -e --delete-before / /mnt/
The “--one-file-system” is particularly important, and not just because the destination “/mnt” is on the source “/”. “/proc” is not a real filesystem, and can result in infinite recursion if copied. The same is true for “/sys”. The “/dev” filesystem is not normally copied since it is the result of drivers pretending to be files, but if you leave out options to avoid it, then you’ll get it (it’s really fun to copy “/dev/random” from an application that does not know what a device special file is, and from which it copies content).
I’m going to add one other option to avoid any “lost+found” directory (this is part of the ext4 filesystem, and is not supposed to be copied in most cases):
rsync --exclude '/lost+found' --dry-run -avczrxl --one-file-system --numeric-ids -e --delete-before / /mnt/
Finally, there is one more useful option, “--info=progress2,stats2”. On long copies it is nice to use that to see progress.
Don’t forget to remove “--dry-run” once you are satisfied with the copy command.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.