From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38786) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c3kei-0007Oy-33 for qemu-devel@nongnu.org; Mon, 07 Nov 2016 09:12:16 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c3kec-0005n1-34 for qemu-devel@nongnu.org; Mon, 07 Nov 2016 09:12:11 -0500 Received: from mx1.redhat.com ([209.132.183.28]:41852) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c3keb-0005mK-TJ for qemu-devel@nongnu.org; Mon, 07 Nov 2016 09:12:05 -0500 References: <0f042e9b-f6a3-27c1-4ca0-94e13f8102d8@gmx.net> <20161104110813.GF9817@stefanha-x1.localdomain> <238afa75-0263-9314-caec-05ffeb46fe6e@gmx.net> From: Laszlo Ersek Message-ID: Date: Mon, 7 Nov 2016 15:12:01 +0100 MIME-Version: 1.0 In-Reply-To: <238afa75-0263-9314-caec-05ffeb46fe6e@gmx.net> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] alpha platform is missing files after initrd load List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Dennis Luehring , Richard Henderson , Stefan Hajnoczi Cc: qemu-devel , "Richard W.M. Jones" On 11/07/16 08:37, Dennis Luehring wrote: > Am 04.11.2016 um 22:08 schrieb Richard Henderson: >> No, it was less specific than that. Something like "unpacking failed: >> error". >> >>> >And, apparently, it used to be handled with a panic() call, but then >>> that >>> >was deemed "policy", and downgraded to a KERN_EMERG message: >> Ouch. A silly decision, but definitely an uphill fight to get it >> changed. > > > using a big(~370MB) initrd.cpio with not enough ram (1GB) in qemu i get > this kernel message > > "Initramfs unpacking failed: write error" > > using a small(~14MB) initrd.cpio with just a staticaly linked c based > init for the kernel also with 1GB ram (more then enough) gives me this > kernel message: > > "Initramfs unpacking failed: junk in compressed archive" > > and i currently can't say if only the first is evil or both > > both cpios created with "find . | cpio -H newc -o initrd.cpio" The second error message is incorrect in its own right (it's just another symptom of running out of memory; the compressed archive is valid in fact). But, fixing that would require a more intrusive change I guess, i.e., to distinguish these two kinds of problems properly. Thanks Laszlo