On Fri, Jan 6, 2023 at 12:39 AM Thibaut <[email protected]> wrote: > > Le 6 janv. 2023 à 04:48, Brian Norris <[email protected]> a écrit > > :
> Indeed. Coreutils seems like a better choice here. OK. So I guess I just copy/paste it back into the openwrt tree from the packages feed, and then later clean it out of packages.git? > As an aside (and documentation for similar cases with devices that have > smaller storage), note that if you don’t want to store the extracted firmware > to permanent storage, caldata_sysfsload_from_file() offers an alternative to > this. Thanks. I was trying to grok why there were at least two variants in caldata.sh; I liked (and imitated) the caldata_sysfsload_from_file() approach better. > > [1] Although the default partitioning sets > > CONFIG_TARGET_ROOTFS_PARTSIZE=200, which limits the default build > > unnecessarily to ~128MiB. I still need to figure out the best way to > > fix that: > > You can probably adjust this on your target-specific config, I suppose, although that's still in the same problem space of "how to set a CONFIG_* default from a target" -- that also can't be done in DEVICE_PACKAGES. (And again, I'm a little new at this, so bear with me.) I could also just hardcode something better I guess. I see others do this: https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ipq40xx/image/generic.mk;h=f92e11c797127344c6e14d6292956eeca8f048eb;hb=d3e89e69c52115d1c02f5c16a4aa6b721e003578#l103 (Build/qsdk-ipq-app-gpt) > but the reason for keeping it small is to keep sysupgrade times reasonable, > IIRC. Ah, makes sense. BTW, speaking of sysupgrade (and maybe this deserves a change of Subject if this discussion goes very far): I've found that the emmc.sh upgrade helpers still don't seem very reliable when the rootfs size changes (and so the "f2fs loop-mounted rootfs_data appended to the rootfs" has to move). sysupgrade can be a bit hard to debug, since you lose access to many normal services along the way, so I'm not 100% sure, but it seems like the two filesystems (rootfs and data/overlay) collide, and that a separate rootfs_data partition (such as the one in the glinet_gl-b2200 target above) would work better. Am I missing something here? It seems that sysupgrade is very ad-hoc in openwrt, and that eMMC/block support is still somewhat underdeveloped, so maybe there aren't really any conventions here, and one just does whatever works for them? I'm thinking of just adding the rootfs_data partition to suck up the remaining GBs of disk (and maybe adding to the Google Wifi target too), but I'm still not sure of the Best solution. As a bonus, with a rootfs_data partition, the sysupgrade could potentially be a lot simpler (and does not need to scale with the size of the rootfs_data contents), because the filesystem could mostly just stay in-place. Brian _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
