Re: [Qemu-devel] alpha platform is missing files after initrd load

[Laszlo Ersek]

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 <address@hidden>
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 <address@hidden>

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.