- installing from UBUNTU on 128GB flash
- installing minimal: LINUX + runtime
- ******* Error message - need more space in partition … /cow"
- Do I need a bigger flash ?
- will a 1TB flash do the trick ?
- some other problem ?
Thx
Which JetPack/SDK Manager version are you working with? Is this the Jetson Orin Nano developer’s kit, or is this from a third party? For this latter question, if the Orin Nano has an SD card slot on the module itself, and if there is no eMMC memory, then this would be an Orin Nano developer’s kit; if this has eMMC, then a third party built the carrier board and the module is a commercial module with eMMC on it. Software and procedures change depending on all of the above.
Generally speaking, flashing an Orin Nano developer’s kit has two distinct topics for flash: The boot chain and software equivalent of what a BIOS would do (if it had a hardware BIOS) is flashed into the QSPI memory of the module itself. QSPI is relatively small, and the content already exists in the flash software on the host PC without having to generate it separately. Then there is the operating system itself, which goes onto an SD card (remember, the SD card of a dev kit is quite different from that of an eMMC model).
If you’ve installed the flash software, and need to flash only QSPI boot chain, then you don’t really need much space beyond what is installed. For reference, L4T is what gets flashed as the o/s, and this is just what you would call Ubuntu after the NVIDIA content is added to it; the major version release of the L4T has to be the same release as that content in QSPI, and so you would not need to flash at all to use a combination of:
- L4T R35.x with JetPack 5.x.
- L4T R36.x with JetPack 6.x.
You could not use L4T R35.x (Ubuntu) with JetPack 6.x QSPI boot content (there is an exception, that if you use the --archived-versions option, then JetPack 6.x will make older releases available, and you could tell JP 6.x to just use the 5.x content), and you could not use L4T R36.x with JetPack 5.x. The dev kits make available a prebuilt SD card image, and most people use this for the dev kit; what remains is to flash the QSPI to match whichever SD card image you want to use. Not much space is required for that.
As soon as you start flashing the o/s itself, and not just QSPI, the space requirements go up dramatically for the host PC. When flashing an eMMC model all of that previous QSPI content for an SD card model of dev kit goes into eMMC partitions instead of going into QSPI, but this also does not require much space…it is the o/s going into eMMC which takes up so much space. It is possible for JetPack to flash the SD card by generating an image, and skipping the prebuilt SD card image. In the case of actually flashing the o/s (which is on the root filesystem, or “rootfs”) of an SD card model, then the same huge increase in host PC disk space requirement applies (separating out the SD card image is why the QSPI model dev kit can flash with so much less PC space, but it is rare for people to do that).
For any case where the rootfs is being generated (all eMMC models, and an SD card model if and only if “generating” the o/s itself for the rootfs) the entire Jetson o/s (rootfs) is being generated as a partition on the host PC itself before flashing the binary content. If your Jetson is going to have a 28 GB partition generated, then you instantly need a lot more than 28 GB. If your Jetson will have a 64 GB partition generated, then you suddenly need far more than 64 GB on the host PC.
If you look at your flash software, it creates a subdirectory “Linux_for_Tegra/”. Within that is a “rootfs/” subdirectory. That content, in addition to some edits based on the model of Jetson you are flashing, and boot specifications, is used only for the “content” of the partition, and the partition itself is larger than the content. Imagine that you have a 64 GB partition, and if you have only 3 or 4 GB of content, you still need 64 GB to generate a partition despite the partition only being a few percent full. This is the raw image…the partition size.
The content actually used in the partition might be small, the rest of that is empty filesystem. There is also something called a “sparse” image. That sparse image leaves out the empty space. Thus, as the actual content size goes up, so too does the sparse image size. As the content approaches full use of the partition the sparse image size approaches the size of the raw partition.
One can actually flash with the raw partition, and long ago this was what was flashed in much earlier models. However, as the image size got larger the time required to transfer that much data over USB increased. At this point NVIDIA started generating a sparse image, and flashing with this. The two methods have the same result, but if the sparse image is something like 10% of the size of the raw image, then the time to flash drops to 10% (at least for USB data transfer time). This means that generating an image on the host PC adds the size of both the raw and sparse partitions to what it must store before flashing that partition. Should the data on the partition nearly fill the partition, then the host PC disk space requirement can approach twice the size of that partition. A nearly full 64 GB partition would take up about 128 GB of space on the host PC.
There will also be temporary file content, which isn’t particularly significant most of the time.
Commercial Jetsons from third parties with their own carrier board design probably require different firmware, and thus they might provide patches to NVIDIA flash software, or they might rebrand the NVIDIA flash software, but the space requirements will be very close to the same.
Which Jetson model? Which JetPack or L4T version? How large is the o/s (rootfs) partition?
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.