LTC Owner is: amitarora.com LTC Originator is: joseferr.com Problem description: When trying to install F7-test4 using a netboot image at Power5 and Power5+ machines, the kernel doesn't boot. This is reproducible, and the steps to reproduce are: 1) Enter the HMC for the machine which will be installed 2) Reboot the desired machine using chsysstate. 3) Enter the desired machine using vtmenu. 4) Configure the netboot options using SMS menu. 5) Boot from the image server. At this point, the machine will request the image using tftp, and by time it tries to boot, it fails. This is the output: BOOTP: chosen-network-type = ethernet,auto,rj45,auto BOOTP: server IP = x.x.xxx.xx BOOTP: requested filename = BOOTP: client IP = x.x.xxx.xxx BOOTP: client HW addr = 0 d 60 f4 1f d2 BOOTP: gateway IP = x.x.xxx.x BOOTP: device /pci@800000020000001/pci@2,2/ethernet@1 BOOTP: loc-code U787D.001.1234567-P1-T1 icmp 5 : redirect BOOTP R = 1 BOOTP S = 2 FILE: ppc64.img FINAL Packet Count = 18562 FINAL File Size = 9503484 bytes. load-base=0x4000 real-base=0xc00000 CLAIM failed Call History ------------ throw - c3903c $call-method - c46cc8 (poplocals) - c3a710 (init-program) - c7da28 boot - c7e66c evaluate - c4a5b8 create-single-mem-node - da4140 invalid pointer - 4 invalid pointer - 4 quit - c4ac78 quit - c4aa60 My Fix Pt Regs: 00 0000000000000000 0000000000000000 00000000deadbeef 0000000000c46cc4 04 0000000000c3fda0 0000000000000004 0000000000c11f60 0000000000c03010 08 0000000010000000 0000000000000004 000000001000000f 80000000001c3b80 0c 0000000000004000 0000000000c17100 0000000000c18000 00000000000e85e0 10 0000000000f48393 0000000000f4812b 0000000000c46cc0 0000000000c46cc8 14 fffffffffffffffe 0000000000004000 0000000000000000 0000000000000000 18 0000000000c13000 0000000000c38000 0000000000c14fc0 0000000000c16fc0 1c 0000000000c20000 0000000000c3fda8 0000000000c11fa8 0000000000c10ff8 Special Regs: %IV: 00000900 %CR: 22808000 %XER: 20000001 %DSISR: 00000000 %SRR0: 0000000000c3eaa8 %SRR1: 800000000000b002 %LR: 0000000000c3ad44 %CTR: 80000000001af404 %DAR: 0000000000000000 PFW: Unable to send error log! ok 0 > The " 0 > " is the SLOF prompt, returning the control to the open firmware. This problem is found when using both ppc32 and ppc64 images, found at images/netboot/ directory of the ISO. This machines can boot F7-test3 and F6 netboot images from the same server. -Jose Otavio --------------------------------------------------------------------------------- I included this bug at "ship issue" level, because we don't know if this problem would show up for a install based on a burned CD or DVD. We've seen this problem using the netboot images. That's the reason why this isn't a "block". In case someone else has seen similar problems with the other install possibilities, this would change. It is interesting to notice that the same ppc64.img has been used to sucessfully install QS20 (Cell) machines, from the same image server. -Jose Otavio
----- Additional Comments From joseferr.com 2007-05-11 13:46 EDT ------- Amit, I was able to normally boot a Fedora 6.93 burned CD at one of the machines. Everything works as it should, using the ISO CD approach. No changes to the netboot image tho, so I'm leaving this as a ship issue.
At this point in the boot process, I'm not sure if control has transferred to the kernel image yet... David, are you aware of changes between f7t3 and f7t4 that could cause a problem with netbooting?
Not unless it's just a problem with the size of the image -- which is actually not unheard-of.
----- Additional Comments From amitarora.com 2007-05-17 06:24 EDT ------- RedHat Team, Is there anything that we can try and help to get more information on this bug ?
------- Additional Comments From joseferr.com 2007-05-17 08:34 EDT ------- (In reply to comment #15) > ----- Additional Comments From dwmw2 2007-05-12 01:09 EST ------- > Not unless it's just a problem with the size of the image -- which is actually > not unheard-of. > > -- I tried to use 3 different machines as servers, which used 3 different downloaded ISOs and they all had the sha1sum checked, without any troubles. None of the images/netboot/ppc64.img provided by the ISOs worked. Thinking it could be something specific for the files of the 6.93's ISO, I tried to use 0427 and 0511 rawhide ppc64 netboot images, and they didn't work either. The test4 ppc64.img is 9.1 MB X test3 is 9.0 MB. I think this is what I could say about the sizes for now. Thanks.
----- Additional Comments From amitarora.com 2007-06-05 02:33 EDT ------- Redhat Team, Are you able to reproduce the problem at your side ? What should be the next step here to proceed further ?
------- Additional Comments From joseferr.com 2007-06-05 09:59 EDT ------- (In reply to comment #19) > Redhat Team, > > Are you able to reproduce the problem at your side ? What should be the next > step here to proceed further ? Fedora 7 was GA'd last thursday and the new netboot images provided with the ISO don't boot the previous mentioned machines too. the files are $ISO/images/netboot/ppc[32|64].img This issue had previously entered a "to do" list from Fedora to correct it.
----- Additional Comments From amitarora.com 2007-07-02 06:32 EDT ------- Redhat, Any update here, plz ?
Apologies for the delay. Please could you try the netboot image at http://david.woodhou.se/zImage.f8 which is a Fedora 8 installer. This uses the zImage wrapper code from the kernel rather than an old copy which we made some time ago. If this doesn't work, then it's an upstream issue which we can continue to pursue. 7e2a0319a1cb48d84234350005db0d0d zImage.f8
Attempting to boot the zImage.f8 posted in comment#9, I hit the following on several power5 systems: 0 > boot network:,\ppc\zImage.f8 BOOTP: chosen-network-type = ethernet,auto,rj45,auto BOOTP: server IP = 0.0.0.0 BOOTP: requested filename = \ppc\zImage.f8 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 S = 2 FILE: /ppc/zImage.f8 FINAL Packet Count = 21106 FINAL File Size = 10805829 bytes. load-base=0x4000 real-base=0xc00000 CLAIM failed Call History ------------ throw - c3903c $call-method - c46d48 (poplocals) - c3a738 (init-program) - c7d728 boot - c7e36c evaluate - c4a638 invalid pointer - e03c1d invalid pointer - 7 invalid pointer - 7 quit - c4acf8 quit - c4aae0 My Fix Pt Regs: 00 0000000000000000 0000000000000000 00000000deadbeef 0000000000c46d44 04 0000000000c3fdc8 0000000000000007 0000000000c11f60 0000000000c03010 08 0000000008000000 0000000000000004 000800001c00000f 80000000001c3b80 0c 0000000000004000 0000000000c17100 0000000000c18000 00000000000e86b0 10 0000000000e80574 0000000000e80298 0000000000c46d40 0000000000c46d48 14 fffffffffffffffe 0000000000004000 0000000000000000 0000000000000000 18 0000000000c13000 0000000000c38000 0000000000c14fc0 0000000000c16fc0 1c 0000000000c20000 0000000000c3fdd0 0000000000c11fa8 0000000000c10ff8 Special Regs: %IV: 00000900 %CR: 22808000 %XER: 20000001 %DSISR: 00000000 %SRR0: 0000000000c3c808 %SRR1: 800000000000b002 %LR: 0000000000c3ad6c %CTR: 0000000000c46d0c %DAR: 0000000000000000 PFW: Unable to send error log! ok 0 >
I believe that error is from the firmware, having failed to load the image. Is there someone on the IBM side who knows more about the firmware limitations?
Please could you also test http://david.woodhou.se/zImage.f8.16MiB and http://david.woodhou.se/zImage.f8.32MiB
(In reply to comment #12) > http://david.woodhou.se/zImage.f8.16MiB 0 > boot network:,\ppc\zImage.f8.16MiB BOOTP: chosen-network-type = ethernet,auto,none,auto BOOTP: server IP = 0.0.0.0 BOOTP: requested filename = \ppc\zImage.f8.16MiB BOOTP: client IP = 0.0.0.0 BOOTP: client HW addr = 46 2a b0 0 70 2 BOOTP: gateway IP = 0.0.0.0 BOOTP: device /vdevice/l-lan@30000002 BOOTP: loc-code U9123.710.10004CA-V7-C2-T1 BOOTP: wait 60 seconds for Spanning Tree ... BOOTP R = 1 BOOTP S = 2 FILE: /ppc/zImage.f8.16MiB FINAL Packet Count = 21106 FINAL File Size = 10805829 bytes. load-base=0x4000 real-base=0xc00000 CLAIM failed Call History ------------ throw - c3903c $call-method - c46d48 (poplocals) - c3a738 (init-program) - c7d728 boot - c7e36c evaluate - c4a638 LߖxâM!§ë¨/¥µЪØm¹»¥ʹߓBX³Z·Ǝa6ЮÜ Ñ6è]Ó²DmÚ÷K8 - c17100 invalid pointer - 83 invalid pointer - 83 quit - c4acf8 quit - c4aae0 My Fix Pt Regs: 00 0000000000000000 0000000000000000 00000000deadbeef 0000000000c46d44 04 0000000000c3fdc8 0000000000000083 0000000000c11f60 0000000000c03010 08 0000000008000000 0000000000000000 0000000000000000 80000000000d8cb4 0c 0000000000004000 0000000000c17100 0000000000c18000 00000000000e86b0 10 0000000000de4f38 0000000000de4d08 0000000000c46d40 0000000000c46d48 14 fffffffffffffffe 0000000001bfd4c0 0000000000000000 0000000000000000 18 0000000000c13000 0000000000c38000 0000000000c14fc0 0000000000c16fc0 1c 0000000000c20000 0000000000c3fdd0 0000000000c11fa8 0000000000c10ff8 Special Regs: %IV: 00000900 %CR: 42808000 %XER: 20000008 %DSISR: 00000000 %SRR0: 0000000000c3a43c %SRR1: 800000000000b002 %LR: 0000000000d2db44 %CTR: 0000000000c3ad38 %DAR: 0000000000000000 PFW: Unable to send error log! ok > http://david.woodhou.se/zImage.f8.32MiB BOOTP R = 1 BOOTP S = 2 FILE: /ppc/zImage.f8.32MiB FINAL Packet Count = 21106 FINAL File Size = 10805829 bytes. load-base=0x4000 real-base=0xc00000 Elapsed time since release of system processors: 11343 mins 33 secs zImage starting: loaded at 0x02000000 (sp: 0x0199fea0) Allocating 0x825eb0 bytes for kernel ... OF version = 'IBM,SF240_219' gunzipping (0x02b00000 <- 0x02007000:0x022881d5)...done 0x771000 bytes Attached initrd image at 0x02289000-0x02a3c547 initrd head: 0x1f8b0800 Linux/PowerPC load: Finalizing device tree... using OF tree (promptr=00c39a48) ... Starting Linux PPC64 #1 SMP Tue Oct 30 13:05:49 EDT 2007 ----------------------------------------------------- ppc64_pft_size = 0x19 physicalMemorySize = 0x40000000 ppc64_caches.dcache_line_size = 0x80 ppc64_caches.icache_line_size = 0x80 htab_address = 0x0000000000000000 htab_hash_mask = 0x3ffff ----------------------------------------------------- Linux version 2.6.23.1-42.fc8 (kojibuilder.phx.redhat.com) (gcc version 4.1.2 20070925 (Red Hat 4.1.2-33)) #1 SMP Tue Oct 30 13:05:49 EDT 2007 ... Welcome to Fedora for ppc +---------+ Choose a Language +---------+ | | | What language would you like to use | | during the installation process? | | | | Catalan ^ | | Chinese(Simplified) : | | Chinese(Traditional) # | | Croatian : | | Czech : | | Danish : | | Dutch : | | English v | | | | +----+ | | | OK | | | +----+ | | | | | +---------------------------------------+
------- Comment From mohd.omar.com 2007-12-10 02:21 EDT------- Hi David, Whether this BUG helps you? https://bugzilla.novell.com/show_bug.cgi?id=335580#c3 I think there is a limitation of size to be loaded via tftp on Power boxes. I too faced this problem. As a workaround I used suse yaboot to load ppc64.img. F8 yaboot gives me a error "Claim error, can't allocate kernel memory". One more workaround is to load /ppc/ppc64/vmlinuz /ppc/ppc64/ramdisk.image.gz via yaboot. --Regards Omar
Assigning to yaboot then. We'll need it to handle TFTP of large files...
------- Comment From mohd.omar.com 2008-01-30 22:55 EDT------- Hi David, F9alpha netboot image also doesn't works on Power5. --log--- BOOTP: chosen-network-type = ethernet,auto,none,auto BOOTP: server IP = 0.0.0.0 BOOTP: requested filename = BOOTP: client IP = 0.0.0.0 BOOTP: client HW addr = 36 cb 20 0 40 2 BOOTP: gateway IP = 0.0.0.0 BOOTP: device /vdevice/l-lan@30000002 BOOTP: loc-code U9133.55A.06DF42G-V4-C2-T1 BOOTP: wait 60 seconds for Spanning Tree ... BOOTP R = 1 BOOTP S = 2 FILE: ppc64.img FINAL File Size = 12566528 bytes. load-base=0x4000 real-base=0xc00000 \ Elapsed time since release of system processors: 273187 mins 25 secs --Regards Omar
Can you try latest yaboot git (http://yaboot.ozlabs.org has instructions) a binary is here: http://people.fedoraproject.org/~pnasrat/yaboot You'll have to run /usr/lib/yaboot/addnote /tmp/yaboot on it first I think, and netboot that yaboot
------- Comment From mohd.omar.com 2008-01-31 03:16 EDT------- Hi paul, The latest yaboot git http://people.fedoraproject.org/~pnasrat/yaboot could pick up the netboot image "ppc64.img" correctly. It works fine. I wonder if it can be incorporated with F9alpha before releasing it(scheduled for 5Feb08). --Regards Omar
------- Comment From mohd.omar.com 2008-01-31 03:42 EDT------- Does we need 'yaboot' for netboot ? It suppose to work individually.It was a work around that I used 'yaboot' to load "ppc64.img". Can we improve netboot image to get loaded via tftp without using yaboot? --Regards Omar
(In reply to comment #19) > Does we need 'yaboot' for netboot ? It suppose to work individually.It was a > work around that I used 'yaboot' to load "ppc64.img". Can we improve netboot > image to get loaded via tftp without using yaboot? No, I believe the size limit is in IBM's firmware -- you'd have to fix the firmware. Alternatively, please suggest a link address which might work... Otherwise, I think netbooting via yaboot is the way forward... at least on boxes with problematic firmware. The stock ppc64.img works fine on my Electra...
Hm. Comment #13 suggests that a link address of 32MiB should work. Can you confirm that this will work on all versions of IBM firmware? I had a distinct recollection that it didn't work on some machines.
------- Comment From jwboyer.com 2008-01-31 07:03 EDT------- (In reply to comment #60) > Hi paul, > The latest yaboot git http://people.fedoraproject.org/~pnasrat/yaboot could pick > up the netboot image "ppc64.img" correctly. It works fine. I wonder if it can be > incorporated with F9alpha before releasing it(scheduled for 5Feb08). Alpha is frozen at the moment and won't be picking up updates. Let's try to work with the Red Hat yaboot owner to get yaboot updated and into Beta. josh
------- Comment From kenblake.com 2008-03-26 16:08 EDT------- (In reply to comment #64) > Alpha is frozen at the moment and won't be picking up updates. Let's try to > work with the Red Hat yaboot owner to get yaboot updated and into Beta. > We are seeing this in our lab with F9 Beta. I have had issues installing a QS20, JS20 and JS24. Any chance this will be fixed soon?
------- Comment From jwboyer.com 2008-03-26 16:30 EDT------- From today's kernel.spec file in Fedora CVS: * Wed Mar 26 2008 David Woodhouse <dwmw2> - Link PowerPC zImage at 32MiB (#239658 on POWER5, also fixes Efika) So it would be good to try with tomorrow's rawhide to see if that change makes a difference.
There seems to be conflicting information on the state of the patches to fix this on HEAD - please can you provide test information (h/w), any additional patches on top of git HEAD and console output to yaboot-devel or yaboot-users. See also http://ozlabs.org/pipermail/yaboot-users/2008-February/thread.html Even if the link address change fixes the zImage I'd like to ensure that we can consistently netboot large images using yaboot.
------- Comment From IndhuDurai.com 2008-04-29 07:47 EDT------- Hi, I am finding the issue reproduced in Fedora9preview release as well. Machine is not booting with /tftpboot/ppc64.img. Regards, Indhu D
Gr. Which machine? What if you link the zImage at 64MiB?
------- Comment From kenblake.com 2008-04-29 12:23 EDT------- (In reply to comment #69) > ------- Comment From dwmw2 2008-04-29 08:00 EST------- > Gr. Which machine? What if you link the zImage at 64MiB? I too am seeing this issue with a JS21 and F9Preview. If you could detail the process for booting the installer via yaboot, I will try it with this system and see if it gets around the issue.
Assuming running tftp/dhcp on linux (if on AIX I think tftpserver runs off / so may have to change to run in root of /tftpboot) 1) Create yaboot on my tftp server for the machine being netbooted. And copy in the appropriate yaboot binary $ mkdir /tftpboot/ppc/ $ cp /path/to/F-9/ppc/chrp/yaboot /tftpboot/ppc/ 2) Copy yaboot.conf kernel and initrd onto server $ mkdir /tftpboot/etc $ cp /path/to/F-9/etc/yaboot.conf /tftpboot/ppc $ mkdir -p /tftpboot/ppc/ppc64 $ cp /path/to/F-9/ppc64/* /tftpboot/ppc/ppc64 3) Edit yaboot.conf, remove ppc32 entries and change label=linux64 to label=linux 4) Create a default 'filename' for that system in my dhcpd.conf host ibm-sf2b-lp1 { hardware ethernet 00:11:22:33:44:55; fixed-address ibm-sf2b-lp1.example.com; filename "ppc/yaboot"; } 5) Boot into OF $ boot network [*] assumes 'network' is valid device aliases
Does F-9 yaboot have all the latest TFTP-related patches? It's still 1.3.13.
No it doesn't have everything from 1.3.14/HEAD (particularly the pxelinux style boot) but it should netboot on IBM Power machines
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Created attachment 306647 [details] Link zImage at 64Mb rather than 4Mb. Move real-base from 12Mb to 32Mb As far as I can tell we have a couple of problems: 1) the filesize of the zImage (vmlinux and initrd) is greater than (12Mb - 16Kb) 2) the Default link address of the zImage is too low. (4Mb) problem (2) is relatively simple to solve, but doesn't help with problem (1). Moving real-base is the only way to solve this problem (1). For small zImages a patched kernel should boot with no visible differences, for large zImages, real-base will bneed to be set to 32Mb (0x2000000) before the zImage is loaded. This works around firmware problems. I attempted to use yaboot to workout some of these problems but as yet I can't get PXE style tftp'ing of the config file to work :( This patch has been boot tested on POWER3,4,5,5+, 6 and JS20. If people don't object I'll push it to Paulus for 2.6.27.
reopening Red Hat bugzilla per comment #32 ...
------- Comment From hannsj_uhl.com 2008-06-26 03:40 EDT------- fyi .. copying the following comment over from Red Hat bugzilla 254120: Netboot with ppc64.img fails booting to this bugzilla: " Comment #6 From Jim Lindeman (lindj.com) on 2008-06-25 14:35 EST [reply] The issue is because the ELF-header at the beginning of the Linux image has an inappropriate value for the "real-base" setting, which tells where Open Firmware should sit in memory. The Linux image is downloaded starting at address 0x4000 ("load-base" setting also in the ELF-header), and if the "real-base" is not set high enough for the OS image to fit, the download will fail. In this particular error above, the "real-base" setting was still at 12Mb (0xC00000). Note that while the OS binary would still fit (was just under 11Mb), the "program image size" (which includes the BSS section, not in the binary), would overflow above the 12Mb threshold and that's why the "CLAIM failed". AIX sets the "real-base" in their ELF header to 32Mb (0x2000000), so they don't ever hit this issue. This is a bug for Fedora to fix. " ------- Comment From hannsj_uhl.com 2008-06-26 03:41 EDT------- fyi .. a patch for this bugzilla was posted at 6/23 at http://patchwork.ozlabs.org/linuxppc/patch?id=19122 ...
Still happening in F10-alpha ... comment#35 from IBM points to a porposed patch to resolve the issue.
... which is now accepted upstream into 2.6.27-rc1 as " commit 9b09c6d909dfd8de96b99b9b9c808b94b0a71614 Author: Tony Breeds <tony> Date: Tue Jun 24 14:20:29 2008 +1000 powerpc: Change the default link address for pSeries zImage kernels Currently we set the start of the .text section to be 4Mb for pSeries. In situations where the zImage is > 8Mb we'll fail to boot (due to overlapping with OF). Move .text in a zImage from 4MB to 64MB (well past OF). We still will not be able to load large zImage unless we also move OF, to that end, add a note to the zImage ELF to move OF to 32Mb. If this is the very first kernel booted then we'll need to move OF manually by setting real-base. Signed-off-by: Tony Breeds <tony> Signed-off-by: Paul Mackerras <paulus> "
(In reply to comment #88) > ------- Comment From jlaska 2008-07-30 08:55 EST------- > Still happening in F10-alpha ... comment#35 from IBM points to a porposed patch > to resolve the issue. Silly question .... Where can I get the F10 Alpha?
L?????b?x??M??!??????/????????m????????b?BX??Z?????a6???? ??6??]????Dm????K??8 - c17100
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
? ?L?????b?x??M??!??????/????????m????????b?BX??Z?????a6???? ??6??]????Dm????K??8 - c17100
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.