Re: [yocto] lost busybox mysteriously

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Gabriele,

On 1/28/20, Gabriele Zampieri <gabbla.malist@xxxxxxxxx> 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@xxxxxxxxx> wrote:
>
>> On 1/27/20, Quentin Schulz <quentin.schulz@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxx
>> Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  [
>> gabbla.malist@xxxxxxxxx]
>> -=-=-=-=-=-=-=-=-=-=-=-
>>
>

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




[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux