On the R3 the /dev/mmcblk0p66 device is automatically mapped as the remaining space on /dev/mmcblk0p5 after parsing the uImage.FIT for kernel, device tree and read-only squashfs rootfs (squashfs filesystem is mapped as /dev/mmcblk0p65). So those p65 and p66 partitions are not actual GPT partitions but rather p65 is the filesystem sub-image of the uImage.FIT stored in p5 and p66 is the remaining space on p5 after the uImage.FIT.
Hence you only need to edit the size of /dev/mmcblk0p5, then reboot, then use resizefs.f2fs with /dev/mmcblk0p66 which will automatically reflect the changed size of the /dev/mmcblk0p5 partition after reboot.
For extroot to work you need to install block-mount (or better to deal also with removable media: install blockd).
In general I’d still recommend you to install uvol which allows you to manage additional storage volumes more easily. In order to automatically allocate all unused storage on the device used to boot and store the root filesystem you can install the autopart package.
Sidenote: The first part of your post is in French and you should write in English here.
For others :
Boot in recovery or on nand (jumpers in H L H L [NAND] or L H H L [eMMC])
Install “parted” (“opkg install parted”)
Use parted to resize partitions 3 and 4 to the right size (that the sectors follow each other because there are empty spaces between the partitions).
Resize partition 5, the system will indicate that the disk (GPT) does not have its maximum size, “fix” and resize the partition to the maximum of its value (“unit s” [sectors], “print free” [show free space after last partition], “resizepart” then enter partition number [5], ending size [15269854s] in my case).
Then quit and install “autopart” (“opkg install autopart”), I don’t know what is used by autopart at the end, but it takes care of refreshing the partition size which will be at the correct dimension after reboot.
For what you are doing you don’t even need autopart (which would try to use the remaining space you have now already allocated to the production partition).
Yes, in my case it did nothing since there was no more space available at the end of the disk (no error, no message).
Without using autopart, on restart, I did not see the total space but always about 100MB. I think it’s running a command to refresh the partitions or something.
You cannot resize /dev/mmcblk0p66 because that’s not really a partition but rather just the remaining space left after the uImage.FIT on /dev/mmcblk0p5, I have explained this in detail just a few posts above.
So i need to use ‘resize.f2fs’ with the ‘dev/mmcblk0p5’ partition which will automatically reflect the changed size in ‘/dev/mmcblk0p66’ partition after reboot?
Sorry, I may not have been fully awake when replying to your post. The partition table looks good, you have successful edited and expanded mmcblk0p5. To use resize.f2fs you need to boot into the recovery firmware or boot from SPI-NAND, so that the partition will not be in use while you are trying to resize it.
Perhaps this value should be set to something a little more reasonable by default? AT 104MiB that only leaves about 20MiB free for the user. For a device like the R3 (and R64 and R2) which you can expect people will install many packages on, this isn’t enough for even some basic added capabilities.
I realize you are against having it larger than RAM. It should be 256MiB at the very least. The average user should not be expected to have to resize the partition/filesystem, compile their own kernel, or use uvol. This is a barrier to wider adoption.
Mount and unmount it first to replay logs before resizing.
