Hi,
I recently flashed my TX2 board with the latest jetpack. After successful flashing, I was trying to download a software that I need but there is no space in the home directory. Can someone help me with this.
By default a Jetson uses a single partition for home and “/”, so it sounds like the system filled up and no longer boots. Is this correct (the below assumes this)?
FYI, logins often require generating temporary files, and if no space is left, then login may become impossible. The form of login which requires the least resources is the serial console, and this logs in by default. If you can reach this, then you will be able to delete some files and then boot normally. For information on serial console, see:
http://www.jetsonhacks.com/2017/03/24/serial-console-nvidia-jetson-tx2/
If you still cannot log in to remove files, then you will likely end up cloning, removing extra files on the loopback mounted clone on the PC, and then flashing again (but using the fixed clone instead of the default image). This takes a lot of time and disk space, and will also depend on which release you have for actual procedure. You can clone from an incorrect release, but the flash itself must be a match to the release which originally flashed the clone.
Hi ,
Thanks for the advice but the system is booting up. But after that I cannot download any files.
What do you see from the commands:
df -H /
df -i -H /
Hi ,
Please find below the commands output.
shiva@shiva-desktop:~/VisionWorks-SFM-0.90-Samples$ df -H
Filesystem Size Used Avail Use% Mounted on
/dev/mmcblk0p1 30G 28G 139M 100% /
none 4,1G 0 4,1G 0% /dev
tmpfs 4,2G 44M 4,1G 2% /dev/shm
tmpfs 4,2G 22M 4,1G 1% /run
tmpfs 5,3M 4,1k 5,3M 1% /run/lock
tmpfs 4,2G 0 4,2G 0% /sys/fs/cgroup
tmpfs 825M 13k 825M 1% /run/user/120
tmpfs 825M 119k 825M 1% /run/user/1000
shiva@shiva-desktop:~/VisionWorks-SFM-0.90-Samples$ df -i -H
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/mmcblk0p1 1,9M 175k 1,7M 10% /
none 997k 1,1k 996k 1% /dev
tmpfs 1,1M 35 1,1M 1% /dev/shm
tmpfs 1,1M 4,0k 1,1M 1% /run
tmpfs 1,1M 5 1,1M 1% /run/lock
tmpfs 1,1M 18 1,1M 1% /sys/fs/cgroup
tmpfs 1,1M 23 1,1M 1% /run/user/120
tmpfs 1,1M 71 1,1M 1% /run/user/1000
You have a very slight amount of space left. Since you are able to access to run df, are you able to delete more files? If you are able to open up to about 15% this would mostly guarantee that login won’t be an issue (at least not from lack of disk space).
FYI, you have i-nodes with 10% left, and the root partition has less than 1% left (139MB). So i-nodes are not an issue and block size is already at a reasonably efficient size. Any large file delete would be particularly useful.
One thing to consider, if you have this TX2 able to use an SD card or SATA hard drive, is perhaps moving your “/usr/local/" content onto an external device (ext4 format), deleting the original "/usr/local/” content, and then mounting that device partition with the copy on “/usr/local/”. You’d open up space for the operating system itself.
Hi,
Thanks for your help. Can you please help me with how to mount the external device partition with the copy on “/usr/local/”.
What kind of storage device is it? SATA drive? SD card? The basics are that you would create a partition, and then run “sudo mkfs.ext4 /dev/whatever_it_is1” for the first partition (without the “1” it is the whole disk, not a partition), and test if it can be manually mounted via:
sudo mount /dev/whatever_it_is1 /usr/local
sudo umount /usr/local
If that works, then you can do the file copies and mount setup. Have you formatted the device yet? Which device is it?
Hi,
For now I am using a USB
Hi,
Now I am using a SD card. I have formatted the device for linux use only.
What partition does this show as on the Jetson? Probably “/dev/mmc1blk1”, but you will want to confirm this.
Noting ahead of time that when you mount this partition at mount point “/usr/local”, the content on the eMMC will still be there, and yet be unavailable until umount. Basically you will be mounting the empty SD card partition somewhere else, copying everything over as root, making sure that this mounts as a duplicate, then remove the content on “/usr/local”. You will need to be certain that the SD card copy works first, and that during the removal of eMMC content on “/usr/local” the SD card is not mounted. Then you will add rules to mount the card there without blocking boot should the card be missing.
There may be automount software getting in the way, and this usually tries to mount removable media somewhere in “/media”. If this is the case, then start by “sudo umount /dev/mmcblk1p1” (adjust if this is the wrong device name for you).
Then you will mount this at a preferred temporary mount location:
sudo mount /dev/mmcblk1p1 /mnt
Run “df -H -T /mnt” to verify the correct device is there, and that it is type ext4. If you do not have “rsync” (run “which rsync”), then add this package:
sudo apt-get install rsync
Now copy all files to the SD card on “/mnt” (rsync understands file types and permissions and should do “the right thing” in cases where “cp” will not). I am going to write this as multi-line, where the backslash "" causes this to continue on the next line and make it all a single line before execution. This is because there will be lines you want to edit and it becomes clearer. The command goes something like this:
# This is "show me what it would do", and only names what would be done without actual execution...this is for
# testing before proceding (you can leave out the log file if you want, I use this to verify what was done). The "--dry-run" is what causes this to "not really" do the copy.
sudo rsync -avcrltxAP --info=progress2,stats2 --delete-before --numeric-ids \
--log-file=log_rsync.txt \
<b>--dry-run \</b>
--exclude '.gvfs' \
--exclude 'lost+found' \
<b>/usr/local/* /mnt/</b>
Now if you check the log_rsync.txt (from the directory you were in as you ran the rsync…make sure you were not actually in “/mnt” or “/usr/local” at the time you ran the command), you should see that any content in “/usr/local/” was named. Now if you remove the “–dry-run”, and run this again, the content will actually be copied to “/mnt”…which happens to be your SD card since you mounted this (and tested with “df -H -T /mnt” to see it was truly mounted there).
Then browse “/mnt” and see if all content exists exactly the same as when you browse “/usr/local”. If this is the case, then you can run “sudo umount /mnt” to umount the SD card. You’ll then see if you can manually mount to “/usr/local/” and have essentially no difference:
sudo mount /dev/mmcblk1p1 /usr/local
cd /usr/local
# Examine or browse around.
ls
# Exit this location.
cd
umount /usr/local
At this point, if all has gone well, then you have a copy of “/usr/local” and could delete the real "/usr/local/* content (don’t do that just yet, you’re going to set up mount first).
You will run “lsblk -f /dev/mmcblk1” and have it list the UUIDs of the SD card. Copy that UUID for the partition (the device as a whole might have a UUID, but the mmcblk1p1 partition is what we are interested in), which we will be using in a file edit.
Assuming the device has UUID “01234567-abcd-0123-abcd-ef0123456789” (I made this up, you have to substitute with the actual partition ID), you will edit “/etc/fstab” (any editor run as root, e.g., “sudo nano /etc/fstab”). The first time we edit will make the SD card mount optional so it won’t hang on boot if the SD card is not found (for example, perhaps you want to use a different SD card for some purpose):
# Somewhere near the end of the file (you can add extra spaces between fields to make it align and look nice if other lines are found):
UUID=01234567-abcd-0123-abcd-ef0123456789 /usr/local ext4 noauto,user 0 0
With this in place you can do this without naming the actual SD card partition:
sudo mount /usr/local
ls /usr/local
sudo umount /usr/local
If this works, then you could stop here, and manually insert the card and “sudo mount /usr/local” if the card is present (be sure to “sudo umount /usr/local” before you remove the card). You should be able to replace “noauto” with “nofail” if you want the partition to automatically mount, but to not call it an error if the SD card is not present:
UUID=01234567-abcd-0123-abcd-ef0123456789 /usr/local ext4 <b>nofail</b>,user 0 0
This does not name the device to backup software, and also does not attempt to filesystem check. The first “0” within “0 0” on the end of the line says “this is not to be dumped by backup software”, and the second “0” of the “0 0” says don’t filesystem check. You’d always check the root partition prior to extra partitions, and so it is a good idea to mark this as something filesystem check in case of troubles, but to do so after the rootfs. If all has gone well up until now, then the final form you will pick for the line in “/etc/fstab” is this:
UUID=01234567-abcd-0123-abcd-ef0123456789 /usr/local ext4 <b>nofail</b>,user 0 <b>2</b>
As a result of this you should find that if the SD card is present during boot, that it mounts with a perfect copy of the old “/usr/local/” via SD card of that UUID. If the card is not present, or if a card of a different UUID is present, then the system should not hang up waiting, and the other SD card should behave as any normal SD card.
Finally, if all is good, and you are brave (meaning you believe the SD card has everything and is mounting correctly), then make sure that you “sudo umount /usr/local” to avoid the SD card itself being deleted, and then:
cd /usr/local
# Make sure you are really there:
pwd
sudo rm -Rf *
cd
# Then reboot with the SD card present, or insert the card and "sudo mount /usr/local".
At this point everything there (the bulk of CUDA development and packages) will go on the SD card instead of the eMMC. Run “df -H” to make sure “/usr/local” shows up, and note “/” now has a lot more free space.
All of this is interchangeable between SD cards and SATA disks. All that changes is the identification of the device, e.g., something like “/dev/mmcblk1” might instead become “/dev/sda”, and the first partition might be either of “/dev/mmcblk1p1” or “/dev/sda1” on the Jetson. Just be very very aware to pick the right identifier when you do some destructive operation to data which names those devices.
Hi,
I followed the steps you told.
After writing the UUID in /etc/fstab when I tried running sudo mount /usr/local after inserting the SD card I got error saying
mount: /usr/local : /dev/mmcblk2p1 already mounted on /usr/local
Can you tell me howto resolve this.
In that case you only need to manually umount first, then try mount again:
sudo umount /usr/local
sudo mount /usr/local
If the card is inserted and the settings are correct, then the system will end up mounting the card automatically. The real goal is to make it so the card mounts correctly and automatically when present, at least during boot, and to not block boot when the card is missing. Should the card be auto mounted there, then you are ok so long as the system does not hang without the card during boot.
If you want to force the SD card to only mount when you tell it to, then change the “nofail” to be “noauto”. Auto mount needs to be told it is not a failure to not have the SD card, but in the case of manual mount (and “noauto” causes manual mount only) there is no issue with boot being blocked with a missing SD card.
Note: Always be sure to umount the SD card partitions before pulling the SD card out (and certainly if power is off the card has been umounted).