Because EMMC (16G) has installed the system and CUDA related packages, there is less space left. I want to install the system and related software packages such as CUDA on the SD card in EMMC of NX. How can I achieve this partial installation?
Because EMMC (16G) has installed the system and CUDA related packages, there is less space left. I want to install the system in the EMMC of NX. How to achieve partial installation of CUDA and other related software packages installed on the SD card?
The best way is to use an NVME M.2 SSD for system storage. NVME SSDs are MUCH MUCH faster than eMMC and SD and have way more write/erase cycles.
SD cards are often unreliable as system storage as many Raspberry Pi users will tell you.
Thank you for your reminder，Due to current hardware limitations, CUDA related software can only be stored on an SD card. Is there any way in that case
You can mount your SD card into an empty directory, move folders from the EMMC to that directory and put a symbolic link from the old location to the new location. However, the SD card is mounted later in the boot process, so you can’t move things that are essential for booting. Plus you will notice that your system will become slower.
Is it correct that this is an eMMC model which also has an SD card slot? In that case it would imply that the SD card slot is on the carrier board, and not on the module itself.
If that is the case, then just format the SD card as ext4, and then mount this on “/usr/local” after copying any existing content from “/usr/local” to that. Mount using the “nofail” option. Does this sound like what you are interested in? All content of “/usr/local” would then be on the SD card. If the SD card is not mounted there, then whatever was originally there would reappear. The “nofail” option would leave the system working without the SD card.
Thank you, I will try to do it according to your method
Yes, there is EMMC. There is also an SD card slot on the motherboard. There are no slots for SSD. Only install the system on EMMC. Put other related AI and CUDA tools on the SD card. Free up some space for EMMC to users.
The method you mentioned should be what I want, and I will try it. But I still want to ask: regarding my situation. Is there a way for NV to directly install AI and CUDA related tools onto the SD card?
No. The filepaths are set in the software packages, and they need to be correct. The size of the Xavier NX’s eMMC is a nuisance, I know.And relocating directory trees and putting in links is cumbersome, I know, and it reduces reliability. For a real product I’d strongly suggest switching to Orin NX and using an external SSD, even if this means another PCB revision. Only then will you get newer Jetpacks.
For this situation, understand that the CUDA content normally goes into “/usr/local”. For this case, which is the simplest case, if you mount an ext4 partition from the SD card onto “/usr/local”, then you will no longer see the old content (but the content will still be there after umount). If you copy the old content to SD card, then mount that at “/usr/local”, then you won’t see any difference, but new content now goes to the SD card instead of eMMC. A similar story/scheme is sometimes useful for mounting “/home”.
I am going to assume your SD card is “/dev/mmcblk1” (the eMMC will be mmcblk0), and that the first partition on that device (mmcblk1p1) is your SD card partition. Be very careful to use the correct designation because you will destroy content if you use the wrong partition designation.
Most SD cards come with a VFAT partition type, and I will suggest changing it to ext4:
sudo mkfs.ext4 /dev/mmcblk1p1
Start by manually mounting this on a temp location:
# If already automounted, then:
sudo umount /dev/mmcblk1p1
# Mounting on a traditional location:
sudo mount /dev/mmcblk1p1 /mnt
Next, do a recursive copy of “/usr/local” to that partition. I use rsync in this case due to some of its intelligence, plus the option “--dry-run” can “fake” the action and simply show you what it would: do if it were not a dry run. Any of the commands below with rsync will be shown first with --dry-run, and then without:
cd
sudo -s
# I've separated this into lines to demo how to exclude a directory, especially "lost+found/":
rsync -avcrltxAP --info=progress2,stats2 --delete-before --numeric-ids \
--dry-run \
--exclude '.gvfs' --exclude 'lost+found' \
/usr/local /mnt
# If that seems to be correct, then run the actual command:
rsync -avcrltxAP --info=progress2,stats2 --delete-before --numeric-ids \
--exclude '.gvfs' --exclude 'lost+found' \
/usr/local /mnt
exit
Note that this rsync can be used for incremental backup to. For example, a few months from now you might have added something to the eMMC’s /usr/local, and want to copy it to the SD card. Just run the same command again. The inverse is also possible, you could modify the SD card, and then later copy a portion to the eMMC when the SD card is not mounted there. One can easily exclude specific content.
Now to test this be certain that this is not already mounted:
# Either of these:
sudo umount /mnt
sudo umount /dev/mmcblk1p1
To mount manually:
sudo mount /dev/mmcblk1p1 /usr/local
Then cd there and see if content still exists. You can also use “df -H -T -t ext4” to see all of your ext4 content and where it is mounted.
Now unmount with “sudo umount /usr/local”. Let’s add it with a nofail option so that it will mount if found, but still work with old content if not found. Edit “/etc/fstab”, and examine something about this file’s content. Example lines to examine:
/dev/mmcblk1p1 /usr/local ext4 defaults 0 4
Note that last column, in this case “4”. This is the fsck order if filesystem checking is needed. You’d order them in mount order. If the rootfs on “/” is “1”, and this is the only other device mounted on top of that device, then you’d increment it by 1 and it would become 2. I’m going to assume you don’t have other “sub devices” on the rootfs eMMC, and will assume “2”. We’ll also make sure this is fault tolerant, which the above line is not:
/dev/mmcblk1p1 /usr/local ext4 defaults,nofail 0 2
VERY IMPORTANT: The “defaults,nofail” has a single comma between tokens. There are no space characters for this column as options of this column are comma-delimited. All other tokens can be separated by any number of spaces or tabs (whitespace) since they are not “compounded lists of comma-delimited options”.
This is now the 2nd fsck device, and it has option “nofail”. What this means is that this device will attempt mounting each boot, but if not able to mount, then boot will continue without this.
At this point you can mount or umount without naming the location. The location will “just work” for either of these:
sudo mount /dev/mmcblk1p1
sudo umount /dev/mmcblk1p1
There are still a possible problems, and that is automounting, or the presence of an SD card which is not intended to mount there. To address this fstab entry to only look at the exact SD card we need to name it via the UUID or PUID. If you run the following command, note that the fourth column (“UUID”) can be used to name that partition:
lsblk -f
In particular, you can find this line since it is mmcblk1p1:
lsblk -f | grep 'mmcblk1p1'
I am going to pretend that the UUID for your SD card is this, but you need to substitute for whatever it really is:
12345678-1234-1234-1234-1234567890bcd
Instead of naming “mmcblk1p1”, a generic first partition of the SD card slot on an eMMC model, let’s edit /etc/fstab to instead name this exact partition:
UUID=12345678-1234-1234-1234-1234567890bcd /usr/local ext4 defaults,nofail 0 2
From now on only the SD card partition with that UUID will be mounted there or even considered for that mount. If you were to reformat this SD card, then the UUID would change and you’d need to edit the fstab again.
Now for the elephant in the room: The automounter might still be mounting this if not stopped. I’m going to mention that there is more than one way to deal with this, and the method can change based not only on distribution, but also on desktop environment. If you need to research this, then this Google search has information:
“ubuntu” how to stop sd card automount
You might not have an automount interference in which case you can ignore this. Run “df -H -T -t ext4” (assuming this is ext4 partition type and not vfat) before manually mounting or unmounting to see if something has already mounted the SD card.
Although this is the udisk2 service, it is generally dconf which is used to edit settings. The command line is not so convenient, but you can install the GUI version of this if you have a GUI desktop handy:
sudo apt-get install dconf-editor
You can disable automount in org->gnome->desktop->media-handling.
For command line of automount disable:
gsettings set org.gnome.desktop.media-handling automount false
(or use “true” to enable)
One can set “noauto” in fstab for a partition, but I don’t think you want to add all of your SD cards to fstab…I don’t know how to tell it to “not automount my UUID, but to automount all others”. Stopping an individual SD card partition from automount is easy, but allowing all to automount except for yours is something I did not find information on.
Be sure to reboot and check “df -H -T -t ext4” and see if it is correctly mounted.
If you are happy with this, then you could umount mmcblk1p1 and delete the old content of “/usr/local/*”, but I suggest leaving the old “bin/” and “lib/” directories.
Thank you for solving my problem, but
rsync -avcrltxAP --info=progress2,stats2 --delete-before --numeric-ids \
--exclude '.gvfs' --exclude 'lost+found' \
/usr/local /mnt
This command requires adding a slash '/usr/local//mnt/'. Otherwise, re mounting will add an extra layer of directory.
Yes, rsync tends to require paying attention to details like that. This is why I mention the “--dry-run” option to find those issues prior to an actual sync.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.