List Archive: gentoo-embedded
Note: Due to technical difficulties, the Archives are currently not up to date.
provides an alternative service for most mailing lists.c.f. bug 424647
* Joakim Tjernlund <joakim.tjernlund@...> [120126 05:38]:
> When you update the RO layer you will be back to a single copy, the previous
> release which is only in the overlay is gone, right?
That's up to you. You can manage your updates however you want. For
example, you can have your RO layer loop mounted out of a release image
and have two (or more) different RW areas depending on which image
you're running. That can allow you to fallback from an update fairly
> It also implies 2 different SW update methods, one for updating the overlay
> copy and one for updating the RO layer.
Well, you probably will have an initramfs to set up the aufs. As part
of the initramfs you can do whatever you have to for the update. If you
have things on the RW layer that should be carried over you can leave
them if you mount the same RW filesystem with the new RO layer or you
can copy them to a new RW filesystem if you want them to move forwards
but still want a separate RW filesystem for each image to allow easy
fallback. It's really up to how you want to manage it and how much RW
you need to go forwards with the update (and where it is on the
> AFAIK, only FSes which are designed for flash(JFFS2, UBIFS, YAFFS etc. )
> are safe w.r.t power cuts.
Yes, that's certainly been my experience.
> We are not using NAND flash yet but our next product will. I do have the
> impression that any block emulating device such as SSD are unreliable
> w.r.t power cuts. I would love to be proven wrong though :)
I've used NOR flash with aufs and a RO loop mounted root filesystem from
within a release image and UBIFS RW filesystem.
It worked well.
I've used NOR with JFFS2 before as well and had some issues. Those may
have been bugs in the JFFS2 implementation I used though.