SD card size loss after flashing?

Hello,

I recently bought a 128GB SD card to get some more space for my NX devkit.
However, using flashing via both the SDK-manager (v1.2, JP4.4) or Etcher from the official .img (latest) file seems to result in a single ~15GB disk image. After flashing the OS, I can confirm the rest of the space is there somewhere using fdisk:

Disk /dev/mmcblk0: 116,1 GiB, 124688269312 bytes, 243531776 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 0B8C5F43-6E1A-4B56-BEB0-E95E7C068375

Device             Start       End   Sectors   Size Type
/dev/mmcblk0p1        40  29360167  29360128    14G Microsoft basic data
/dev/mmcblk0p2  29360168  29491239    131072    64M Microsoft basic data
/dev/mmcblk0p3  29491240  29622311    131072    64M Microsoft basic data
/dev/mmcblk0p4  29622312  29623207       896   448K Microsoft basic data
/dev/mmcblk0p5  29623208  29624103       896   448K Microsoft basic data
/dev/mmcblk0p6  29624104  29753127    129024    63M Microsoft basic data
/dev/mmcblk0p7  29753128  29754151      1024   512K Microsoft basic data
/dev/mmcblk0p8  29754152  29754663       512   256K Microsoft basic data
/dev/mmcblk0p9  29754664  29755175       512   256K Microsoft basic data
/dev/mmcblk0p10 29755176  29959975    204800   100M Microsoft basic data
/dev/mmcblk0p11 29959976 243531742 213571767 101,9G Microsoft basic data

First I figured maybe I got scammed, SD card isn’t a true 128GB, but after a series of tests, (F3 and H2testw), I could get the whole ~125GB under a single Ext4 or FAT partition.

Searching the forum, I seem to be alone with this problem. Might be something fishy about the SD card, or the flashed image always enforces a 16GB partition? I could probably mount the remaining ~100GB partition separately as a last resort, but it seems weird.

Did I miss something?
Gabor

Hi,

If you use sdcard image, then below screen would show up in your first boot time.

That did the trick.

In case anyone wants to dig deeper into the how’s and why’s…

When using SDK Manager, the primary boot partition is the first one created, see below:

Device             Start       End   Sectors   Size Type
/dev/mmcblk0p1        40  29360167  29360128    14G Microsoft basic data
/dev/mmcblk0p2  29360168  29491239    131072    64M Microsoft basic data
/dev/mmcblk0p3  29491240  29622311    131072    64M Microsoft basic data
/dev/mmcblk0p4  29622312  29623207       896   448K Microsoft basic data
/dev/mmcblk0p5  29623208  29624103       896   448K Microsoft basic data
/dev/mmcblk0p6  29624104  29753127    129024    63M Microsoft basic data
/dev/mmcblk0p7  29753128  29754151      1024   512K Microsoft basic data
/dev/mmcblk0p8  29754152  29754663       512   256K Microsoft basic data
/dev/mmcblk0p9  29754664  29755175       512   256K Microsoft basic data
/dev/mmcblk0p10 29755176  29959975    204800   100M Microsoft basic data
/dev/mmcblk0p11 29959976 243531742 213571767 101,9G Microsoft basic data

… which makes it annoyingly complicated to extend the first partition with the space of the last one (adress spaces are not continuous… not impossible, but quite the effort).

When writing the .img file, the partition order is different:

Device           Start      End  Sectors  Size Type
/dev/mmcblk0p1  610304 28432383 27822080 13,3G Linux filesystem
/dev/mmcblk0p2    2048   133119   131072   64M Linux filesystem
/dev/mmcblk0p3  133120   264191   131072   64M Linux filesystem
/dev/mmcblk0p4  264192   265087      896  448K Linux filesystem
/dev/mmcblk0p5  266240   267135      896  448K Linux filesystem
/dev/mmcblk0p6  268288   397311   129024   63M Linux filesystem
/dev/mmcblk0p7  397312   398335     1024  512K Linux filesystem
/dev/mmcblk0p8  399360   399871      512  256K Linux filesystem
/dev/mmcblk0p9  401408   401919      512  256K Linux filesystem
/dev/mmcblk0p10 403456   608255   204800  100M Linux filesystem
/dev/mmcblk0p11 608256   608291       36   18K Linux filesystem

… with a large amount of unpartition space right after the first partition (/dev/mmcblk0p1 in my case).
You can either extend the partition yourself (using gparted, fdisk, or parted under Linux, pick your poison) or if all goes well, first time Ubuntu booting will notice the unpartitioned space and lets you configure it.

If you used SDK manager and you don’t mind having two partitions, you can always turn the big partition into a stand-alone bootable partition (and then it shows up as a regular SD card, already mounted on your Jetson).

from somewhere in the forum; adjusted by someone from open source source:

#!/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

for 128 the value s below will need to be adjusted somehow

GPT_SIZE=40
UDA_NEW_SIZE=32

Tested on flashed NXes with sdkmanager

4 Likes

Damn… that’s quite the magic trick. Thanks!