I’m using Jetson TX2 but now I got only 6G left in /dev/mmcl.
I want to expand the storage using sd card.
And I’ve already done partitioning and formatting except mounting.
Could it occur any problems if I enter “sudo mount /dev/mmcblk2p1(sd card) /dev/mmcblk0p1”?
I’m not used to using Ubuntu…please help.
hello lionmini,
you cannot mount your sdcard to mmcblk0p1 since it’s APP partition.
for example,
$ ls -al /dev/disk/by-partlabel
...
APP -> ../../mmcblk0p1
you may insert your SD card to Jetson device, and it should automatically mount it to /media/ for your usage.
thanks
It is far simpler to add a partition to some mount point where you do the actual work. As an example, most of the CUDA content is at “/usr/local”. Much of what you do is probably in your home directory. One could create a partition and copy the current “/usr/local/*” to it, and then mount on “/usr/local”, or you could create a partition and copy your current “/home” to it, followed by mounting that partition on “/home”. Where is most of your work at? How big is the SD card?
Booting all of the root partition from SD would probably be slower, and would definitely be more painful (it can be done though if you really want to).
Thanks for your reply, JerryChang.
As you said, I can see ‘/dev/mmcblk2p1(sd card)’ is automatically mounted to ‘/media/user/~~~’.
So is there no way to expand ‘/home’ or ‘/usr/lib’ using sd card?
I tried to mount '/media/user/’ to ‘/home’ but it says "/media/user/~" is not a block device.
Thanks you, linuxdev.
I really appreciate your advice.
But I got a problem.
I found that ‘/dev/mmcblk2p1’ is already mounted to ‘/media/user/~~~~’ automatically.
After that, I copied ‘/home’ to ‘/media/user/~ ’ and then 'sudo mount /media/user/ ~/home /home’ as you said.
But there was an error >> “mount: /home: /media/user/45383464-e6f4-471b-a0a2-6d8348c4a42e/home is not a block device.”
P.S.
[ storage usage ]
Before you go too far, let’s make sure the actual filesystem on mmcblk2p1 is ext4. For now it is ok that this mounts somewhere else, especially since you’d need to copy content over anyway before placing it on top of a new mount point. What do you see from the following:
lsblk -f /dev/mmcblk2
sudo gdisk -l /dev/mmcblk2
If this is a valid GPT partition (and very likely it is) of type ext4 (unless you formatted this, it will not be ext4), then you can proceed to add content using something like rsync, or perhaps even just recursive copy (rsync tends to be a lot safer and there are fewer corner cases of failure due to odd content). Then it is a simple matter to set it up to mount where you really want it mounted.
Do not attempt to simply mount it, you’ll need some preparation. What do you see from those commands above?
The screenshots are cutting of part of the information. Even for the lsblk output where the picture can be enlarged it would be best to be able to reply to you by my own copy and paste of the UUID, but I cannot do that with an image. You could just mouse copy and paste instead of screenshots if you use ssh to connect to your Jetson…the ssh terminal on a host PC can be copied and pasted directly to your browser without any screenshots being needed.
If you want to log those commands instead, directly on the Jetson, without any mouse involved:
lsblk -f /dev/mmcblk2 2>&1 | tee log_lsblk.txt
sudo gdisk -l /dev/mmcblk2 2>&1 | tee log_gdisk.txt
(which would create two log files which can be attached to the forum thread)
Then, based on what is there, we can show an edit to “/etc/fstab” to mount where you really want this mounted.
Hi, linuxdev
Here’s what you want.
log_lsblk.txt (251 Bytes)
log_gdisk.txt (888 Bytes)
Mounting for “/” is an extreme difference, and I won’t be covering that. I will be assuming you are backing up “/usr/local” to this partition, and then replacing the original content with that partition. This could easily be “/home”, which is a minor edit. Mounting to “/usr” should be avoided (same issue as replacing “/”).
Your partition is already formatted as ext4, so you can go straight to updating the partition and changing its mount point.
With the partition at its auto mount point of “/media/user/45383464-e6f4-471b-a0a2-6d8348c4a42e”, you could back up directly to this from “/usr/local” like this:
cd /usr/local
sudo -s cp -adpR * /media/user/45383464-e6f4-471b-a0a2-6d8348c4a42e/
Then verify content of “/media/user/45383464-e6f4-471b-a0a2-6d8348c4a42e” looks like it matches “/usr/local”. Be sure to use “ls -AF” in your comparison because you want to see “dot files” (files starting with “.”).
Now umount the existing media mount:
sudo umount /media/user/45383464-e6f4-471b-a0a2-6d8348c4a42e
Test mount to overlay on top of “/usr/local” (the old content will still be there, but will be inaccessible until umount):
sudo mount /dev/mmcblk2p1 /usr/local
See if you see the content just as it used to be, but verify this is mmcblk2p1 via “df -H -T /usr/local”. It should say it is ext4 /dev/mmcblk2p1 mounted on “/usr/local”, and the available space should be based on the SD card partition size.
Assuming that went well, we will add an entry into “/etc/fstab” which makes it possible to mount the SD there, but won’t automatically invoke this, and does not make it mandatory that the card be present for boot. Add the following line to “/etc/fstab” (you are free to add spaces between fields to make a nice “table” if you want):
UUID=45383464-e6f4-471b-a0a2-6d8348c4a42e /usr/local ext4 noauto,nofail,rw,suid,dev,exec,nouser,async 1 2
The first field identifies the source of the mounted data. UUID is specific to that SD card partition. If you use another SD card, then it won’t see this entry as applying to it. You could say “/dev/mmcblk2p1”, but then boot would assume that SD card partition every time regardless of whether or not it is the wrong partition.
The second field is where it will mount.
The third field is just the filesystem type.
The fourth field is interesting. There is normally the key word “defaults”, but I separated it into its multiple options which defaults is an alias for. The “noauto” means the system will not automatically mount this, which is the reverse of what defaults would do. The option “nofail” is quite important here, and also differs from defaults. If there is an attempt to mount this partition, and the mount fails, then the system will continue without blocking on the failure. This means that if the SD card is present, then mount will proceed normally, but if the card is not present, then the system will ignore the missing card and continue.
The next field is just a marker for backup and restore software. It is unlikely to matter, but “1” implies that if a backup operation is attempted, then the SD card partition will be backed up.
The last field is related to the order of filesystem repair should the system be shutdown incorrectly, and then repair is needed. The first repair would always be the system on “/”, and this would be “1”. We are marking the SD card for any repair to occur after “/” by setting it to “2”. Not really something to worry about.
With the SD card not mounted (“sudo umount /media/user/45383464-e6f4-471b-a0a2-6d8348c4a42e”), then you can now test manual mount:
sudo mount /usr/local
sudo umount /usr/local
…notice how you don’t need to label the source anymore.
If you reboot, then you would once more need to “sudo mount /usr/local”. If testing works, then you can edit that fourth field, and remove “noauto”. Each reboot with the SD present should mount there. Each reboot without the SD should proceed normally, but ignore the mount step.
If your SD is mounted, then its content replaces “/usr/local”. If the SD is not mounted, then the original content shows up again.
If you really need more space for “/”, then you could umount “/usr/local”, and the recursively delete “/usr/local/*”. Be very very careful to delete the right content, and to delete only after your SD is verified. Example:
sudo -s
umount /usr/local
cd /usr/local
rm -Rf ./*
cd
mount /usr/local
# Examine content
exit
The same thing could be performed for “/home”. You could split the SD into two partitions, and mount on both. I recommend leaving original “/home” content, and that way if the card is gone, then you have a backed up earlier version of “/home”. Similar for “/usr/local”, but less dangerous to lose the content. If you are now writing to the SD card, then there isn’t much reason to remove the old original eMMC content…you won’t be using more space and so it is ok to leave what is there, it is the SD card which will fill up after this. You could in fact on occasion recursively copy from the SD card as it changes into the original eMMC as a sort of backup system.
If you clone the TX2, then the SD card content will not clone. The eMMC content will clone. Any interest in cloning the SD card is a separate step.