Problem description: For a long time we have booted ppc64's with the ppc64.img. However, in recent Fedora releases the ppc64.img no longer boots. The boot appears to be normal but fails with: RAMDISK: Compressed image found at block 0 invalid compressed format (err=1) Installation from ppc64.img still works fine for RHEL 5, 5.1, and 5.2. I can boot the machine by scp-ing over the installer kernel and initrd, and creating a stanza in grub.conf to boot with them. That defeats the purpose of the ppc64.img, however. Hardware Environment Machine Type: 9124 HV4 LPAR CPU type: POWER5 Please provide access information for the machine if it is available. Is this reproducible? Yes. If so, how long does it (did it) take to reproduce it? Fails withing a second or so of boot. Describe the steps: 1. Setup dhcp/tftp server to serve ppc64.img to machine's MAC address 2. Setup the LPAR firmware to boot off the dhcp/tftp server 3. Boot off the network 4. Failure occurs during installer kernel boot ======================================================================================================== This bug apparently differs from bug Red Hat Bugxilla #239658, in its failure mode: "invalid compressed format (err=1)" vs "CLAIM failed", respectively. However, they are similar enough that the may either be related or different manifestations of the same failure. The boot from ppc64.img also fails on a JS21. It does have a different error message: FILE: /f9-ppc64.img FINAL File Size = 12566528 load-base=0x4000 real-base=0xc00000 .---------------------------------. | No Operating Systems Installed | `---------------------------------'
Created attachment 316324 [details] Console log of Fedora 9 installer kernel boot
This issue appears not just to be limited to ppc64.img. I can't get Fedora 9 to install on either the HV4 or the JS21 with the separate installer kernel and initrd. This has worked fine in the past, and in fact works with RHEL 5.2. Booting from the Fedora 9 installer vmlinuz and ramdisk.image.gz on the HV4, anaconda prompts me for language and networking setup as usual. After I enter the HTTP setup information, I get "Retrieving images/minstg2.img", then and Error dialog box, "Unable to retrieve the install image." When I try the same thing on the JS21, the kernel appears to hang during boot - it's difficult to tell because the SOL console gets dropped. The last line is "SLUB :Gnslabs=13, HWalign=128, Order=0-1, MinObjects=4, CPUs=4, Nodes=1". Then no more console.
Raising to P1 - I can' get Fedora 9 installed on my ppc64 machines. Please inform me if I'm doing something wrong that causes this failure or if something has changed in the install procedure.
This bug was incorrectly associated with component "imageinfo". I have modified this to "kernel", which is presumably the correct component, but the original bug reporter should confirm this.
I was able to work around this issue by setting the real-base OF variable to 1000000 0 > printenv real-base -------------- Partition: common -------- Signature: 0x70 --------------- real-base c00000 c00000 ok 0 > setenv real-base 1000000 ok 0 > This be set automatically or at least documented.
------- Comment From gcwilson.com 2009-04-15 16:24 EDT------- I've generally been able to boot Fedora 10 on ppc64. So it appears to be fixed. Closing this bug on our side. ------- Comment From gcwilson.com 2009-04-15 16:30 EDT------- Wait, maybe I'm being too hasty. Comment #21 mentions needing to get this into RHEL 6. Red Hat, do you require this bug to track ppc64 boot issues int oRHEL 6?
------- Comment From gcwilson.com 2009-04-15 16:30 EDT------- NOT closing on our side until I hear whether or not this bug is required for RHEL 6.
------- Comment From tonyb.com 2009-04-16 16:36 EDT------- (In reply to comment #25) > NOT closing on our side until I hear whether or not this bug is required for > RHEL 6. > A variety of changes have gone into the kernel and yaboot to get FC11 (RHEL6) booting. The rawhide yaboot and kernel boot, but the installer fails for other reasons. I think we're okay to close this bug.
------- Comment From gcwilson.com 2009-04-16 17:28 EDT------- Thank you, Tony. Closing based on the last comment.
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.