Tip: Rootfs Partition Resizing

Thought I’d just pass something along. I was doing a lot of flashes and testing things, and at one point decided to fill the root partition. If the root partition was not already at its maximum size, you might be tempted to use gparted to resize it. You can’t though, because the rootfs partition is the first partition, and there is no free space before the second partition.

So this is how you can do it anyway should you decide you don’t care if it isn’t normally possible and have a lot of free time…

Clone rootfs. Use sudo losetup --find” on the host PC to find the first loopback device. Cover the clone with loopback, e.g., if find shows “/dev/loop1” (I was cloning, else it would be loop0):

ls -l /where/ever/it/is/clone.img.raw
# Find the size of the clone, increase it by the amount you want, and
# make sure the amount is rounded to a multiple of 1024*1024 bytes (this is how the "-S"
# parameter of a flash from scratch would do it). For example, if the original raw file
# is 21474836480 bytes the flash used "-S 20GiB"...20*1024*1024*1024), and to add approximately
# 2GiB more, add 1024*1024*1024*2 bytes, and you get a total size of 23622320128 bytes).
# Resize the .raw file:
truncate --size=23622320128 /where/ever/it/is/clone.img.raw
# Cover by loopback:
sudo losetup /dev/loop0 clone.img.raw
# Pretend loopback is a block device:
sudo gparted /dev/loop0
# resize and save! Remove loopback coverage.
sudo losetup -D
# Note: flash.sh works with either raw files or sparse files as system.img...it doesn't
# care if this is a raw file.
cp /where/ever/it/is/clone.img.raw /where/ever/Linux_for_Tegra/bootloader/system.img
cd /where/ever/Linux_for_Tegra
sudo ./flash.sh -r jetson-tx2 mmcblk0p1
# Your Jetson now uses the resized rootfs without losing anything.

I have many clones for every Jetson L4T, and even some going back to Tegra3 hardware. You can use the same losetup and gparted resizing on clones to reduce them for storage.

You may run into a bug in the flash.sh script where it does not correctly find the loopback device when loop0 is not used…and working with loop devices for resizing might use up loop0. Near line 466 of flash.sh you might want to change it by commenting out one line and adding a new line:

#       local loop_dev="${LOOPDEV:-/dev/loop0}";
        local loop_dev="$(losetup --find)";

Maximum size of a TX1 or TK1: 14580MiB
Maximum size of a TX2: 29318MiB

Thanks @linuxdev, we’ve added a link for your procedure to the wiki from https://elinux.org/Jetson/TX2_eMMC.

Hello

When I do df -h I can see /dev/root gets filled up (currently 68%) as I install downloads I need or when I compile openCV. I already had to re-flash my Jetson TX2 because it was at 100% and start all over again. Is there a way to keep the size acceptable ? Note: I have already done things like sudo apt-get clean, autoclean and autoremove

The maximum partition size, when flashing on command line, is:

sudo ./flash.sh -S 29318MiB jetson-tx2 mmcblk0p1

What do you get from:

df -H /

…the max shows a size of about 31G (base 10, not 1024, so this is actually 29318MiB).

Not all flash procedures default to using all possible eMMC.

I get this

nvidia@tegra-ubuntu:~/Projects/libv2012/build$ df -H
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
/dev/root 30G 17G 11G 61% /
devtmpfs 8,2G 0 8,2G 0% /dev
tmpfs 8,3G 373k 8,3G 1% /dev/shm
tmpfs 8,3G 23M 8,3G 1% /run
tmpfs 5,3M 4,1k 5,3M 1% /run/lock
tmpfs 8,3G 0 8,3G 0% /sys/fs/cgroup
tmpfs 824M 87k 824M 1% /run/user/1001

Note : I have reduced to 61% by cleaning the bin.

So it looks like you already have the largest possible partition size for this case. About the only thing else you can do is add a separate storage device and mount it somewhere like “/usr/local” (which happens to be where most of the CUDA stuff goes).

I wouldn’t recommend it, but if you look at “/var/”, you will see the CUDA repo is a local repository which can be deleted. This means when you use apt to query packages for CUDA the Jetson itself is the repository, and a remote system is not providing this. I cloned an R28.1 TX2 and ran filelight on the loopback mounted clone. This shows the local CUDA repo consumes about 2.2GB of storage. Technically this could be removed if you will not be making any changes to the related software (once the software is installed you might not need the repo…this repo saves every install package for CUDA, not just the ones you’ve installed…the installed packages exist elsewhere).

One option you might consider is to create an ext4 formatted SD card, copy “/var/cuda-repo-8-0-local/" to that SD card (preserving permissions…you’d need sudo), deleting the "/var/cuda-repo-8-0-local/” content, and then mounting the SD card partition with the copy on that directory (I’m using CUDA8 as the example and assumes first partition of SD card is ext4):

sudo -s
mount /dev/mmcblk1p1 /mnt
cp -adpR /var/cuda-repo-8-0-local/* /mnt
umount /mnt
cd /var/cuda-repo-8-0-local
# Be very careful! You must be in the right place when you do this...
rm -Rf *
cd
mount /dev/mmcblk1p1 /var/cuda-repo-8-0-local

You would then have to mount the SD card there to use apt-get with any of the CUDA packages.

Hi all,

How I can create and extra partition in EMMC memory? I am wondering if Can I resize system.img.raw file (i.e sudo ./flash.sh -S 10000MiB jetson-tx2 mmcblk0p1) and after that to increase the size and convert the new free space to a new partition using gparted?

Is there a direct way to create an extra partition in EMMC memory.

If you have some suggestion please let me know.

Thanks.

Is this R28.2? I’m not certain, but what you can do and how you do it might change slightly depending on release.

You can resize system.img.raw while via covering it with loopback (“sudo losetup --find ./system.img.raw”, then look for “/dev/loop0” or whatever number was indicated) and doing the resize on the loopback device as if it is a real hard drive. Don’t forget to detach the loop device after you finish…the flash.sh script itself has a bug in it and it doesn’t correctly detect if loop0 is already in use. See “man losetup” for detaching.

I have not tried splitting the APP partition, there is some risk, but what you want to do should be possible (make a backup of your clone). Logical sector size is 512 bytes, so any changes should be an even multiple of this. Your extra partition will need a new label other than APP.

I’m also not sure which host “bootloader/” config files are overwritten during a flash based on arguments, but look at the “bootloader/flash.xml” file. This lists partitions to be flashed, labels, so on. If you flashed with max size for rootfs originally, then size is 30742151168…this divided by 1024 twice is “29318MiB”. Any changes would need to be 512 byte increments.

Note that if you were to flash with a size of “-S 29318MiB” you’ve used max size APP. If you wanted something like 10GiB reserved, then “1010241024*1024” is 10737418240 bytes. Or in MiB, 10240. You could just resize your system.img.raw to “30742151168 - 10737418240 == 20004732928”, and then flash with the “-r” to re-use the existing image…but put your image in place of “bootloader/system.img”. The flash command would name size 20004732928 (20004732928/1024/1024 == 19078) like this:

# Resize clone, put it in place of "bootloader/system.img". Flash:
sudo ./flash.sh -S 19078MiB jetson-tx2 mmcblk0p1

Once flash finished you could use normal tools (gdisk) to partition the free space.

Hi linuxdev,

Thanks for your help.

Yes, I am using R28.2. I tried to edit the virtual filesystem created by flash.sh and exist in the file ‘system.img.raw’ using those commands

# Cover by loopback:
sudo losetup /dev/loop0 system.img.raw
# Pretend loopback is a block device:
sudo gparted /dev/loop0

Using gparted I can change the partition size but when I try to create a new partition in the unallocated space I get this message:


It is not possible to create more than 1 primary partition
If you want more partitions you should first create an extended partition. Such a partition can contain other partitions. Because an extended partition is also a primary partition it might be necessary to remove a primary partition first

Maybe I should create my own virtual filesystem then I will be able to create another partition and I can flash it with the “-r” to re-use the existing image, in this case an image created by me.

Are you trying to create a second partition on the loopback system? This won’t work, you’d need to create the correct partition size of the image, and make sure the actual underlying file holding the image is the same size (the “truncate” command can be used for this). Then flash using this file as system.img along with a “-S size” parameter matching this. If you use “MiB” units then exact byte size is divided twice by 1024 and this is the MiB. If using “GiB”, then the exact image size is divided three times by 1024 to get GiB. Let the flash.sh script put your resized image on the system and simultaneously do the resizing of leftover space…then once done you can use gdisk to add the new partition.

Example:
Suppose you want your original max size 29318MiB partition to instead be 18GiB. You’d clone this, and then loopback resize under something like gparted to 18GiB (a.k.a., 1810241024*1024 bytes == 19327352832). You’d sync and remove the loopback coverage, then truncate the file ("–size" equivalents: “19327352832”, “18G”):

truncate --size=19327352832 some_clone.bin
mv some_clone.bin /where/ever/Linux_for_Tegra/bootloader/system.img
sudo ./flash.sh -r -S 18GiB jetson-tx2 mmcblk0p1
# login to new boot of Jetson...
gdisk /dev/mmcblk0
# ...add whatever space is available as a new partition.

I understand your idea, we can add the new partition from the Jetson.

In my case I want to check if there is a procedure where I can create the extra partition form the host PC, then I should be able to flash this new memory layout into several TX2 boards without to boot the board and create the partition.

I am wondering if I can create a virtual file system (http://web2.clarkson.edu/projects/itl/honeypot/ddtutorial.txt) with the the memory layout required and with a size of 29318MiB
The first partition will have the Nvidia rootfs and a second partition will be empty with ext4 format.

If I flash this virtual memory using ./flash.sh. For example:

mv my_custom.img.raw /where/ever/Linux_for_Tegra/bootloader/system.img.raw
sudo ./flash.sh -S 29318MiB jetson-tx2 mmcblk0p1

Do you think that it should work? Will I be able to see these partitions after boot the board?

Thanks.

Regardless of how you set up for production I still suggest you test by doing this manually at first to gather knowledge. A weakness of the current generation of flash software is that it isn’t able to flash the entire eMMC based on a starting address (the older TK1 could read/write any address span, current flash software seems to require a partition name and individual partitions…the old flash for TK1 had a target “all” or target purely via offset and span).

Keep in mind you’ll probably want a partition label and a test of whether it works as is. Once you have this you can clone that partition as a “.bin” file and name it in the flash.xml as a new partition. You will want to preserve all existing partition layout and naming information, and if you’ve added this new partition originally from within a running Jetson, then you’ll know this has been preserved. It is a test environment.

If you use “-r” and reuse with the 29318MiB it might work, but the Jetson itself seems to understand file systems (it can convert from sparse to raw), and so I can’t guarantee the end of partition won’t cause the flash to stop there as well…there is no harm in trying, just reflash if it fails. If you test flash.sh and do not use the “-r”, then you will overwrite your work and need to start over if you don’t have a backup image. “system.img” is regenerated every time if you don’t use “-r”. Copy to system.img.raw won’t matter as this is not the file flashed…system.img is. The Jetson is smart enough to know the difference between raw and sparse, the file name has nothing to do with formats.

FYI, there is a mksparse program which is used to convert a raw ext4 image to a sparse image. If you like your image, then you can use this with NULL character padding should you need to switch to mass flash with flash time reduced. Non-sparse will just take longer. Once the image is raw it cannot be converted back, the format differs from open source raw-to-sparse-and-back-to-raw format conversion.