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
next prev parent 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