Can this be done through Ubuntu like a Raspberry Pi using raspi-config? Or is a complete flash of the eMMC required for full 16GB capacity? I don’t know about anyone else, but my disk usage is as follows: size: 12GB, used: 5.1G, avail: 6.1G
I don’t know about non-destructive resizing, but just FYI, when flashing to R19.3 I found “-S 15GiB” failed but “-S 14GiB” worked. Info on flash.sh says this “-S” is only for the rootfs, but there are other partitions consuming space as well, so max use has to take that into account.
Personally, I’d like an option which simply makes rootfs use all it can. I don’t think the Jetson is queried for size available though, because flash.sh blindly builds system.img which is a loopback mounted file system of the exact size of the rootfs partition…pre-built before flashing begins (system.img, if loopback mounted, could actually serve as a cross-compile environment of the complete system). Once system.img is created, it copies the loopback mounted version over to Jetson. Copy happily starts even if the system.img is too large or can’t be loopback mounted.
The “parted” disk partitioning program does exist on the Jetson itself, and in theory should work with GPT partitions to resize…however, just printing information from parted says it has an unrecognized disk label. This in itself might be a bug in how flash.sh partitions, e.g., it might not update a checksum even though the system can use the partitions without that. If we could find out why parted does not like the disk label, parted could probably resize.
Can anyone comment on “parted” and causes of this application not being able to read the disk label?
Is it safe to use gparted to expand the filesystem to unused space on the eMMC?
Would I just delete each unknown partition?
No to delete.
The flash.sh -K 6 option in particular, used for kernel flash when using fastboot, places the kernel in one of those “unknown” partitions (partition 6, mmcblk0p6). gparted does not know what is there, but it doesn’t mean it isn’t used. The L4T image is in mmcblk0p1. When not using fastboot and instead using u-boot, it is quite possible that something still uses a byte offset which relies on those first partitions…unused space might be part of what starts something at an exact byte offset.
It is “possible” that after the mmcblk0p6 partition, even under fastboot, partitions of “unknown” type might not matter. Under u-boot (but not fastboot) it is possible that after mmcblk0p1 all other partitions might not matter. In the case of u-boot, it is looking for zImage in /boot of mmcblk0p1. If something fails there is no reason you couldn’t just flash again…I would not bother to test with fastboot, but with u-boot it is tempting…just expect to re-flash if something goes wrong.