On 11/04/16 17:37, Richard Henderson wrote: > On 11/04/2016 05:08 AM, Stefan Hajnoczi wrote: >> On Thu, Oct 20, 2016 at 12:45:37PM +0200, Dennis Luehring wrote: >>> qemu: 2.7.x (git head) >>> platform: Alpha (Clipper) >> >> Two options: >> >> 1. Not many people use Alpha. You may need to debug this yourself by >> learning about the Linux alpha boot protocol (where the initramfs is >> loaded and how big that region of memory may be). Then you can >> verify the memory contents after QEMU has loaded the >> kernel/initramfs using monitor commands to read memory. You may need >> to look at QEMU's kernel/initramfs loading code to see what it's >> doing. >> >> 2. If it worked in a previous QEMU version, please use git-bisect(1) to >> find out which commit broke it. >> >> Good luck! > > We debugged this via private mail. > > For the 4.7 kernel, we had enough ram to unpack the (large) initrd; with > the 4.8 kernel, we ran out. The 4.8 kernel did in fact print an > (obscure) error message to that effect, which had not been noticed.
Was it Unpacking initramfs... Initramfs unpacking failed: junk in compressed archive ? If so, then the same has been encountered with the aarch64 target: https://github.com/libguestfs/libguestfs/commit/c24f242521e8 > I > consider it a bug that the kernel does not treat this like any other > failure to mount /root, via panic. I agree. And, apparently, it used to be handled with a panic() call, but then that was deemed "policy", and downgraded to a KERN_EMERG message: commit 73310a169aebe257efdd35a763cce1c7658f40c9 Author: H. Peter Anvin <h...@linux.intel.com> Date: Wed Jan 14 11:28:35 2009 -0800 init: make initrd/initramfs decompression failure a KERN_EMERG event Impact: More consistent behaviour, avoid policy in the kernel Upgrade/downgrade initrd/initramfs decompression failure from inconsistently a panic or a KERN_ALERT message to a KERN_EMERG event. It is, however, possible do design a system which can recover from this (using the kernel builtin code and/or the internal initramfs), which means this is policy, not a technical necessity. A good way to handle this would be to have a panic-level=X option, to force a panic on a printk above a certain level. That is a separate patch, however. Signed-off-by: H. Peter Anvin <h...@linux.intel.com> I guess it is "possible to design a system which can recover from this", except noone seems to have bothered, since 2009. (Ditto for the proposed "panic-level=X" alternative.) I've now briefly considered posting a trivial kernel patch for this, but having learned about the above commit, I don't think so... Thanks Laszlo > Increasing ram from 1GB to 2GB allowed the 4.8 kernel to succeed in > unpacking and booting off of the initrd.
