Hi all,
I have a question on how to fully use SD card space.
At first I use the SD card image from NV websit to boot the board. At the first boot, I could choose to use all 128GB of it.
However, when I use Jetpack update and flash it again, only the first 16GB is used and during bootup there is no place to change it (see below).
Did I miss anything in configuring the partition? How should I give all the space to partition 1 just like us the SD card image?
Thank you so much for the help!
hello shua1zh,
may I know which JetPack release you’re working with.
you may try to put APP partition at end offset, then it can be resized according to the SD card capacity.
please generate the SD card image using create sdcard image script; then write that image into the SD card for using.
such script file makes sure to create APP partition at the end of the disk and latest resizing service will take care of resizing to occupy the unallocated memory of the SD card.
please also refer to Topic 73032, and Topic 76807 for similar issues.
thanks
Hi Jerry,
Thank you for the response. I’m using JetPack 4.4 and SDK manager 1.1.0.6343.
I’m very new to Jetson and JetPack. May I know which script should I use to create sdcard image and what need to be modified?
I notice the initial SD card image from website is doing that correctly and automatically.
Thank you so much!
The create-jetson-nano-sd-card-image.sh script does not exist in ~/nvidia/nvidia_sdk/JetPack_4.4_DP_Linux_DP_JETSON_XAVIER_NX_DEVKIT/Linux_for_Tegra.
Apparently the reason for this to happen is to reduce the time to flash. An alternative is to use /dev/mmcblk0p11 the “UDA” paritition as /home.
used sdkmanager cli 1 1 0 63 43
32 gb sdcard got to two 14 gb partitions
why?
the complication here is that after installing cuda components;
the space at the system partition exhausts completely
Filesystem Size Used Avail Use% Mounted on
/dev/mmcblk0p1 14G 13G 366M 98% /
none 3.5G 0 3.5G 0% /dev
tmpfs 3.8G 4.0K 3.8G 1% /dev/shm
tmpfs 3.8G 29M 3.8G 1% /run
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
tmpfs 3.8G 0 3.8G 0% /sys/fs/cgroup
tmpfs 777M 12K 777M 1% /run/user/120
tmpfs 777M 0 777M 0% /run/user/1000
lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
loop0 7:0 0 16M 1 loop
mtdblock0 31:0 0 32M 0 disk
mmcblk0 179:0 0 28.8G 0 disk
├─mmcblk0p1 179:1 0 14G 0 part /
├─mmcblk0p2 179:2 0 64M 0 part
├─mmcblk0p3 179:3 0 64M 0 part
├─mmcblk0p4 179:4 0 448K 0 part
├─mmcblk0p5 179:5 0 448K 0 part
├─mmcblk0p6 179:6 0 63M 0 part
├─mmcblk0p7 179:7 0 512K 0 part
├─mmcblk0p8 179:8 0 256K 0 part
├─mmcblk0p9 179:9 0 256K 0 part
├─mmcblk0p10 179:10 0 100M 0 part
└─mmcblk0p11 179:11 0 14.6G 0 part
zram0 252:0 0 1.9G 0 disk [SWAP]
zram1 252:1 0 1.9G 0 disk [SWAP]
ssh user@remoteip dd if=/mnt/nxdevkit.raw | dd status=progress of=/dev/mmcblk0
resizenx.sh.log (4.1 KB)
The dd allowed to rewrite-on-the-fly the entire sdkdisk to previous state.
30953963520 bytes (31 GB, 29 GiB) copied, 4670.26 s, 6.6 MB/s
trying the resize script once again;
this time using
screen
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
loop0 7:0 0 16M 1 loop
mtdblock0 31:0 0 32M 0 disk
mmcblk0 179:0 0 28.8G 0 disk
├─mmcblk0p1 179:1 0 28.6G 0 part /
├─mmcblk0p2 179:2 0 64M 0 part
├─mmcblk0p3 179:3 0 64M 0 part
├─mmcblk0p4 179:4 0 448K 0 part
├─mmcblk0p5 179:5 0 448K 0 part
├─mmcblk0p6 179:6 0 63M 0 part
├─mmcblk0p7 179:7 0 512K 0 part
├─mmcblk0p8 179:8 0 256K 0 part
├─mmcblk0p9 179:9 0 256K 0 part
└─mmcblk0p10 179:10 0 100M 0 part
sudo fdisk /dev/mmcblk0
Device Start End Sectors Size Type
/dev/mmcblk0p1 40 59857111 59857072 28.6G Linux filesystem
/dev/mmcblk0p2 59857112 59988183 131072 64M Microsoft basic data
/dev/mmcblk0p3 59988184 60119255 131072 64M Microsoft basic data
/dev/mmcblk0p4 60119256 60120151 896 448K Microsoft basic data
/dev/mmcblk0p5 60120152 60121047 896 448K Microsoft basic data
/dev/mmcblk0p6 60121048 60250071 129024 63M Microsoft basic data
/dev/mmcblk0p7 60250072 60251095 1024 512K Microsoft basic data
/dev/mmcblk0p8 60251096 60251607 512 256K Microsoft basic data
/dev/mmcblk0p9 60251608 60252119 512 256K Microsoft basic data
/dev/mmcblk0p10 60252120 60456920 204801 100M Microsoft basic data
However, there still seems something missed; resize2fs will throw out permission error. probably force unmount might resolve
The issue with the partition at NX devkit has been resolved in three turns:
sudo su && echo u > /proc/sysrq-trigger
umount / && e2fsck -y /dev/mmcblk0p1 && reboot
resize2fs /dev/mmcblk0p1
resize2fs 1.44.1 (24-Mar-2018)
Filesystem at /dev/mmcblk0p1 is mounted on /; on-line resizing required
old_desc_blocks = 2, new_desc_blocks = 4
The filesystem on /dev/mmcblk0p1 is now 7482134 (4k) blocks long.
root@nx1-desktop:/home/nx1# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mmcblk0p1 29G 12G 16G 44% /
none 3.5G 0 3.5G 0% /dev
tmpfs 3.8G 4.0K 3.8G 1% /dev/shm
tmpfs 3.8G 29M 3.8G 1% /run
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
tmpfs 3.8G 0 3.8G 0% /sys/fs/cgroup
tmpfs 778M 12K 778M 1% /run/user/120
tmpfs 778M 0 778M 0% /run/user/1000Modifying ROOTFSSIZE during flash.sh will make flashing too slow over USB 2.0 link.
I rewrote the script above, with two main changes (14->11 partitions, and retaining the 11th UDA partition):
#!/bin/sh
set -ex
GPT_SIZE=40
UDA_NEW_SIZE=32
move_part() {
name=$(sgdisk -i $1 /dev/mmcblk0 | grep "Partition name" | cut -d"'" -f2)
typecode=$(sgdisk -i $1 /dev/mmcblk0 | grep "Partition GUID code:" | cut -d' ' -f4)
guid=$(sgdisk -i $1 /dev/mmcblk0 | grep "Partition unique GUID:" | cut -d' ' -f4)
sgdisk -d $1 -n $1:$2:$3 -c $1:"$name" -t $1:"$typecode" -u $1:"$guid" /dev/mmcblk0
partprobe /dev/mmcblk0
}
read DISK_SIZE </sys/block/mmcblk0/size
START=$((DISK_SIZE-GPT_SIZE-UDA_NEW_SIZE))
move_part 11 $START $((START+UDA_NEW_SIZE-1))
for i in $(seq 10 -1 2); do
dd if=/dev/mmcblk0p$i of=part$i.img
read size </sys/block/mmcblk0/mmcblk0p$i/size
START=$((START-size))
move_part $i $START $((START+size-1))
dd of=/dev/mmcblk0p$i if=part$i.img
rm -f part$i.img
done
move_part 1 $GPT_SIZE 0
sgdisk --move-second-header /dev/mmcblk0
resize2fs /dev/mmcblk0p1