Regarding l4t_create_default_user.sh

Hello.

Sorry for obscuring the question.

To explain with an example,

After flashing the Jetson Nano, the settings I want, when the power button is pressed, it does not enter hibernation and immediately shuts down, or I need to fix a bug in Ubuntu to do desktop sharing (Vino), etc.
The question was, can we clone the Jetson nano that has completed these tasks and restore the cloned nano to the target nano as it is?

Thank you.

Hello,

To restore what you have backed up
It takes about 3 minutes and 30 seconds from the start of the script execution and does not require a reboot process. Is it correct?

image

Thank you.

Hello,

When the backup was restored, the message [The [APP] has been pdated successfully] appeared normally on the host PC as in No. 1, but when I checked the target module as in No. 2, the following message was repeatedly displayed and the booting was not possible. What is the problem?


Thank you.

@WayneWWW
@DaneLLL

Hello,

I found following text on https://elinux.org/Jetson/Clone

There is also another method to backup APP partition, if Cloning fails with L4T tool, please try this method. This method is written for Jetson AGX Xavier but it can apply to other platforms.

Is it work for jetson nano?

Thank you.

that is actually not a method to clone an APP partition, but rather a method of doing full clone, as per my experience, as I am using it. In the article, However, it just illustrates APP partition clone use case so that it could be used with mksparse & flash.sh
Moreover, te method is experimental - provided as is: any lost data, burned devices will be solo responsibility of the developer who uses it as is.

Although it works with Jetson nano, unless the nano has production module with eMMC, it is beter to detach sdcard from nano & clone APP partition at host PC, or clone the entire disk

1 Like

Probably. Not a guarantee.

Don’t use “-r -k APP”. Use “-r”, allow the other partitions to be updated to match. The extra time will be trivial. In theory just “-k APP” would work, but I think it has too many exceptions. Also, make sure that the release of flash software installing a new rootfs is the same version which flashed the Jetson that created that rootfs. Don’t mix L4T release versions.

NOTE: @mdegans mentions just using the SD card directly if you have this. He is right, this will simplify life for you. The above comments on “-k APP” apply if using flash software.

1 Like

Hello,

I am using the emmc module.
If so, can I use this method?

Thank you.

Hello,

For example, if you have a source and a destination module, you are saying to make the two l4t versions the same, right?


Thank you.

Then clone with command line:

sudo ./flash.sh -r -k APP -G my_backup.img jetson-nano-emmc mmcblk0p1

Restore with:

sudo ./flash.sh -r jetson-nano-emmc mmcblk0p1

(first place a copy of your backup in "`Linux_for_Tegra/bootloader/system.img`" prior to flashing)

Note that the clone provides both "`my_backup.img`" (sparse) and "`my_backup.img.raw`" (raw). Either will flash the same thing, but the sparse image is smaller. You can never examine or alter the sparse image, so the raw image is actually the one you should never lose. You can edit and examine and modify the raw image. A sparse image can be created from a raw image if you want a smaller image. Make sure that the software flash release version used to create the original image is the same release as that which is updating the nano with the clone.
1 Like

You cannot flash from a Nano, but you can use its rootfs as the source to flash to another Nano provided you have the Ubuntu PC in the middle.

The rootfs and boot content have strong dependencies. All of the non-rootfs partitions need to be from a release supporting what the rootfs has. If you were to flash normally, then this is a guaranteed match. As soon as you use one Nano for content to put on another Nano, then the match is only guaranteed if you made sure flash software performing the flash of clone onto a new Jetson is a match.

This does mean making sure both Nanos are flashed with the same release.

Hello,

as mentioned above
I used “-r -k APP” to restore the 4 nanos, but two were restored normally, and two were unable to boot.
Would it be normal if I restore it with the -r -k APP option removed?

Thank you.

You need the “-r” to avoid the image of rootfs being overwritten with a newly generated image. The “-k APP” is probably best removed because it causes the surrounding partitions to not be flashed. There may be some subtle incompatibility for the two which failed to boot…and if that is the case, then not using “-k APP” would guarantee those non-rootfs partitions are compatible. Always use the “-r” unless you are ok with overwriting the current rootfs with a default generated verison.

1 Like

Hello,


As you told me, the “-r -k APP” was removed and only the “-r” option was used, so the target nanomodule, which failed yesterday, was restored properly.

As you told me, the message after restoration is different from when using “-r -k APP”. (Refer to the red square box)


This is not a restoration problem, and the update package is displayed even after cloning with the display of the update package disabled as follows. Do you have anything to comment on this?

===== /etc/apt/apt.conf.d/ 10periodic =========================

APT::Periodic::Update-Package-Lists “0”;
APT::Periodic::Download-Upgradeable-Packages “0”;
APT::Periodic::AutocleanInterval “0”;


I tried to restore one target nano with a cloned image.
I don’t know how to use this to create a mass flashing blob. Is there anything you can tell me?

Thanks to you, the restoration was successful. Thank.

Thank you.

@DaneLLL
@WayneWWW

Hello,


The cloned image is copied to bootloader/system.img and mass flashing image is being created.

Even if I read README_Massflash.txt
sudo ./nvmassflashgen.sh [] mmcblk0p1
It is not guided to give any options other than secureboot options.

How do I create a mass flashing blob from a cloned image?

Thank you.

Hi @Hodu
For clearness, please start a new topic. Thanks.

1 Like

ok

Hello,

As quoted

WayneWWW told me to create an image with a default account and password and use that image to do mass flashing.

Thank you.

I do not see anything that would prevent from doing so.

1 Like

I’ve never mass flashed, I couldn’t tell you anything useful for that.

However, if I were to guess, then perhaps you could place a loopback mounted copy of your image (the raw format, not the sparse one) on “Linux_for_Tegra/rootfs/”. Then flash would use that as the content to create a new filesystem from. This would result in the image being edited, but this would only be the boot content and not the rest of the image (just make sure your actual original clone image is protected somewhere).

1 Like