Description of problem: The kernel+initrd+system.map file included in ppc trees fails to properly boot on IBM Power5 systems. Version-Release number of selected component (if applicable): * anaconda-12.32 (rawhide-20091006) How reproducible: * everytime Steps to Reproduce: 1. Configure a IBM Power5 system to boot the ppc64.img over the network from OpenFirmware Actual results: 0 > boot network:,\ppc\F-12-Alpha-ppc64.img BOOTP: chosen-network-type = ethernet,auto,rj45,auto BOOTP: server IP = 0.0.0.0 BOOTP: requested filename = \ppc\F-12-Alpha-ppc64.img BOOTP: client IP = 0.0.0.0 BOOTP: client HW addr = 0 11 25 7e 28 64 BOOTP: gateway IP = 0.0.0.0 BOOTP: device /pci@800000020000002/pci@2/ethernet@1 BOOTP: loc-code U789F.001.AAA0060-P1-T1 BOOTP R = 1 BOOTP R = 2 BOOTP R = 3 BOOTP R = 4 BOOTP R = 5 BOOTP R = 6 BOOTP S = 4 FILE: /ppc/F-12-Alpha-ppc64.img BOOTP: read-first-block fail: 0 FILE: /ppc/F-12-Alpha-ppc64.img FINAL Packet Count = 59157 FINAL File Size = 30288142 bytes. load-base=0x4000 real-base=0x2000000 CLAIM failed Call History ------------ throw - 203903c $call-method - 2046d48 (poplocals) - 203a758 (init-program) - 207e038 boot - 207ec7c evaluate - 204a638 invalid pointer - 2206935 invalid pointer - 7 invalid pointer - 7 quit - 204ad0c quit - 204aae0 My Fix Pt Regs: 00 0000000000000001 0000000000000000 00000000deadbeef 0000000002046d44 04 000000000203fde8 0000000000000007 0000000002011f60 0000000002003010 08 0000000008000000 0000000000000004 000800001c00000f 80000000000da450 0c 0000000000004000 0000000002017100 0000000002018000 000000000009c498 10 000000000223c432 000000000223bb05 0000000002046d40 0000000002046d48 14 fffffffffffffffe 0000000000004000 0000000000000000 0000000000000000 18 0000000002013000 0000000002038000 0000000002014fc0 0000000002016fc0 1c 0000000002020000 000000000203fdf0 0000000002011fa8 0000000002010ff8 Special Regs: %IV: 00000900 %CR: 22808000 %XER: 20000001 %DSISR: 00000000 %SRR0: 0000000002046838 %SRR1: 800000000000b002 %LR: 000000000214ff28 %CTR: 000000000214ff20 %DAR: 0000000000000000 PFW: Unable to send error log! ok 0 > Expected results (F-11-GOLD): 0 > boot network:,\ppc\F-11-GOLD-ppc64.img BOOTP: chosen-network-type = ethernet,auto,rj45,auto BOOTP: server IP = 0.0.0.0 BOOTP: requested filename = \ppc\F-11-GOLD-ppc64.img BOOTP: client IP = 0.0.0.0 BOOTP: client HW addr = 0 11 25 7e 28 64 BOOTP: gateway IP = 0.0.0.0 BOOTP: device /pci@800000020000002/pci@2/ethernet@1 BOOTP: loc-code U789F.001.AAA0060-P1-T1 BOOTP R = 1 BOOTP R = 2 BOOTP S = 2 FILE: /ppc/F-11-GOLD-ppc64.img FINAL Packet Count = 51497 FINAL File Size = 26366022 bytes. load-base=0x4000 real-base=0x2000000 Elapsed time since release of system processors: 1395 mins 48 secs zImage starting: loaded at 0x00400000 (sp: 0x02ddff90) Allocating 0xfa5be4 bytes for kernel ... OF version = 'IBM,SF240_382' Trying to claim from 0x400000 to 0x1d20000 (0x1920000) got ffffffff gunzipping (0x03000000 <- 0x00407000:0x0088bed2)...done 0xe9d000 bytes Attached initrd image at 0x0088c000-0x01d12d48 Allocating 0x1486d48 bytes for initrd ... Relocating initrd 0x3fa6000 <- 0x0088c000 (0x1486d48 bytes) initrd head: 0x1f8b0800 Linux/PowerPC load: Finalizing device tree... using OF tree (promptr=02039a68) OF stdout device is: /vdevice/vty@30000000 Hypertas detected, assuming LPAR ! command line: memory layout at init: alloc_bottom : 000000000542d000 alloc_top : 0000000008000000 alloc_top_hi : 00000000f5000000 rmo_top : 0000000008000000 ram_top : 00000000f5000000 Looking for displays instantiating rtas at 0x00000000076a1000 ... done boot cpu hw idx 0000000000000000 starting cpu hw idx 0000000000000002... done starting cpu hw idx 0000000000000004... done starting cpu hw idx 0000000000000006... done copying OF device tree ... Building dt strings... Building dt structure... Device tree strings 0x000000000542e000 -> 0x000000000542f316 Device tree struct 0x0000000005430000 -> 0x0000000005443000 Calling quiesce ... returning from prom_init Phyp-dump not supported on this hardware Using pSeries machine description Using 1TB segments Found initrd at 0xc000000003fa6000:0xc00000000542cd48 console [udbg0] enabled Partition configured for 8 cpus. CPU maps initialized for 2 threads per core Starting Linux PPC64 #1 SMP Wed May 27 17:18:17 EDT 2009 ----------------------------------------------------- ppc64_pft_size = 0x1a physicalMemorySize = 0xf5000000 htab_hash_mask = 0x7ffff ----------------------------------------------------- Initializing cgroup subsys cpuset Initializing cgroup subsys cpu Linux version 2.6.29.4-167.fc11.ppc64 (mockbuild.phx.redhat.com) (gcc version 4.4.0 20090506 (Red Hat 4.4.0-4) (GCC) ) #1 SMP Wed May 27 17:18:17 EDT 2009 [boot]0012 Setup Arch Additional info:
Isolated the time the ppc64.img no longer worked. FAIL - http://download.fedora.redhat.com/pub/fedora/linux/releases/test/12-Alpha/Fedora/ppc/os/images/netboot/ppc64.img FAIL - http://kojipkgs.fedoraproject.org/mash/rawhide-20090714/development/ppc/os/images/netboot/ppc64.img FAIL - http://kojipkgs.fedoraproject.org/mash/rawhide-20090707/development/ppc/os/images/netboot/ppc64.img FAIL - http://kojipkgs.fedoraproject.org/mash/rawhide-20090705/development/ppc/os/images/netboot/ppc64.img FAIL - http://kojipkgs.fedoraproject.org/mash/rawhide-20090704/development/ppc/os/images/netboot/ppc64.img FAIL - http://kojipkgs.fedoraproject.org/mash/rawhide-20090703/development/ppc/os/images/netboot/ppc64.img <!-- SOMETHING CHANGED --> PASS - http://kojipkgs.fedoraproject.org/mash/rawhide-20090702/development/ppc/os/images/netboot/ppc64.img PASS - http://kojipkgs.fedoraproject.org/mash/rawhide-20090630/development/ppc/os/images/netboot/ppc64.img PASS - http://download.fedora.redhat.com/pub/fedora/linux/releases/11/Fedora/ppc/os/images/netboot/ppc64.img
That's some excellent debugging, but unfortunately the change between those two trees was pretty huge: 20090702 - anaconda-11.5.0.53-1.fc12 20090703 - anaconda-12.0-1.fc12 I'll look into this a little more tomorrow.
I looked at the changes a bit, and there is very little that has to do with ppc, and even less that has to do with netboot image creation. I'm suspecting more something else in the tree changed. It could also be the size of the images, as they increased in size by a number of megs on that day as well. Jlaska was going to get some help from PPC folks on that.
Adding tonyb for additional insight. Tony, do you have any experiences to share that might be contributing the failure?
(In reply to comment #0) > 0 > boot network:,\ppc\F-12-Alpha-ppc64.img <SNIP> > FILE: /ppc/F-12-Alpha-ppc64.img > FINAL Packet Count = 59157 > FINAL File Size = 30288142 bytes. > load-base=0x4000 > real-base=0x2000000 <SNIP> > FILE: /ppc/F-11-GOLD-ppc64.img > FINAL Packet Count = 51497 > FINAL File Size = 26366022 bytes. > load-base=0x4000 > real-base=0x2000000 It looks to me that the image is just too large to load with that real-base. Try the never ending dance of moving real-base around 0x6000000 (96Mb) should be sooo far away from load-base that it should work. But, having looked at the filesizes from: http://kojipkgs.fedoraproject.org/mash/rawhide-20090703/development/ppc/os/images/netboot/ The change was small :(
Thanks Tony, setting real-base to 6000000 did the trick. 0 > printenv real-base -------------- Partition: common -------- Signature: 0x70 --------------- real-base 6000000 6000000 ok 0 > boot network:,\ppc\F-12-Alpha-ppc64.img ... Linux/PowerPC load: Finalizing device tree... using OF tree (promptr=06039a68) OF stdout device is: /vdevice/vty@30000000 Preparing to boot Linux version 2.6.31-0.125.4.2.rc5.git2.fc12.ppc64 (mockbuild.phx.redhat.com) (gcc version 4.4.1 20090807 (Red Hat 4.4.1-5) (GCC) ) #1 SMP Tue Aug 11 21:05:10 EDT 2009 Calling ibm,client-architecture...command line: http://pastie.org/648337 (full log) So what's the outcome here? Should this be documented somewhere?
(In reply to comment #6) > Thanks Tony, setting real-base to 6000000 did the trick. > > 0 > printenv real-base > -------------- Partition: common -------- Signature: 0x70 --------------- > real-base 6000000 6000000 > ok > > 0 > boot network:,\ppc\F-12-Alpha-ppc64.img > ... > Linux/PowerPC load: > Finalizing device tree... using OF tree (promptr=06039a68) > OF stdout device is: /vdevice/vty@30000000 > Preparing to boot Linux version 2.6.31-0.125.4.2.rc5.git2.fc12.ppc64 > (mockbuild.phx.redhat.com) (gcc version 4.4.1 20090807 (Red Hat > 4.4.1-5) (GCC) ) #1 SMP Tue Aug 11 21:05:10 EDT 2009 > Calling ibm,client-architecture...command line: > > http://pastie.org/648337 (full log) > > So what's the outcome here? Should this be documented somewhere? I think documenting it in the release notes for each Redhat/Fedora release would be great. Also if it's not too hard adding a README to the images/netboot would be helpful. Of course netbooting yaboot is the "preferred" install method :)
I see 2 RFE's coming out of this ... (In reply to comment #7) > I think documenting it in the release notes for each Redhat/Fedora release > would be great. Also if it's not too hard adding a README to the > images/netboot would be helpful. #1 - add a README file into the "images/netboot/" directly explaining the ppc[32|64].img. jkeating is cc'd and probably can offer input here. > Of course netbooting yaboot is the "preferred" install method :) #2 - add content to the Fedora 12 install guide outlining what these images are? I've filed bug#528495 (despite ppc becoming a secondary architecture in Fedora 13) to raise this issue with the docs group.
I'm going to close this out as NOTABUG as far as anaconda's concerned, then, since we're not responsible for setting these values up. If I'm misunderstanding something here, please feel free to reopen.
this doesn't seem like a common bugs issue, as it's - well - NOTABUG. seems, as jlaska suggested, more of an install guide thing. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #10) > this doesn't seem like a common bugs issue, as it's - well - NOTABUG. seems, as > jlaska suggested, more of an install guide thing. Are the release notes or install-guide open to modifications for F12?
I don't know, best check with the documentation team. stickster? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers