Linux-mtd Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Dahl <ada@thorsis.com>
To: linux-mtd@lists.infradead.org
Cc: Yocto discussion list <yocto@yoctoproject.org>,
	Jupiter <jupiter.hce@gmail.com>
Subject: Re: Install Yocto image and backup
Date: Tue, 03 Nov 2020 09:16:07 +0100	[thread overview]
Message-ID: <3029789.gPz3SqCoUO@ada> (raw)
In-Reply-To: <CAA=hcWSAsKEcFaR1dCpCey_m2Z2zOxYT1N8NNjL6bNQxSrHj1A@mail.gmail.com>

Hei hei,

Am Montag, 2. November 2020, 10:16:58 CET schrieb Jupiter:
> Hi Alexander,
> 
> Thanks for your advice.
> 
> > In my opinion two things are common practice:
> > 
> > 1) Using a layer on top of raw NAND, like UBI/UBIFS nowadays, so bad
> > blocks
> > can be handled properly in a layer below your rootfs.
> 
> Yes, the UBI/UBIFS is used in NAND partitions, I guess you alluded
> there is no need use the backup, right?

If your kernel and rootfs partition is just one UBIFS in a bigger UBI volume, 
then no. Single bad blocks affecting the UBIFS partitions would be handled by 
the underlying UBI. You should however consider using ubihealthd or something 
similar to become aware of badblocks over time and handle them before it's too 
late and you can not boot from the rootfs anymore, especially if it is read 
only and not touched for writing in normal operation.

> > 2) Using an A/B scheme for updating and using a well tested framework for
> > that  (instead of self written shell scripts).  You don't need another
> > NAND chip for that, just multiple partitions.  You can still have your
> > kernel/rootfs read-only at runtime.
> If I do need to use a backup, it won't need another NAND chip, it will
> be another UBI/UBIFS partition. But I would like as simple as possible
> if no backup is a common practice.

I don't think backup is the right term here. Backup would be something you 
make based on a running system.

I just looked briefly over the documentation of RAUC [1]. This is no explicit 
recommendation, there are other update frameworks, but you can find a lot of 
ideas and concepts in there frequently used in the embedded world for updates.

Your original question implied you want some kind of redundancy, but never 
update kernel and root filesystem, right? That's rather unusual at least if 
your device is somehow connected to a network. So what I suggested was having 
two rootfs partitions. One is active and the device boots from it (A), and the 
other one acts as inactive (B). When you update, write the new rootfs to the 
inactive partition and then just switch over and boot B instead. You might add 
a third partition for recovery or factory reset. Only the active partition 
would be used in the running system and can still be readonly there.

Alex

[1] https://rauc.readthedocs.io/



______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  reply	other threads:[~2020-11-03  8:18 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-02  1:02 Install Yocto image and backup Jupiter
2020-11-02  8:40 ` Alexander Dahl
2020-11-02  9:16   ` Jupiter
2020-11-03  8:16     ` Alexander Dahl [this message]
2020-11-03  9:17       ` Jupiter
2020-11-03  9:48         ` [yocto] " Richard Weinberger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3029789.gPz3SqCoUO@ada \
    --to=ada@thorsis.com \
    --cc=jupiter.hce@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=yocto@yoctoproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox