Pivot overlay on NBG6817

I'm working with LEDE 17.01.5. It's not clear to what booting features have made it into this release.

The small root partition is not workable for my needs and I need to utilize the /dev/mmcblk0p10 partition, but no one has reported success with pivot overly or pivot root.

Is this not possible on this router?

Thanks,
-Chip

17.01.x doesn't support the nbg6617 (IPQ4018) at all, to the best of my knowledge it also uses spi-nor flash and not sdhc/ eMMC.

Correction I have the NGB6817. 17.01.5 installs and seems to work properly, I just cannot seem to get a larger root volume so I can install more than a couple packages.

After exhausting everything I know about setting up pivot overlay or pivot root, I gave up an took another approach.

Not too concerned about having a function dual boot, I deleted partitions 5 through 9, recreate partition 5 with all the free space. After reboot I ran resize2fs on the partition and now my root_fs has ~370M.

# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                 3.5M      3.5M         0 100% /rom
tmpfs                   235.2M      2.7M    232.5M   1% /tmp
/dev/loop0              369.9M     53.3M    296.8M  15% /overlay
overlayfs:/overlay      369.9M     53.3M    296.8M  15% /
tmpfs                   512.0K         0    512.0K   0% /dev
/dev/mmcblk0p10           3.2G    300.7M      2.9G   9% /emmc
# gdisk -l /dev/mmcblk0
GPT fdisk (gdisk) version 1.0.1

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/mmcblk0: 7634944 sectors, 3.6 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 98101B32-BBE2-4BF2-A06E-2BB33D000C20
Partition table holds up to 12 entries
First usable sector is 34, last usable sector is 7634910
Partitions will be aligned on 2-sector boundaries
Total free space is 1 sectors (512 bytes)

Number  Start (sector)    End (sector)  Size       Code  Name
   1              34            8225   4.0 MiB     FFFF  rootfs_data
   2            8226           16417   4.0 MiB     FFFF  romd
   3           16418           18465   1024.0 KiB  FFFF  header
   4           18466           26657   4.0 MiB     FFFF  kernel
   5           26658          823329   389.0 MiB   8300  rootfs
  10          823330         7634909   3.2 GiB     FFFF  bu2

Hopefully this information is useful to someone else looking to increase the size of their root_fs.

-Chip

2 Likes

Your custom partitioning changes will blow up badly with the next sysupgrade. The sysupgrade scripts depend on the correct number, order and assignment of partitions (at least for partitions 3-8), their size doesn't matter (as long as they're big enough, so at least 1+4+32 MB (keep in mind, OEM expects to have 64 MB at its disposal for the rootfs, but around 21 MB are already in use today)) - but header/ kernel/ rootfs and header_1/ kernel_1/ rootfs_1 must be present and at the correct location. Sysupgrade (in 18.06 and newer or stock OEM ZyXEL, just as well as OEM u-boot) always alternates between both locations.

Edit: Given how header/ header_1 are accessed (raw), I'd also strongly suggest to keep these partitions exactly at their original size.

Sysupgrade blows up too much for me to trust it anyway. I always reflash and restore.

To make this routers space most usable it really needs a larger rootfs partition.

It's easy enough to de-brick these routers, so the risk is worth it.

No, it's not - sysupgrade and the OEM firmware tools rely on the same markers to determine the install location and will blow up in very similar ways. I'm not saying that you can't resize the partitions, but you must keep 3-8 present and intact, just borrow the space from 10.