[OpenWrt-Devel] [PATCH v2 0/2] kernel: add kmod-ubi and kmod-fs-ubifs
Ralph Sennhauser
ralph.sennhauser at gmail.com
Fri Sep 16 05:51:17 EDT 2016
On Thu, 25 Aug 2016 13:07:43 +0200
Daniel Golle <daniel at 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 <daniel at 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 at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
More information about the openwrt-devel
mailing list