Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Ossy <ossy1980@gmx.net>
To: buildroot@busybox.net
Subject: [Buildroot] init: I won't write compressed data to a terminal.
Date: Wed, 07 Jul 2010 22:20:31 +0200	[thread overview]
Message-ID: <4C34E18F.4080109@gmx.net> (raw)
In-Reply-To: <AANLkTimdJ34gAH-YTjfOkW_iEsKZyRvBVnbLIS55oMdd@mail.gmail.com>

Am 07.07.2010 02:35, schrieb Mitch Davis:
> On Wed, Jul 7, 2010 at 8:16 AM, Ossy<ossy1980@gmx.net>  wrote:
>> Hi buildroot mailinglist,
>
> Hey Ossy!
>
>> After successfully compiling a whole rootfs and mounting it via loop on some
>> nfs export I started my arm ebedded device and ran into tho following error
>> after booting the image via tftp.
>>
>> "init: I won't write compressed data to a terminal."
>>
>> The bootargs include a console=ttyS0,115200 and rootfs over nfs options.
>> I guess there is is an issue with the built in zip/bzip compression.
>> But why is the init process not able to output to the terminal?
>
> I would suspect that it's not init as-such, but rather there is a
> startup script that is not working properly.
>
> What happens if you also include "init=/bin/sh" on your kernel boot
> line, then boot?
> What happens if you rename /etc/inittab to have a different name (so
> init won't find /etc/inittab) then boot?

After passing init=/bin/sh to the kernel, I ran into a similar error:
[    4.387550] eth0: link up, 100 Mb/s, full duplex, flow control disabled
[    4.716652] Looking up port of RPC 100003/2 on 192.168.1.106
[    4.727962] Looking up port of RPC 100005/1 on 192.168.1.106
[    4.739261] VFS: Mounted root (nfs filesystem) on device 0:12.
[    4.745153] Freeing init memory: 112K
sh: I won't write compressed data to a terminal.
sh: For help, type: `sh --help'.
[    4.816666] Kernel panic - not syncing: Attempted to kill init!
[    4.822617] Backtrace:
[    4.825103] [<c0028544>] (dump_backtrace+0x0/0x110) from [<c0314e70>] 
(dump_stack+0x18/0x1c)
[    4.833598]  r7:c7820000 r6:c7820000 r5:4005eef0 r4:c03f89dc
[    4.839341] [<c0314e58>] (dump_stack+0x0/0x1c) from [<c0314ec4>] 
(panic+0x50/0x13c)

I think the init process somewhere calls an inline zipping. But I can't 
imagine where and why.

Regards,
Marcus

  reply	other threads:[~2010-07-07 20:20 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-06 22:16 [Buildroot] init: I won't write compressed data to a terminal Ossy
2010-07-07  0:35 ` Mitch Davis
2010-07-07 20:20   ` Ossy [this message]
2010-07-07 20:33     ` Peter Korsgaard
2010-07-07 20:41       ` Ossy
2010-07-07 20:49         ` Peter Korsgaard
2010-07-07 21:39           ` Peter Korsgaard
2010-07-09 19:46             ` Ossy
2010-07-11 18:52               ` Peter Korsgaard
2010-07-07 20:45       ` Peter Korsgaard
2010-07-07  5:52 ` Peter Korsgaard
2010-07-07  6:14   ` Mitch Davis
2010-07-07 18:00   ` Ossy
2010-07-07 18:59     ` Peter Korsgaard
2010-07-07 20:14       ` Ossy

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=4C34E18F.4080109@gmx.net \
    --to=ossy1980@gmx.net \
    --cc=buildroot@busybox.net \
    /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