Hello,
I am using the jetson nano production module and it seems that the rfs is full and it is not booting.
Can the jetson nano production module be recognized as a usb device and delete certain files?
Thank you.
Hello, @mdegans
Can you help me?
jetson nano emmc cannot boot, the message is as follows.
I think the problem is because the rfs is full. Can I delete unnecessary files by recognizing the jetson nano emmc module as a usb device?
Thank you.
Hi
Since emmc is 16GB only, you may consider to have external storage and move the rootfs to it. May refer to
https://elinux.org/Jetson/L4T/Boot_From_External_Device
1 Like
Additional note: The exported data from the virtual USB device in device mode is read-only, and tiny, so it cannot be used for a way to delete when too much space has been used. If it is an SD card model, just delete content you don’t want from the SD card mounted to a different computer. For the eMMC model, if you have serial console access, then use that. Otherwise you must flash again, but can clone first and delete excess from the clone before using it to flash.
1 Like
Hello,
Thank you for always leaving good answers…
Is the problem of not booting that I attached above is caused by full rfs?
How do I delete a specific partition after cloning?
Do you restore the cloned image, delete the excess and clone the image again?
From the point of view of a customer (end user), it seems to be too difficult. Is there any other alternative when it can’t boot like this problem?
Thank you.
Hello,
I only guessed it might be a problem due to the rfs being full
Is the problem of not booting that I attached above is caused by full rfs?
Thank you.
I can’t say from what was shown (in part because the images clip some of the output) if the filesystem is full. However, if it is full, and if you can log in via serial console, then there is a lot you can do to fix this, or to just examine what is going on. For example, if you can use serial console, then you might run the command “df -H -T” and see what it shows.
You don’t delete a partition. The only partition which matters in cloning is the root filesystem (“rootfs”/“APP”). You might have a custom carrier board, in which your host side flash software would have updates, and when you flash the clone, then the clone plus correct supporting content would be flashed.
When you flash, the default cause is to create host file “Linux_for_Tegra/bootloader/system.img”. If you flash and tell it to “reuse” the rootfs (via command line option “-r”), then whatever system.img is there gets used again rather than getting generated from scratch. If you happen to have a clone, and copy it to “bootloader/system.img”, then your clone becomes what the Jetson installs. If you take a clone from a Jetson, and flash the clone back, then you have effectively made no changes and have done nothing.
However, the raw clone (cloning produces both a “raw” and “sparse” clone) can be mounted on the host PC. The mounted clone can be examined, edited, “fixed” as needed, so on. If you are unable to access a rootfs you want to keep, then working on the clone on the host PC would give you the way to do this. Consider this the most powerful backup and restore possible.
There is no “rescue” image. It is possible to set up a unit to perhaps boot to a USB thumb drive and work from that, but generally you would need to set that up ahead of time and test it. If it happens that the bootloader looks for other bootable devices before continuing on with the Nano’s main boot device, then you could perhaps rescue this way. However, a clone is a true backup and does this anyway. There is no fast or simple alternative once the system cannot boot with user access.
Of course if this is an SD card model, then none of that matters because you can just mount the SD card on the host PC and fix there.
1 Like
Hello,
It’s a production module, and it’s a problem that our customers in the US are having.
Customers don’t know how to flash.
Thank you.
Hello,
I’ll ask customers to do the following and share the results.
Thank you.