Problem with 16GB storage space when install ing Jetpack 4.4.1 with SDK Manager. I have Production Nano module (with eMMC).
what’s your use-case, may I also know all the packages you had installed to the Nano?
I have fresh started SDK manager (deleted all Jetpack folders and reinstall sdk manager) to program a production Nano with our custom carrier through the Recover port, see SDK screen capture. After flashed the OS the SDK stated low disk space (not sure the exact message). After continue with the flashing, the Nano (target) have only ~300MB left. Could you help? I remembered that jetpack 4.4.1 used to give me 2GB of space after completed this flash.
you should remove some SDK components, or, please add external storage.
We will have an SD card and I can install our app on it. Which component can I remove to create more disk space? Also, are there descriptions for folders/files that would help me to know what can be deleted?
Thank you for your supports!!!
you’re able to deselect those “Jetson SDK Components” to trim the image size.
Just wanted to add that you can still use JetPack/SDKM to add those components at a later date (not during initial flash)…you’d simply start the Nano fully booted instead of being in recovery mode, and you’d uncheck everything but adding those components.
If you do install such that you have room, and then add a new storage device (regardless of whether it is SD card, USB storage, so on), and mount this on “
/usr/local” (after copying any existing content to your new storage), then any addition of optional components at this later date which happen to be in the subdirectory would result in space being used with this other storage device. It wouldn’t fill up eMMC. Just beware that if it is a removable device, then you probably need to mount it such that if the device is missing it won’t stop boot.
Thank you both for your helps. Could you let me know if my thought processes are correct by:
- Flash Jetson OS only using SDK manager after rebuild the kernel and image for enabling an SD card.
- Mount sd card as usr/local and move all files from usr/local of eMMC to the sd card
- Use SDK manager to install other Jetpack components.
- For duplicating to another Nano SOM and custom carrier board, copy image of this SOM and Sd card.
This might be less complicated. Is it correct that this is an eMMC model? If so, and if it has another storage method (looks like SD card), then there is probably no need to build any kernel. If this is a third party carrier board (and by definition an eMMC model would probably always use a third party carrier board), then the manufacturer of that carrier board would provide flash software which takes into account any modifications of device tree and leave any SD card slot usable.
On the other hand, if this is an SD card model (a dev kit), and if you have some other storage device (e.g., USB storage), then you would also not need to build any kernel.
Can you give more details about your carrier board and module, e.g., SD card dev kit versus a separately purchased eMMC module and carrier board?
In cases where your system already runs, and where you are willing to offload just “
/usr/local” instead of everything, then it is trivial to copy content from the existing “
/usr/local” to the alternate storage, and then mount this storage on “
/usr/local” (which happens to be where the largest of NVIDIA dev content resides).
Thank for looking into this. It is a Nano eMMC module with our custom carrier board, which will needs custom kernel and pinmux for SD card enable. Will the process below work, especially the 4th step?
- Flash Jetson OS only using SDK manager after rebuild the kernel, pinmux and image for enabling an SD card.
- Move all files from usr/local of eMMC to the sd card and mount sd card as usr/local.
- Use SDK manager to install other Jetpack components (I need CUDA for camera).
- For production units (more Nano and custom carrier board), create and copy the image of this SOM and this SD card to another SOM and SD card.
Correct. Whatever makes your carrier board and peripheral I/O work needs to be in place.
Technically you only need to copy instead of move, at least while testing. As long as you haven’t installed the extra content which takes too much space there won’t be much to copy yet.
Correct. With the SD card partition mounted at that location any install of such components will be to the SD card and will leave eMMC alone. There is of course some metadata on eMMC, e.g., the
dpkg mechanism notes the package is installed, but this is a very tiny amount of space.
Yes. As long as the version installed to eMMC (the metadata) matches what is on the SD card partition (which is mounted on “
/usr/local”), then it should “just work”.
Caution: Removable media, if told to mount in a specific location, should be mounted such that mount failure won’t stop boot. This means that if someone forgets to insert the SD card the system would still boot. There are some “best practices” for the “
/etc/fstab” entry I will suggest below.
You might also have an issue with auto mount trying to mount the partition. You can disable this auto mount via compressing the config file, and if you want to add it back in later, then just decompress this file. Modifications would be needed if you want auto mount to continue for other auto mount content except for your SD card. On the other hand, many people won’t care about auto mounting content, so in that case:
sudo bzip2 /etc/udev/rules.d/99-nv-ufs-mount.rules
(which turns this into “
99-nv-ufs-mount.rules.bz2” and effectively disables it)
About best practices in auto mounting the SD card: You should provide some details as to how you are partitioning this, and whether you want to name this based on a device or if instead you want to name this by a partition ID. Often a partition ID is the best way to go, but in production you might just name the device. A device will always be there no matter which SD card is plugged in (so long as it is partitioned and formatted), but a UUID requires more information.
A basic line in “
/etc/fstab” which won’t fail upon boot when the partition is not present is something like this (several variations available, but I’m assuming here that the partition to be mounted is “
/dev/mmcblk1p1”…adjust for your case):
/dev/mmcblk1p1 /usr/local ext4 rw,suid,dev,exec,nofail 0 0
The important part in the above is “
nofail”. This is the option which means that if no such device is found upon boot, then to continue on without it.
Thank you for clear explanation especially caution section. The SD Card is non removable of this design.