#12107 HIGH 13.1.0: Unbootable initramfs in secure mode

[Zarro Boogs per Child]

#12107: Unbootable initramfs in secure mode
-------------------------------------------+--------------------------------
           Reporter:  dsd                  |       Owner:  Quozl                   
               Type:  defect               |      Status:  assigned                
           Priority:  high                 |   Milestone:  13.1.0                  
          Component:  ofw - open firmware  |     Version:  Software Build 12.1.0-21
         Resolution:                       |    Keywords:                          
        Next_action:  test in build        |    Verified:  0                       
Deployment_affected:                       |   Blockedby:                          
           Blocking:                       |  
-------------------------------------------+--------------------------------

Comment(by dsd):

 Q4D23 still can't boot the above failing files which did work on Q4D21:

  * http://dev.laptop.org/~dsd/20120916/build2-failing/runos.zip
  * http://dev.laptop.org/~dsd/20120916/build2-failing/runrd.zip

 Now they start booting the kernel at least, messages include:

 {{{
 rootfs image is not initramfs (compression method gzip not configured);
 looks like an initrd
 RAMDISK: gzip image found at block 0
 }}}

 The same thing happens with the nicaragua build of 12.1.0 which uses a
 kernel/initramfs from the vmeta repository.

 This looks like #12181. Whats not clear to me is: why this worked in
 Q4D17, and why our kernel doesn't manage to uncompress the initramfs.
 Since we were also baffled by that in the XO-4 case too, I've
 investigated:

 The root of the problem seems to be the device tree initrd info passed by
 OFW. For this initramfs of 2122879 bytes, ofw passes: linux,initrd-
 start=0xbdf9b80 linux,initrd-end=0xc000000

 That means that the length calculation produces 2122880 bytes
 (phys_initrd_size = end - start) which is one too many.

 So the kernel reaches unpack_to_rootfs() in init/initramfs.c which tasks
 itself with uncompressing 2122880 bytes. It finds the gzipped initramfs at
 the start, and decompresses it, but it realises that it has only
 uncompressed 2122879 bytes. So it goes around the loop again, trying to
 find a decompressor for the final byte, and it fails. Thats when the
 kernel starts producing messages like "gzip compression not supported" -
 its confused.

 So, please check the linux,initrd-end calculation. It looks like it is off
 by one in this case.

-- 
Ticket URL: <http://dev.laptop.org/ticket/12107#comment:8>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system