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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.