From: Artem Bityutskiy <dedekind1@gmail.com>
To: Daniel Mack <zonque@gmail.com>
Cc: Sven Neumann <s.neumann@raumfeld.com>,
linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: Regression in handling of unsafe UBI shutdown
Date: Wed, 20 Jul 2011 15:32:16 +0300 [thread overview]
Message-ID: <1311165141.20738.171.camel@sauron> (raw)
In-Reply-To: <CACTFLANrd0FO9GNJpvS+MxnQgLLtXpA-sai30oYN90cjEFOErA@mail.gmail.com>
On Wed, 2011-07-20 at 11:18 +0200, Daniel Mack wrote:
> On Wed, Jul 20, 2011 at 7:21 AM, Artem Bityutskiy <dedekind1@gmail.com> wrote:
> > On Tue, 2011-07-19 at 15:57 +0200, Daniel Mack wrote:
> >> UBIFS: recovery needed
> >> Error reading superblock on volume 'ubi:RootFS'!
> >> UBIFS not mounted, use ubifs mount to mount volume first!
> >> Wrong Image Format for bootm command
> >> ERROR: can't get kernel image!
> >>
> >>
> >> Hence my question is: were there any radical changes in the UBI/UBIFS
> >> code on the kernel side that make older code not like the new content
> >> anymore?
> >
> > Daniel, sorry, I have no time to look at this now, could you please try
> > to bisect the issue?
>
> It's not really easy to bisect as the issue is not always fully
> reproducable, and also because the flash needs to be re-initialized
> after it happened.
>
> Also note that it's not the kernel itself that complains about the
> state of the file system in this case but U-Boot. If we boot a 3.0-rc7
> kernel in such a situation (via USB for example), the kernel will
> recover the FS and continue.
>
> I don't know how many people use the UBI code in U-Boot, and I don't
> know either whether it was a good idea to go this way in the first
> place, but we didn't want to waste much space on the NAND for a
> fixed-size partition just for the kernel, and have a hard limit for it
> in the future. And as I said, this approach has worked just fine in
> the past.
>
> So, let me re-phrase my question: is anyone aware of changes in the
> UBIFS code between 2.6.36 and 3.0 that might cause trouble to U-Boot's
> UBI code from 2009?
I guess that would be an on-flash format change? I am not aware of such
changes, and if there were such - this is a big issue which we wound
need to fix.
--
Best Regards,
Artem Bityutskiy
next prev parent reply other threads:[~2011-07-20 12:31 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-19 13:57 Regression in handling of unsafe UBI shutdown Daniel Mack
2011-07-19 15:02 ` Artem Bityutskiy
2011-07-20 5:21 ` Artem Bityutskiy
2011-07-20 9:18 ` Daniel Mack
2011-07-20 9:31 ` Daniel Mack
2011-07-22 7:58 ` Artem Bityutskiy
2011-07-20 12:32 ` Artem Bityutskiy [this message]
2011-07-20 12:50 ` Daniel Mack
2011-07-20 11:45 ` Mike Hench
2011-07-20 11:50 ` Daniel Mack
2011-07-20 12:06 ` Mike Hench
2011-07-24 14:52 ` Daniel Mack
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=1311165141.20738.171.camel@sauron \
--to=dedekind1@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=s.neumann@raumfeld.com \
--cc=zonque@gmail.com \
/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