On Thu, 25 Aug 2016 13:07:43 +0200 Daniel Golle <dan...@makrotopia.org> wrote:
> On Thu, Aug 25, 2016 at 12:50:59PM +0200, Ralph Sennhauser wrote: > > Hi Daniel, > > > > On Thu, 25 Aug 2016 10:53:34 +0200 > > Daniel Golle <dan...@makrotopia.org> wrote: > > > > [snip] > > > > > Are you planning to switch to initramfs and then load the ubi and > > > ubifs modules in order to get a persistent rootfs?! > > > Remember that otherwise, these modules are needed to be built-in > > > to the kernel in order to mount the rootfs during boot. > > > > I use an initramfs to mount root indeed. This is just an > > alternative to 7 patches in generic and mvebu to do the same. > > > > The kernel partition is 6MB, so there is plenty space and using > > busybox works fine except there is no ubiblock applet. To work > > around this I build ubi as a module instead of built-in and use > > module parameter to create a blockdevice from the squashfs volume > > for use by the overlayfs. > > Does the memory used for the initramfs get freed once you switched to > the 'real' rootfs? If so, this would indeed be a quite good > alternative to the current way and also provide other pre-init > features such as failsafe-mode. > > I'll also be working on improving the patch-situation, afaik it's > currently 3 patches which are not yet upstream to handle mounting In case of mvebu at least generic/995-mangle_bootargs.patch and mvebu/100-find_active_root.patch are required as well. Unless of course you use an initramfs. Cheers Ralph > ubifs as well as creating ubiblock and selecting it as root_dev for > squashfs. I'm planning to implement parsing the root= cmdline > parameter in the same way UBIFS does, so in case of non-ubifs rootfs, > a ubiblock can be auto-created based on the volume specified in the > cmdline. This will improve the situation eg. for dual-boot, as the > volume name to-be-mounted will no longer need to be hard-coded into > the kernel. Once this is done, the remaining patches can be replaced > with those fit-for-upstream versions. > > > Cheers > > > Daniel > > > > > > > Cheers > > Ralph _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
