Xavier reflash

Hello, I ran into a problem when I backed up the new board and flash it. The machine can be flashed normally, but the board cannot be started after flash.

  1. After the new board is started, the error “random: 7 urandom warning (s) missed due to ratelimiting” is reported. After waiting for a period of time, the prompt “or press Control-D to continue” is displayed. After operation, the system enters the super user mode.

  2. Lack of network card and sound card after simple operation.

  3. Prepare a new board and continue the above operation. The board can start normally.

  4. The system flash log is as follows.
    flash-log.c (52.2 KB)

Hi Yolomei,

Are you using the devkit or custom board?
and What’s the Jetpack version in use?

What’s the difference between the first new board(cannot be started after flash) and the current new board(The board can start normally)?

  1. Use the command “sudo./flash - r jetson-xavier-nx-emmc mmcblk0p1” on the customized board to flash;

  2. The L4T version used is R32.5.1

  3. Normal startup means: enter the account and password, log in, and then use it normally; The board with problems cannot enter the login interface, and an error is reported as shown in the figure above

Do you follow the adaptation instruction for your customized board?
It looks you are using the board config for the devkit.

For these two boards, do you run the same command and flash the same image?
and How about the result if you re-flash the board which cannot be started at first?

Sorry, the command written above is wrong. The correct one is “sudo./flash - r jetson-xavier-nx-devkit-emmc mmcblk0p1”;

As shown above, I didn’t find any problems with my flash log, but there was a problem with startup

Yes, it looks fine from flash log.
Do you re-flash the first board again and see if it still has the problem at startup?

I have flashed it many times, but it is still the same problem.
If I directly use the command “sudo./flash.sh jetson-xavier-nx-devkit-emmc mmcblk0p1” to flash the development board, it can start normally.
But in this case, it is not suitable for mass production, because I have many other software to be installed on the development board together.

Only the first board could not startup normally with “sudo ./flash - r jetson-xavier-nx-devkit-emmc mmcblk0p1”?

The -r parameter for flash.sh decide if re-build system.img with the stuff under Linux_for_Tegra/rootfs/.

Have you tried the following instruction to backup and restore APP partition?
Flashing Support — To clone a Jetson device and flash

Yes, I have operated three boards in this way, but only one board is correct

Just something to consider: The boot content is flashed when you use the “-r” option to flash.sh, but the boot content must match the rootfs content. In theory, if your flash is set up with the correct custom device tree (and any other customization to boot content), and if the flash release is the same as that which is compatible with the rootfs, then it should work. However, if there is a mismatch between the boot content release and the rootfs, then this might fail (especially if the device tree is not correct). Generally speaking, it is better to do as you have and to flash the boot content as well, but I wonder if that content is valid for your custom carrier board?

To really know much of anything you must include a full serial console boot log. Note that the urandom warning is not an issue and won’t have any effect on boot (and mostly not even on normal operation…this is related to realtime extensions, and is usually for audio needing more CPU time than is available, which is a temporary issue).

Hello, thank you for your reminder. I found the reason: because I am a copy system.img, I used GNOME DISKS software to mount an ssd disk on the copied development board, and added the mount directory in etc/fstab. However, when flashing a new board, GNOME DISKS did not initialize the disk, and the mount location was added to the/etc/fstab file, which led to conflicts. So I can start normally after deleting the contents added in/etc/fstab.

So there is a new problem. What should I do if I want to write the system image to the ssd card and mount the emmc as a disk.

Is it correct to say that you have a current eMMC rootfs, and that you want to transfer a copy to SSD, and then use the SSD instead? I can give you a good bit of information, but someone from NVIDIA will have to answer some final details since I don’t have an SSD to try this with. Do you have a clone of the rootfs right now? Or is this still on a running Jetson’s eMMC?

The following figure shows the memory partition of my development board
My goal is to move the system in “/dev/mmcblk0p1” to the mounted hard disk “/dev/nvme0n1p1”, and mount the existing emmc (/dev/mmcblk0p1) to the “/mnt” directory. In other words, exchange these two partitions, and use the attached hard disk as the new emmc, and the current emmc as the hard disk

I downloaded the file from the following github

git clone https://github.com/jetsonhacks/rootOnNVMe

Execute the following commands in turn

cd rootOnNVMe
sudo ./copy-rootfs-ssd.sh
sudo ./setup-service.sh
sudo reboot

After execution, my memory partition is as follows

The problem now is how to format “/dev/mmcblk0p1” into a common hard disk partition for storing personal files.

Another problem is that my current root file system exists in all three directories. What is the relationship between them? Can I delete both options 1 and 2 and leave only the desired 3. As shown in the figure below

I can’t answer all of this, but will point out a few things:

  • The copy-rootfs-ssd.sh script uses rsync for file copy. This is good, and should be correct.
  • Any eMMC model of Jetson, when flashed on command line, has the ability to name a “pointer” in the boot software for looking at configuration. Typically, this does not negate the need for “/boot” of the eMMC. You need to be careful about deleting everything in eMMC’s rootfs.
  • Before deleting anything in eMMC, be certain that boot actually goes to the NVMe. If it does, then it might be chain loading from eMMC, and so I caution again against deleting from eMMC, but this would be a good test to know if the NVMe is actually working as expected.
  • Do expect that it is possible for the need to update or edit either or both of:
    • eMMC “/boot/extlinux/extlinux.conf
    • NVMe “/boot/extlinux/extlinux.conf
  • When it is booting to where you want, then you might consider creating a serial console boot log to follow any references to mmcblk0p1 during boot.
  • Consider when editing any extlinux.conf that you should not delete the eMMC entry; you should keep this, but make a duplicate naming the NVMe, and place the NVMe as the first entry (and mark as default). This means you can recover without flashing if something goes wrong.

Someone else should probably comment on what part of eMMC is still needed when booting to NVMe, but posting a serial console boot log could answer some of the mystery. When you do go to delete content on eMMC, I suggest first testing without deleting either of these in eMMC:

  • /boot
  • /lib

You have a copy of home on the NVMe, so in theory you could remove that on eMMC as a test. Should something go wrong, then eMMC would still boot, although it would have issues.

Another place you can delete without worry is to recursively remove “/usr/local”. This would free up a lot of space if you have CUDA, and would not harm boot even if you are stuck on eMMC.

It isn’t until you can verify the eMMC “/boot” is not part of a chain load that this can be deleted.

OK, thank you. In this case, how can I recover to the original state. That is, “mmcblk0p1” is emmc, and “nvme0n1p1” is formatted and mounted to “/mnt”

After a series of operations, the partition structure is as follows

The “mmcblk0p1” partition is automatically generated after I format it and use the command “sudo ./flash.sh jetson-xavier-nx-devkit-emmc nvme0n1p1” to flash. The contents are as follows

The problem now is that I want to use the command “sudo./flash. sh jetson-xavier-nx-devkit-emmc nvme0n1p1” to reflash the machine, but the original content is not formatted, so the flash does not succeed.

I don’t actually have the NVMe to experiment with, so I do not have experience with that. I can’t answer specifics. I can tell you though that you can flash the NVMe separate from the rest of the Jetson. When you flash an eMMC model you are basically setting up “/boot” or pointers to a “/boot” inside the Jetson’s eMMC. This will not necessarily install anything to an NVMe (it might with the right commands, someone else will need to comment), but if it sets up a pointer to the boot content, then a cloned NVMe could “just work”.

Hello, what should I do if I want to backup and restore again