BananaPi R3 eMMC overlay resizing

[yurtesen]

I was curios about the command in the wiki

Sinovoip BananaPi BPi R3 V1.0, V1.1

It suggests:

parted /dev/mmcblk0 -- mkpart f2fs 768MiB -34s resizepart 5 768MiB resizepart 4 67.1M resizepart 3 12.6M 
  # say F to fix gpt global size
reboot

mount /dev/mmcblk0p66 /mnt && umount /dev/mmcblk0p66 && resize.f2fs /dev/mmcblk0p66
  # if resize.f2fs fails, a sysupgrade may fix

Can somebody explain the parted command?
First it makes a new partition of 768MiB? why?
What is -34s?
Why does it resize part 4 and part 3? Because overlay is on part 5 ?

I guess partly my question is why not resize part 5 only, then run the resize.f2fs on overlay to enlarge it?

Thanks,

[panachoi]

Okay: I've managed to to this.
Outline:

Installed 23.05-rc3 from sdcard to NOR/NAND and EMMC
Boot production NAND partition, install parted and f2fs-tools

resize /dev/mmcblk0p5 with parted to the size you like
reboot production NAND system, mount and unmount
/dev/mmcblk0p66 as outlined above, then resize.f2fs /dev/mmcblk0p66

I didn't bother with eliminating the free spaces (sectors) between some partitions, as they are minimal.

[yurtesen]

@panachoi that is exactly what I did myself. Except I built myself an image with the needed tools. I do not like to bother with installing stuff later

But the wiki has so much more cumbersome process. I am not sure why they have that. I was wondering if anybody knows if there is a practical reason. I was just curious.

[ahuman]

I also came to this thread hoping for a proper answer to @yurtesen's question, but I guess whoever wrote that wiki section doesn't pay much attention to the forums.

In searching for more answers, I also ended up at this comment over at the BananaPi forums:

https://forum.banana-pi.org/t/bpi-r3-change-or-add-partion-to-overlay/14240/12

Which is a completely different take on the whole subject as recommended by @daniel.

[buggz]

There are too many threads on the same matter, not just on this subject, but all subjects.
Making it is VERY difficult to find answers.
I have successfully performed this, but not from the instructions in this thread.
I will have to find my post, as I replied, that the procedure I followed worked.

[buggz]

I resized my BPI-R3 eMMC via the following method:

@Sailor

It‘s been a while, since I setup my bpi r3. But first of all, we need to solve your space problem.
I think the easiest way, would be the get the sqashfs factory image from openwrt.org.
Then head to: system/ firmware upgrade in luci and install the image. If I remember right, luci puts the image in /tmp, which is a ram disc.
After the reboot everything should be fine again. On the fresh install, install cfdisk. With it just resize /dev/mmcblk0p5 to occupy the remaining free space and reboot afterwards.
After the reboot you should have 8GB space available.

Edit: the post was saying: resize /dev/mmcblk0p66 before, which is wrong. I posted the correct procedure below.

My mistake. Try like this:

cfdisk /dev/mmcblk0

it look something like:

Navigate to /dev/mmcblk0p5 and resize this partition. It should work without a warning. Afterwards reboot.

[ahuman]

I went ahead and pieced together the exact meaning of the parted command from the wiki article, for any other novices like me who are baffled.

https://www.gnu.org/software/parted/manual/parted.html

"--" signifies the end of command options. Prevents the "-34s" from being interpreted as an option (that doesn't exist).

"mkpart f2fs 768 MiB -34s" is all one command, making a new partition beginning 768 MiB from the start of the disk and stopping 34 sectors from the end of the disk. So this fills the entire eMMC capacity, less 768 MiB (approx. 6.57 GiB). Does not actually create the filesystem, only specifies its expected type (f2fs) for the partition table.

"resizepart 5 768MiB" moves the end of partition 5 to 768 MiB (i.e. where the previously created partition starts). This is the "production" partition (i.e. where your stuff goes). The actual size will be 704 MiB because the partition starts at 64 MiB (67.1MB).

"resizepart 4 67.1M" moves the end of partition 4 to 67.1 MB (i.e. 64 MiB, where partition 5 starts). This is the "recovery" partition, and this resize pads it out to fill the ~20 MiB of empty space left between partitions 4 & 5 in the default flash layout. I don't really see any reason to bother with this.

"resizepart 3 12.6M" moves the end of partition 3 to 12.6MB (i.e. where partition 4 starts). This is the "fips" partition, and this resize pads it out to fill the ~1.5 MiB of free space left between partitions 3 & 4 in the default flash layout. Again, I don't see any reason to bother with this.

My understanding is that the new 7 GiB partition becomes the overlay (mmcblk0p66) after the resize.f2fs operation.

But to repeat, a primary developer strongly discourages that approach:

https://forum.banana-pi.org/t/bpi-r3-change-or-add-partion-to-overlay/14240/12

And messing around with partitions 3 & 4 just feels like chasing OCD to me ("Nooo! I can't have any free space!"). What's the benefit?

I'm going to stick with increasing partition 5 (production) a sensible amount, and then use the uvol/autopart solution to get additional space that can be used for anything.

[Videopac]

Thanks for your help.
However: I don't have cfdisk and can't seem to install it:
opkg install cfdisk
gives an error:
Failed to download the package list from https://downloads.openwrt.org/releases/23.05.3/targets/mediatek/filogic/packages/Packages.gz

And I can't update my packages, maybe due to too less free space (approx 25MB).
Do I really have to de-install AdGuardHome first in order to extend my eMMC partition?
(and why is the full eMMC capacity not being used in the first place?)

[buggz]

Sorry, I have no idea, I am just a simple user here.

I do notice that on my GL.iNet GL-MT6000, the FULL space IS available, and is utilized.
So, I think this is a bad configuration desicion issue that can possibly be changed from the start?
I don't know, nor understand either...

@Videopac

(and why is the full eMMC capacity not being used in the first place?)

[roelofz]

Hi,

After endless searching, reading, and trying, there must be a difference in what is all suggested and what I have in my config.

This is the parted layout:

(parted) print                                                            
Model: MMC 008GB0 (sd/mmc)
Disk /dev/mmcblk0: 7818MB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system  Name        Flags
128     17.4kB  4194kB  4177kB                           bios_grub
 1      4194kB  4719kB  524kB                ubootenv    hidden, legacy_boot
 2      4719kB  6816kB  2097kB               factory     hidden
 3      6816kB  12.6MB  5767kB               fip         boot, hidden, esp
 4      12.6MB  67.1MB  54.5MB               recovery    boot, hidden, esp
 5      67.1MB  805MB   738MB                production

As you can see, enough room for partition 5 what seems to be addressed (I never could found out why) as mmcblk0p66 in resize.f2fs.

resize.f2fs gives the following ouput:

root@router:/# resize.f2fs /dev/mmcblk0p66
Info: MKFS version
  "Linux version 5.15.150 (builder@buildhost) (aarch64-openwrt-linux-musl-gcc (OpenWrt GCC 12.3.0 r23809-234f1a2efa) 12.3.0, GNU ld (GNU Binutils) 2.40.0) #0 SMP Fri Mar 22 22:09:42 2024"
Info: FSCK version
  from "Linux version 5.15.150 (builder@buildhost) (aarch64-openwrt-linux-musl-gcc (OpenWrt GCC 12.3.0 r23809-234f1a2efa) 12.3.0, GNU ld (GNU Binutils) 2.40.0) #0 SMP Fri Mar 22 22:09:42 2024"
    to "Linux version 5.15.167 (builder@buildhost) (aarch64-openwrt-linux-musl-gcc (OpenWrt GCC 12.3.0 r24106-10cc5fcd00) 12.3.0, GNU ld (GNU Binutils) 2.40.0) #0 SMP Mon Sep 23 12:34:46 2024"
Info: superblock features = 0 : 
Info: superblock encrypt level = 0, salt = 00000000000000000000000000000000
Info: Segments per section = 1
Info: Sections per zone = 1
Info: total FS sectors = 191848 (93 MB)
Info: CKPT version = 5ccce354
[FIX] (move_one_curseg_info:2921)  --> Move curseg[0] 3 -> 17 after 1000

[FIX] (move_one_curseg_info:2921)  --> Move curseg[1] 1a -> 1b after 1000

[ASSERT] (move_one_curseg_info:2904) ret == 0

And the it stops, no mather how often I reboot, cry, start being angry, I just don´t get it.
In all examples I have seen, this should be the trick, but this just doesn't work. I did mount en umount, tried a upgrade as suggested in one of the topics, but still.

Strange observation: autopart installs but with uci errors (maybe related).
I am now in the nand image on 23.05.5, tried it also on 23.05.3.

Please, who can understand what is going wrong here.

Thanks for all your thoughts!

[roelofz]

Don´t ask how, but it did work now. I think it was by removing the last partition and rerunning cfdisk, but can´t understand it completely.
Sometimes it helps to let it go for a while (old IT wisdom )

Anyway, the partition is resized....