Re: [yocto-patches] [meta-rockchip][PATCH] provide a filesystem overlay example

[Trevor Woerner <twoerner@gmail.com>]

On Fri 2025-12-12 @ 03:05:10 PM, Quentin Schulz via lists.yoctoproject.org wrote:
> Hi Trevor,
> 
> On 12/12/25 2:49 PM, Trevor Woerner via lists.yoctoproject.org wrote:
> > On Fri 2025-12-12 @ 11:47:55 AM, Quentin Schulz via lists.yoctoproject.org wrote:
> > > Hi Trevor,
> > > 
> > > On 12/11/25 10:03 PM, Trevor Woerner via lists.yoctoproject.org wrote:
> [...]
> > > Additionally, CONFIG_OVERLAY_FS support likely needs to be enabled in the
> > > kernel for this to work, so mentioning this would be nice? (though we also
> > > didn't mention this for the VPU, so... :) ).
> > 
> > It's funny I didn't mention this, considering the other email thread in
> > progress ;-) The aarch64 defconfig includes:
> > 
> > 	CONFIG_OVERLAY_FS=m
> > 
> > which is good enough to make this work. It also includes
> 
> If one includes kernel-modules in the image ;)
> 
> [...]
> 
> > > > diff --git a/dynamic-layers/rk-rauc-demo/recipes-core/systemd/files/home.mount b/dynamic-layers/rk-rauc-demo/recipes-core/systemd/files/home.mount
> > > > new file mode 100644
> > > > index 000000000000..d6a384fa9c75
> > > > --- /dev/null
> > > > +++ b/dynamic-layers/rk-rauc-demo/recipes-core/systemd/files/home.mount
> > > > @@ -0,0 +1,13 @@
> > > > +[Unit]
> > > > +Description=OverlayFS mount for /home to /data/overlay/home
> > > > +Requires=etc.mount
> > > > +After=etc.mount
> > > > +
> > > 
> > > Why is this not data.mount too?
> > 
> > I did this patch one piece at a time. It took me less than an hour from
> > start of reading to getting /etc working. It then took me the rest of
> > the day to get /home added as well. The problem was with
> > ordering/dependencies.
> > 
> > If I ordered both /home and /etc overlays after data.mount it would
> > always fail; either one or both of the mounts would not appear in the
> > `mount` output or (worse) the overlays would appear to be mounted (they
> > would show up in the `mount` output) but one or both of the mounts would
> > not work.
> > 
> 
> That's really odd. Half wondering if this shouldn't be brought up to the
> systemd community? Not sure exactly what could be going wrong..
> 
> > The solution I found was to explicitly order them: data → etc → home. In
> > practice it didn't matter whether home or etc came first, they just
> > needed to be strongly ordered.
> > 
> > While trying to get this right, sometimes systemd itself would throw a:
> > 
> > 	[ SKIP ] Ordering cycle found, skipping Ove…mount for /etc to /data/overlay/etc
> 
> But there's no circular dependency... That's weird.
> 
> > 
> > on boot (sometimes for etc, sometime for home) which at least warned me
> > that something went wrong. Other times it didn't give the error, but
> > failed anyway.
> > 
> > tl;dr: it's a bit finicky ;-)
> > 
> 
> This is the kind of information one would want to have in a comment or in
> the git commit log so that we know *why* something seemingly odd was done.
> It wasn't a mistake or an oversight, but a work-around for a specific issue.

WOW! Your suggestion to use RequiresMountsFor did the trick! It
literally solved all the problems I was seeing. Take a look at the v2 i
just posted.

Thanks!