[LEDE-DEV] [RFC] rootfs_data on different MTD outside firmware image

John Crispin john at phrozen.org
Fri Jun 17 23:31:39 PDT 2016



On 18/06/2016 06:21, Adrian Panella wrote:
> Hi, some Linksys devices (i.e WRT1900AC, EA4500, EA8500,...) have two
> different partitions for dual boot, and an additional partition that
> Linksys uses for system config (sysconf).
> Each of these partitions is of a considerable size (23-37 mb, varying
> between devices).
> 
> As far as I could see, the ports already in Owrt/LEDE (Kirkwook & Mvebu)
> use only one partition at a time for the overlayfs, so total 23-37mb
> shared among squashfs rom and ubifs overlay.
> In some cases the third partition (sysconf) is mounted, but in /mmt, not
> taking part in the overlay, and so not directly useful for installing
> additional packages.
> 
> I believe that a way to better profit all this available space would be
> to leave one partition for the rom squashfs alone (23-37mb there) and
> share the 3rd partition between alternative boots as the ubifs overlay
> (another 23-37mb here). In total we double the space up to a full 74mb
> for packages, reducing the need for extroot.
> 
> 
> Have you found any serious disadvantage on this approach, and that's why
> it is not implemented in mvebu/kirkwood? If so, which one?
> 
> If we leave ubifs outside the image, and only squash in one MTD, does it
> add any benefit to have squash image on top of an UBI layer? Erase
> counters would be lost between firmware flashes anyway and no other
> write would occur in between. On the other hand, in the third MTD (i.e.
> sysconf) the erase counters could be preserved between firmware updates,
> as the ubi block doesn't need to be recreated each time, and only a
> ubiformat could be performed on flash.
> 
> I'm planning on switching ipq806x/EA8500 to this scheme, and would
> appreciate opinions first.

sharing a rootfs between 2 different kernels is not good as the kernel
modules wont be in sync with the kernel version magic. inside th eubi
you will have a squash +overlay which is the best approach imho. we
could create a special data area however the kernel should always go
hand in hand with its squashfs and overlay area. if you flash the
kernel+rootfs from within the running installation then the erase
counters will not get lost.



More information about the Lede-dev mailing list