linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: JH <jupiter.hce@gmail.com>
To: Gabriele Zampieri <gabbla.malist@gmail.com>
Cc: connman <connman@lists.01.org>,
	Quentin Schulz <quentin.schulz@streamunlimited.com>,
	linux-mtd <linux-mtd@lists.infradead.org>,
	Andy Pont <andy.pont@sdcsystems.com>,
	Yocto discussion list <yocto@yoctoproject.org>
Subject: Re: [yocto] lost busybox mysteriously
Date: Tue, 28 Jan 2020 21:40:19 +1100	[thread overview]
Message-ID: <CAA=hcWTxX5GrnEJzKCJFhbe9mFvy8A7hG+EXbmczZSafyspfpw@mail.gmail.com> (raw)
In-Reply-To: <CAAx3WaA2uoCki+1AV9QFZybbszfS5wecWKf1PfDvgV5u9EVL=g@mail.gmail.com>

Hi Gabriele,

On 1/28/20, Gabriele Zampieri <gabbla.malist@gmail.com> wrote:
> HI JH,
>
> - Can you stop on uboot and try "nand bad"? This will list the bad blocks
> on your device.
=> nand bad

Device 0 bad blocks:


> - How do you flash your ubi partition(s)?

I boot zImage-initramfs kernel to Linux user space, then run:
ubidetach -p /dev/mtd5
ubiformat /dev/mtd5 -y
ubiattach -m 5
ubimkvol /dev/ubi0 -s 160MiB -N rootfs_data
mount -t ubifs ubi0:rootfs_data /mnt
cp -adr /yocto_rootfs/* /mnt

> - During boot, does ubifs layer complain about the partition is it trying
> to mount? It will in case of corrupted metadata and may result in a read
> only mount.

There is no partition involved during the boot, all partitions start
in user space after booting.

> - It's pretty weird that busybox has gone and the partition is intact.
> Didn't you messed with any script? Can you replicate on another board?

I don't think it was bad block problem, because it is a new version
hardware, which has some problem in power supply, could unstable or
insufficient power supply cause MTD / NAND crash?

Thank you Gabriele,

Kind regards,

- jh

>
> On Tue, Jan 28, 2020 at 7:25 AM JH <jupiter.hce@gmail.com> wrote:
>
>> On 1/27/20, Quentin Schulz <quentin.schulz@streamunlimited.com> wrote:
>> > Hi JH,
>> >
>> > On Mon, Jan 27, 2020 at 10:13:37PM +1100, JH wrote:
>> >> Hi Andy,
>> >>
>> >> Thanks for the response.
>> >>
>> >> On 1/27/20, Andy Pont <andy.pont@sdcsystems.com> wrote:
>> >> > JH wrote...
>> >> >
>> >> >>That the same problem of missing busybox was not just occurred
>> >> >> during
>> >> >>the device running in the middle of operation, it was also occurred
>> >> >>during booting image from NAND, I saw several times that the first
>> >> >> and
>> >> >>second cycles of booting image from NAND were working well, then
>> >> >> some
>> >> >>following booting process would be crashed by missing busybox, then
>> >> >>could not run whole shell commands. I have been pondering if it
>> >> >> could
>> >> >>be caused by NAND issue or network virus / fishy? Appreciate any
>> >> >>clues.
>> >> > The first step is for us to understand what “missing” means?  Have
>> >> > you
>> >> > got any mechanism (U-Boot, SD card boot, etc.) that will allow you
>> >> > to
>> >> > mount and look at the contents of the NAND file system?
>> >>
>> >> Means that busybox was not there anymore, it mysteriously lost, all
>> >> shell commands would no longer available. It cannot to run mount or
>> >> any shell commands. There was two scenarios when that happened:
>> >>
>> >> - In the middle of running, the device all of certain could not run
>> >> shell commands and failed mysteriously
>> >>
>> >> - During the u-boot booting kernel process, there were full errors of
>> >> failing shell commands. Let me make it clear,  that booting error did
>> >> not occur in the first or second kernel booting after the new image
>> >> installation, it happened in the following kernel booting, but there
>> >> was nothing to delete busybox accidentally, busybox was just
>> >> mysteriously disappeared. Because I could not run ls, I did not know
>> >> if there are other things missing. If you ask how I could know the
>> >> busybox was missing, I ran the zImage-initramfs to boot the linux in
>> >> RAM, then mount the ubi0 to find  out busybox was gone.
>> >>
>> >>
>> >> > If you look at the /bin directory (ls -la /bin/busy*) what do you
>> >> > see?
>> >> > Have the files been deleted? Truncated? Zero length?
>> >>
>> >> Could not run ls or any shell commands when the busybox was missing.
>> >>
>> >
>> > /bin/ls -la /bin/busy* ?
>> >
>> > Maybe something is messing with the PATH environment variable. Or
>> > something is removing the symlinks from some binaries to busybox.
>>
>> No, could not run /bin/ls as it was  linked to  /bin/busybox.nosuid,
>> the /bin/busybox.nosuid was damaged for some reason.
>>
>> >> > What file system are you using on the NAND flash?  How are the
>> >> > devices
>> >> > being reset during the various boot cycles?  If it is a hardware
>> >> > reset
>> >> > then some file systems are less resilient to it than others but I
>> would
>> >> > expect in that case more fundamental boot issues.
>> >>
>> >> UBIFS, most device reset or boot cycles were calling halt or reboot,
>> >> but it sometime it could just use power cycle.
>> >>
>> >
>> > IIRC, UBIFS is safe from power cycles.
>>
>> Good to know. Thank you.
>>
>> > Quentin
>> >
>> -=-=-=-=-=-=-=-=-=-=-=-
>> Links: You receive all messages sent to this group.
>>
>> View/Reply Online (#48171):
>> https://lists.yoctoproject.org/g/yocto/message/48171
>> Mute This Topic: https://lists.yoctoproject.org/mt/70128245/3618237
>> Group Owner: yocto+owner@lists.yoctoproject.org
>> Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  [
>> gabbla.malist@gmail.com]
>> -=-=-=-=-=-=-=-=-=-=-=-
>>
>

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

      parent reply	other threads:[~2020-01-28 10:40 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAA=hcWRQmXa4_hh3KzKmqeaEkGsbdTEimsPjh=tZWribMkM0dA@mail.gmail.com>
2020-01-26 23:35 ` lost busybox mysteriously JH
     [not found]   ` <emb3e01e23-7511-48c8-9229-85a767ab359c@andys-imac.leeshillfarm.local>
2020-01-27 11:13     ` [yocto] " JH
2020-01-27 11:31       ` Jonatan Palsson
2020-01-28  5:58         ` JH
2020-01-27 12:06       ` Quentin Schulz
2020-01-27 15:04         ` Laurent Gauthier
2020-01-28  5:55           ` JH
2020-01-28  6:25         ` JH
     [not found]           ` <CAAx3WaA2uoCki+1AV9QFZybbszfS5wecWKf1PfDvgV5u9EVL=g@mail.gmail.com>
2020-01-28 10:40             ` JH [this message]

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='CAA=hcWTxX5GrnEJzKCJFhbe9mFvy8A7hG+EXbmczZSafyspfpw@mail.gmail.com' \
    --to=jupiter.hce@gmail.com \
    --cc=andy.pont@sdcsystems.com \
    --cc=connman@lists.01.org \
    --cc=gabbla.malist@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=quentin.schulz@streamunlimited.com \
    --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;
as well as URLs for NNTP newsgroup(s).