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.
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.
Lack of network card and sound card after simple operation.
Prepare a new board and continue the above operation. The board can start normally.
The system flash log is as follows. flash-log.c (52.2 KB)
Use the command “sudo./flash - r jetson-xavier-nx-emmc mmcblk0p1” on the customized board to flash;
The L4T version used is R32.5.1
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?
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.
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.
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
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.
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”.
