Description of problem: * RHEL5.3-Server-2008091[4567].nightly * Error appears through automate RHTS testing * Behavior appears ppc dependent Version-Release number of selected component (if applicable): RHEL5.3-Server-2008091[4567].nightly How reproducible: Always Steps to Reproduce: 1. Try a nfs install from pxe with a ks.cfg file. Actual results: Config file read, 1024 bytes Welcome Welcome to yaboot version 1.3.12 Enter "help" to get some basic usage information Default supplied on the command line: linux ksdevice=eth1 ks=http://rhts.redhat.com/ks/hosts/ibm-js20-01.lab.bos.redhat.com/ks.cfg nousbstorage boot: linux ksdevice=eth1 ks=http://rhts.redhat.com/ks/hosts/ibm-js20-01.lab.bos.redhat.com/ks.cfg nousbstorage Please wait, loading kernel... /pci@8000000f8000000/ide@4,1/disk@0:2,vmlinux-anaconda: No such file or directory boot: Expected results: Install should work Additional info: Links to several logs: Log for ppc RHEL5.3-Server-20080917.nightly http://rhts.redhat.com/cgi-bin/rhts/test_log.cgi?id=4338561 Log for ppc RHEL5.3-Server-20080916.nightly http://rhts.redhat.com/cgi-bin/rhts/test_log.cgi?id=4316846 Log for ppc RHEL5.3-Server-20080915.nightly http://rhts.redhat.com/cgi-bin/rhts/test_log.cgi?id=4300584 Log for ppc RHEL5.3-Server-20080914.nightly http://rhts.redhat.com/cgi-bin/rhts/test_log.cgi?id=4292806
Can you please run the test with the 20080918 that is the last compose.
Ignore the part about vmlinuz-anaconda. Thats us trying to load the kernel from local yaboot but we misconfigured yaboot.conf. I can get a kickstart for you but it doesn't even get that far. You really just need a netboot image to test this.
Brock, When these test failed it was during RHTS test run. By the time I came in the machine was already being used for another test. So I do not have the ks.cfg available. I don't think it is needed anymore based on talking with Bill. Jeff
this seem to be size issues. When ppc64 is booted with a netimage that is 8.6 Mb it gets past the point where it hung before. Currently testing to see what the roof value is. I see two ways out of this one. Either take stuff out of the image, which may cause some funckyness. Or, update the firmware. Don't know much about the firmware involved, maybe someone can chime in.
If this in fact a size thing, it's really unlikely there's anything we can do. For just this one release alone, we've had to add ext4 programs, iscsi utilities, lots of nss libraries required by the new RPM, and various crypto utilities. These additions are all driven by feature requests for anaconda, and we're not going to be able to remove them or conditionalize them based on arch. So if we can't find another fix, I'm afraid netboot.img simply isn't going to work on 5.3. And it's definitely not going to work on RHEL6 either, because the initrd.img will be even bigger there.
I was told it has been deprecated if Fedora. Is there any reason we still need to carry it in RHEL6? I am not sure how many customers use it currently. But After talking with Bill This is an issue with the size of the netboot image. So I think at this point we are going to have to talk to PM and find out if this regression is acceptable.
Personally, I'm with Chris here. I prefer not having netboot on one architecture than having to take out a whole bunch of cool stuff for the other archs. Additionally, note that only the netboot is affected. The installation with Yaboot is still possible.
From the installers point of view we could make the image smaller by taking out stuff, which would cause a regression. So most probably the answer we are looking for is in the firmware. I don't know what needs to be done to increase the capacity of the firmware. What component would that be?
please try this workaround and let me know if you can netboot 1) boot the system to the Open Firmware prompt 2) setenv real-base 2000000 let me know if that allows it work.
can you remind me how to get to the Open Firmware prompt? I know I'm supposed to hit some key at E1F1 I believe but its been a while and I can't remember.
I figured it out. So far this seems to have done the trick.
at e1f1 hit '8' key. otherwise with the SMS screens come up it will say to press 1 for SMS and 8 for OF
after the install it seems real-base gets reset to real-base=0xc00000. Watching the boot it seems like yaboot has a problem loading, it spits some more numbers on the screen and then loads yaboot again. The second time it works and the system comes up. but now real-base is reset to 0xc00000. Does this make sense to anyone?
Created attachment 317717 [details] Patch to update RPA notes in addnote.c and prom_init.c This is the patch and comments for this. The patch is not against the rhel5u3 kernel I dont have it but it shouldnt be hard to apply =======================================================================It appears that the only way to get this to all work correctly is to have an RPA note in the zImage wrapper that matches what the kernel will provide in its CAS struct. For now the short-term fix will be to patch addnote.c to provide values that match what the kernel currently uses. Longer-term it would be better if addnote and/or the wrapper script could dig out the CAS values from the kernel and put them in the RPA note. I did a test where I modified the RPA note in the inst64 image. That got into the kernel OK, but failed to instantiate RTAS because it was out of memory in the 128MB RMA. Moving the load address of the zImage down to the 56MB point fixed that. I will look at whether it would be better to make the wrapper use memory more efficiently instead. ============================================================================= This patch updates the RPA notes in arch/powerpc/boot/addnote.c and arch/powerpc/kernel/prom_init.c to correspond with each other and with the CAS struct that the kernel provides to firmware. The main changes are: - ignore_my_client_config flag is now set to 0 (don't ignore) in addnote.c so that firmware will act on the real_base setting in the CHRP note and move itself to the 32MB point - min RMA size is set to 128MB (and in the CAS struct too) - new_mem_def and large_page_ready are set to 1 to correspond with what the CAS struct says (and what the kernel can do).
IBM, have you successfully tested this patch?
Paul Mackerras did some testing but it was not with a different kernel. I can try and see if I can make a rhel5u2 netboot image that is too large and then apply the patch to that and see if it fixes it. the first sentence above is confusing. it should read: Paul Mackerras did some testing but it was with a different kernel
Created attachment 317842 [details] rebased patch to the rhel5u2 kernel this patch is rebased on the rhel5u2 (.92) kernel. I made a kernel with an attached initrd that was not compressed. then I made a zImage.initrd that was large. When I netbooted that image the netboot failed to download to the system. When I applied the patch and built a kernel with the same initrd then the kernel would complete the downloading.
Comment on attachment 39361 testing failed on one my my partitions. I'm not satisfied the patches are correct. I'm marking them obsolete and will do more testing on them
I found the problem with your patch. The patch enables some "features" of the hypervisor that aren't supported by the RHEL5 kernel and don't match the CAS info, so the firmware keeps rebooting a it gets conflicting settings between the zImage header and the CAS call in prom_init.c Specifically, the new layout for memory properties isn't supported, at least our CAS claims it's not, so we must not set new_mem_def to 1. Just changing that flag in both addnote.c and prom_init.c makes it boot again. Note that there's also another difference between SLES11+upstream vs. RHEL5 which is the link address of the zImage wrapper which is set to 64M in SLES11 afaik and 4M on RHEL5. That may also be a problem with large images, you may want to change arch/powerpc/boot/zImage.lds the 4*1024*1024 statement to something like 64*1024*1024, or maybe a bit less, ie paul is suggesting 56M to avoid problems with instanciating RTAS.
Ameet Paranjape <ameet.com> is taking over the RH Onsite Liason role from me, effective today, 10/1/08. Feel free to CC me on messages, but please communicate with him from here on out
Created attachment 319144 [details] Patch to set set real-base Have a patch that I was able to verify that it would change the real-base to 2000000 and not cause constant rebooting.
Please consider this under the exception process
Requesting release note. IBM, please propose release note text.
RH. the failure has been with the test NOT the patch. I was trying to use mkzimage to combine and kernel and an initrd to netboot. This doesnt work. When I just do a 'make zImage.initrd' and net boot that image the real base is updated as expected. Ameet is making me one last test image using the new commands. Please still consider this patch Very Rough Release Notes: Netbooting on PPC is presently broken, likely because the size of the netboot image has grown beyond the ability of OpenFirmware to support. Users will simply see the system die on netboot with the following messages: <Insert error msgs here> If this happens, use the following work-around. This will need to be done each time the kernel is netbooted. First, boot to the OpenFirmware prompt, by pressing the '8' key early in boot, (when the IBM splash screen is displayed) Execute: "setenv real-base 2000000" Then proceed to boot into SMS with: "0> dev /packages/gui obe" From there, you can select to do a network boot as usual. test the image Ameet made. made sure real-base was c00000 before netbooting the image and real-base was 2000000 after so it works.
This has been tested and verified to work on the -117 kernel. The patch has been posted to RKML for review IBM would appreciate it if Red Hat would still consider this for the Beta release of RHEL 5.3.
Posted for review: http://post-office.corp.redhat.com/archives/rhkernel-list/2008-October/msg00139.html
The Red Hat maintainer has some questions about the patch. Could you please clarify. ----------------------------------------------------- > > - 0x00c00000, /* real-base, i.e. where we expect OF to be */ > > + 0x02000000, /* real-base, i.e. where we expect OF to be */ Does this require OF to be patched? No the 0x02000000 is the location FW expects the realbase to be. The workaround for this problem was to have the admin boot to the OF prompt and run 'setenv 2000000'. This is simply getting the kernel to match what FW already expects > > - 0, /* lparaffinity */ > > + 1, /* lparaffinity */ What does that do? the description in the PAPR+ doc reads: The ns.lparaffinity field is a binary flag whose valid values are 0 or 1. If the field is not one of these valid values the value is assumed to be 0. If the character value is 1, the client program requests that the platform provide all available affinity information. This field is only relevant for POWER 4 architecture. Paul had included this in his change to make sure that addnote.c and prom_init.c fields were in sync. > > - 1, /* ignore_my_client_config */ > > + 0, /* ignore_my_client_config */ When this is set to 1 it means to ignore my settings in the RPA section. We dont want to be ignored, this patch sets the value that we want. > > + 0, /* force_alpha_mode */ And these? When this is set to 1 it means to ignore my settings in the RPA section. We dont want i.e.a "full-system" partition being converted into one that can load/run the IVM/VIOS image. The "alpha" partition has a special virtual device (VMC node) that allows it to communicate HMC-like commands to the hypervisor directly.
Here is an updated release note: Netbooting on PPC is presently broken. The combined size of the kernel and initrd is larger that the space allocated for it by OpenFirmware. Users will see the system fall back to the OpenFirmware prompt will a message similiar to this: "initrd CORRUPTION. memory range 04312e6c 055ae3a8 Expected md5 52e82f59dbc739dc8af725879b7eec9a Got md5 f0b1363efdb998ff3b4f2c42d71aeaff initrd corrupted EXIT called ok 0 >" If this happens, use the following work-around. This will only need to be once. First, boot to the OpenFirmware prompt, by pressing the '8' key early in boot, (when the IBM splash screen is displayed) IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM 1 = SMS Menu 5 = Default Boot List 8 = Open Firmware Prompt 6 = Stored Boot List At the OpenFirmware prompt (0 >)Execute: "setenv real-base 2000000" To verify the command worked execute: "printenv real-base" Then proceed to boot into SMS with: "0> dev /packages/gui obe" fix a type and some formatting: Netbooting on PPC is presently broken. The combined size of the kernel and initrd is larger that the space allocated for it by OpenFirmware. Users will see the system fall back to the OpenFirmware prompt with a message similiar to this: "initrd CORRUPTION. memory range 04312e6c 055ae3a8 Expected md5 52e82f59dbc739dc8af725879b7eec9a Got md5 f0b1363efdb998ff3b4f2c42d71aeaff initrd corrupted EXIT called ok 0 >" If this happens, use the following work-around. This will only need to be once. First, boot to the OpenFirmware prompt, by pressing the '8' key early in boot, (when the IBM splash screen is displayed) IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM IBM 1 = SMS Menu 5 = Default Boot List 8 = Open Firmware Prompt 6 = Stored Boot List At the OpenFirmware prompt (0 >)Execute: "setenv real-base 2000000" To verify the command worked execute: "printenv real-base" Then proceed to boot into SMS with: "0> dev /packages/gui obe"
in kernel-2.6.18-118.el5 You can download this test kernel from http://people.redhat.com/dzickus/el5
downloaded the kernel suggested looked at the source for it and the source contained the patch. However the rpm only had the vmlinuz kernel. When I do a file on it I get ]# file vmlinuz-2.6.18-118.el5 vmlinuz-2.6.18-118.el5: ELF 64-bit MSB executable, cisco 7500, version 1 (SYSV), statically linked, stripped When I look at the ga'd rhel5u2 network install image I get: file rhel5u2 rhel5u2: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), statically linked, not stripped I'm looking more for the rhel5u2 install image to test with. I need something that is built with arch/powerpc/boot/addnote.c (ie zImage or better yet zImage.initrd). Then I can try and netboot that and see if the real-base is changed.
RHEL5.3-Server-20081006.0 still fails the exact same way. kernel-2.6.18-118.el5.ppc64.rpm http://rhts.redhat.com/cgi-bin/rhts/jobs.cgi?id=31690
the link posted in the comment above is private to RH. I can't view what happened. Also can RH provide the steps they use to make their net boot install image.
TFTP BOOT --------------------------------------------------- Server IP.....................10.16.64.10 Client IP.....................10.16.44.91 Gateway IP....................10.16.47.254 Subnet Mask...................255.255.248.0 Filename......................ppc/0A102C5B/netboot TFTP Retries..................5 Block Size....................512 FILE : ppc/0A102C5B/netboot BLKSIZE : 512 TFTP-RETRIES: 5 PACKET COUNT = 100 PACKET COUNT = 200 PACKET COUNT = 300 PACKET COUNT = 400 PACKET COUNT = 500 PACKET COUNT = 600 PACKET COUNT = 700 PACKET COUNT = 800 PACKET COUNT = 900 PACKET COUNT = 1000 PACKET COUNT = 1100 PACKET COUNT = 1200 PACKET COUNT = 1300 PACKET COUNT = 1400 PACKET COUNT = 1500 PACKET COUNT = 1600 PACKET COUNT = 1700 PACKET COUNT = 1800 PACKET COUNT = 1900 PACKET COUNT = 2000 PACKET COUNT = 2100 PACKET COUNT = 2200 PACKET COUNT = 2300 PACKET COUNT = 2400 PACKET COUNT = 2500 PACKET COUNT = 2600 PACKET COUNT = 2700 PACKET COUNT = 2800 PACKET COUNT = 2900 PACKET COUNT = 3000 PACKET COUNT = 3100 PACKET COUNT = 3200 PACKET COUNT = 3300 PACKET COUNT = 3400 PACKET COUNT = 3500 PACKET COUNT = 3600 PACKET COUNT = 3700 PACKET COUNT = 3800 PACKET COUNT = 3900 PACKET COUNT = 4000 PACKET COUNT = 4100 PACKET COUNT = 4200 PACKET COUNT = 4300 PACKET COUNT = 4400 PACKET COUNT = 4500 PACKET COUNT = 4600 PACKET COUNT = 4700 PACKET COUNT = 4800 PACKET COUNT = 4900 PACKET COUNT = 5000 PACKET COUNT = 5100 PACKET COUNT = 5200 PACKET COUNT = 5300 PACKET COUNT = 5400 PACKET COUNT = 5500 PACKET COUNT = 5600 PACKET COUNT = 5700 PACKET COUNT = 5800 PACKET COUNT = 5900 PACKET COUNT = 6000 PACKET COUNT = 6100 PACKET COUNT = 6200 PACKET COUNT = 6300 PACKET COUNT = 6400 PACKET COUNT = 6500 PACKET COUNT = 6600 PACKET COUNT = 6700 PACKET COUNT = 6800 PACKET COUNT = 6900 PACKET COUNT = 7000 PACKET COUNT = 7100 PACKET COUNT = 7200 PACKET COUNT = 7300 PACKET COUNT = 7400 PACKET COUNT = 7500 PACKET COUNT = 7600 PACKET COUNT = 7700 PACKET COUNT = 7800 PACKET COUNT = 7900 PACKET COUNT = 8000 PACKET COUNT = 8100 PACKET COUNT = 8200 PACKET COUNT = 8300 PACKET COUNT = 8400 PACKET COUNT = 8500 PACKET COUNT = 8600 PACKET COUNT = 8700 PACKET COUNT = 8800 PACKET COUNT = 8900 PACKET COUNT = 9000 PACKET COUNT = 9100 PACKET COUNT = 9200 PACKET COUNT = 9300 PACKET COUNT = 9400 PACKET COUNT = 9500 PACKET COUNT = 9600 PACKET COUNT = 9700 PACKET COUNT = 9800 PACKET COUNT = 9900 PACKET COUNT = 10000 PACKET COUNT = 10100 PACKET COUNT = 10200 PACKET COUNT = 10300 PACKET COUNT = 10400 PACKET COUNT = 10500 PACKET COUNT = 10600 PACKET COUNT = 10700 PACKET COUNT = 10800 PACKET COUNT = 10900 PACKET COUNT = 11000 PACKET COUNT = 11100 PACKET COUNT = 11200 PACKET COUNT = 11300 PACKET COUNT = 11400 PACKET COUNT = 11500 PACKET COUNT = 11600 PACKET COUNT = 11700 PACKET COUNT = 11800 PACKET COUNT = 11900 PACKET COUNT = 12000 PACKET COUNT = 12100 PACKET COUNT = 12200 PACKET COUNT = 12300 PACKET COUNT = 12400 PACKET COUNT = 12500 PACKET COUNT = 12600 PACKET COUNT = 12700 PACKET COUNT = 12800 PACKET COUNT = 12900 PACKET COUNT = 13000 PACKET COUNT = 13100 PACKET COUNT = 13200 PACKET COUNT = 13300 PACKET COUNT = 13400 PACKET COUNT = 13500 PACKET COUNT = 13600 PACKET COUNT = 13700 PACKET COUNT = 13800 PACKET COUNT = 13900 PACKET COUNT = 14000 PACKET COUNT = 14100 PACKET COUNT = 14200 PACKET COUNT = 14300 PACKET COUNT = 14400 PACKET COUNT = 14500 PACKET COUNT = 14600 PACKET COUNT = 14700 PACKET COUNT = 14800 PACKET COUNT = 14900 PACKET COUNT = 15000 PACKET COUNT = 15100 PACKET COUNT = 15200 PACKET COUNT = 15300 PACKET COUNT = 15400 PACKET COUNT = 15500 PACKET COUNT = 15600 PACKET COUNT = 15700 PACKET COUNT = 15800 PACKET COUNT = 15900 PACKET COUNT = 16000 PACKET COUNT = 16100 PACKET COUNT = 16200 PACKET COUNT = 16300 PACKET COUNT = 16400 PACKET COUNT = 16500 PACKET COUNT = 16600 PACKET COUNT = 16700 PACKET COUNT = 16800 PACKET COUNT = 16900 PACKET COUNT = 17000 PACKET COUNT = 17100 PACKET COUNT = 17200 PACKET COUNT = 17300 PACKET COUNT = 17400 PACKET COUNT = 17500 PACKET COUNT = 17600 PACKET COUNT = 17700 PACKET COUNT = 17800 PACKET COUNT = 17900 PACKET COUNT = 18000 PACKET COUNT = 18100 PACKET COUNT = 18200 PACKET COUNT = 18300 PACKET COUNT = 18400 PACKET COUNT = 18500 PACKET COUNT = 18600 PACKET COUNT = 18700 PACKET COUNT = 18800 PACKET COUNT = 18900 PACKET COUNT = 19000 FINAL PACKET COUNT = 19077 FINAL FILE SIZE = 9767384 BYTES -\|/-\|/-\|/ Elapsed time since release of system processors: 4 mins 59 secs Config file read, 1024 bytes Welcome Welcome to yaboot version 1.3.13 (Red Hat 1.3.13-5.el5) Enter "help" to get some basic usage information The above is from the log. It shows the system loading the netboot image and then falling back to the locally installed yaboot. Someone from rel-eng will need to provide the details on how the netboot image is generated.
just want to make sure I'm looking at the correct code. Does RH netboot the install image directly or does RH have yaboot sent via dhcp and then use that to get the install image?
We netboot the install image directly
when the netboot doesnt work and it drops back to yaboot. Please reboot the system and go into the OpenFirmware (press 8 at IBM splash screen) then type the following command and let me know the result: printenv then after typing the printenv the type 'dev /packages/gui obe' to continue with the boot
When I try the netboot image it fails for me as well. When I reboot the system and look at real-base I see that it is unchanged: 0 > printenv real-base -------------- Partition: common -------- Signature: 0x70 --------------- real-base c00000 c00000 ok So my question is when the netboot image is constructed are the changes in arch/powerpc/boot/addnote.c part of that? What about the zImage.lds changes? Those changes affect where the kernel gets loaded and what real-base gets set to and if OF will accept the changes the kernel is suggesting. Can I get detailed steps on how the netboot image is constructed?
also tried the workaround with this install image and that didnt work either. Go right to a message that says 'No Operating System installed'
These comments did not get mirror from IBM Bugzilla: Comment #48 From Michael J. Wolf 2008-10-07 15:23:58 [reply] ------- going to try and get the ramdisk.image.gz that contains the install tool and put that together with a zImage made from the latest kernel source I have available and see if that works. If it does I would like to get it back to RH testers to make sure it works in their environment. ------- Comment #49 From Michael J. Wolf 2008-10-07 15:26:32 [reply] ------- Also it did not appear to me that the RPA note was part of the ELF header for the install image. I asked David Howells about this and he didnt see it either using the readelf command. So this leads me to believe we have the image without the RPA note, that means that OF wont be configured correctly and the installer wont work ------- Comment #50 From Michael J. Wolf 2008-10-07 16:08:37 [reply] ------- ok I took the installers ramdisk.image.gz and put it together with the latest kernel using the 'make zImage.initrd' command and the installer came up. So it definitely looks like this is a problem of getting addnote invoked properly on the image Also made sure that before I booted that real-base was set to c00000. After the installer came up, I restarted the system and booted to OF 0 > printenv real-base -------------- Partition: common -------- Signature: 0x70 --------------- real-base 2000000 2000000 real-base is changed as expected. ------- Comment #51 From Michael J. Wolf 2008-10-07 16:35:26 [reply] ------- ok after chatting with David Howells I decided to test one more thing. I took the original install image supplied to me that earlier did *not* work. I ran the program addnote <img name>. Then I looked at the image using hexdump -c and verified that the RPA config was part of the image. Next I put the image on my boot server and netbooted a partition. The partition booted to the installer. i then reset the system and booted to the OF prompt. I looked at real-base and it was properly modified to be 2000000. so the problem is the the rpa config is not part of the current installer. possible solutions 1) modify mk-images.ppc script to run addnote on the final image 2) change more of the rpm scripting and make a zImage.initrd and use that I will also make the addnote modified RH installer available to RH testers to try and verify for themselves that it works.
IBM was able to create a netboot image using the 118.el kernel source and a ramdisk.image.gz used by the internal Red Hat test team. I provided this image to the Red Hat test team and they were able to successfully boot and install on their POWER box. The next step is to fix the mk-image.ppc script used to build the netboot image so it incorporates IBM's fix (see RH BZ comment#47 (IBM comment #49)). David Howells is looking into this.
Actually, I hadn't got as far as looking at the mk-image.ppc script yet. I have come to the following conclusion, though: addnote is not run because the kernel RPM does not build the final, bootable kernel image used by the installer. I think we're going to need to have the kernel RPM specfile build addnote and install it in the kernel RPM so that the mk-image.ppc script has it available.
going to try and get the ramdisk.image.gz that contains the install tool and put that together with a zImage made from the latest kernel source I have available and see if that works. If it does I would like Also it did not appear to me that the RPA note was part of the ELF header for the install image. I asked David Howells about this and he didnt see it either using the readelf command. So this leads me to believe we have the image without the RPA note, that means that OF wont be configured correctly and the installer wont work ok I took the installers ramdisk.image.gz and put it together with the latest kernel using the 'make zImage.initrd' command and the installer came up. So it definitely looks like this is a problem of getting addnote invoked properly on the image Also made sure that before I booted that real-base was set to c00000. After the installer came up, I restarted the system and booted to OF ok after chatting with David Howells I decided to test one more thing. I took the original install image supplied to me that earlier did *not* work. I ran the program addnote <img name>. Then I looked at the image using hexdump -c and verified that the RPA config was part of the image. Next I put the image on my boot server and netbooted a partition. The partition booted to the installer. i then reset the system and booted to the OF prompt. I looked at real-base and it was properly modified to be 2000000. I will also make the addnote modified RH installer available to RH testers to try and verify for themselves that it works. (In reply to comment #48) > going to try and get the ramdisk.image.gz that contains the install tool and > put that together with a zImage made from the latest kernel source I have > available and see if that works. If it does I would like > to get it back to RH testers to make sure it works in their environment. Mike was able to create a netboot image using the 118.el kernel source and a ramdisk.image.gz used by the internal Red Hat test team. I provided this image to the Red Hat test team and they were able to successfully boot and install on their POWER box. The next step is to fix the mk-image.ppc script used to build the netboot image so it incorporates Mike's fix (see comment#49). David Howells (Red Hat) is looking into this.
Created attachment 319772 [details] Install addnote in the kernel RPMs Okay, I think the first step is to apply the attached patch to the kernel RPM spec file. This will cause it to include the addnote binary for the ppc64 arch. The second step is to get mk-image.ppc to call addnote; something I'm looking in to at the moment.
Created attachment 319776 [details] Add note to bootable kernel image The attached patch should be applied to the anaconda package. It should make mk-image.ppc add the note defined by the kernel RPM to the zImage. This is untested at the moment.
Pardon my ignorance, but what does the addnote binary do exactly? Is running addnote on the kernel image a temporary workaround or has Red Hat been using a broken script for a very long time?
The patch in comment #52 should be applied in anaconda-11.1.2.138-1 .
addnote will do a binary edit. It will fill in the RPA-config section in the ELF header. The RPA config sets up the OpenFirmware the way we need it. It is a little of both about scripts being broken. What is really triggering this, is the size of the kernel + initrd is larger that the default area that was currently being used. These changes will get the kernel loaded in an area properly
The ppc64 directly bootable kernel image should have an ELF note attached to provide OpenFirmware/yaboot with some parameters about what resources and environment the running kernel will require. The standard kernel tarball, if used to build the bootable image runs a program called addnote to add this ELF note to the final image. The RHEL-5 kernel RPM cannot do this because some of the components (notably the initrd image) are not available at this point, but rather are constructed by the installer. The mkzimage and mk-image.ppc scripts used by anaconda don't attempt to parameterise the final image by attaching the ELF note. I've provided two patches to hopefully deal with this. Both are required. The kernel spec file patch just builds and installs the addnote program in the kernel binary RPMs for ppc64. The anaconda patch causes mk-image.ppc to apply this program to the final image to add the ELF note.
Just be careful that images with the RPA note section in them might be harmful to netboot on PowerMac's. They can screw up the Apple OF to the point of rendering the G5 incapable of booting at all. You need to differenciate thus pSeries vs. PowerMac netboot images.
can someone give me a list of system types that will have supported network installing via ppc64.img? pseries powermacs cell blades any i didnt think of..... I want to make sure that the patch is targetted only to systems that need this fix
afaik, powermacs are the only ones with a problem. Apple OF runs in virtual mode and is very sensitive to the values of virt-base and real-base, if they are set to something they haven't tested with, OF becomes unbootable. This is why nowadays kernels build 2 different zImages, one for pmac and one for pseries (and everybody else).
Had a meeting tonight with Paul Mackerras and Ben H. and others to discuss options. We are worried about powermacs. If they try and load an image with these changes the powermac could become unbootable We are worried about powermacs because: - internal developers for may try and load on their G5's - the kernel config file for the kernel has both PSERIES and PMACxxx flags set. I dont have access to config file for the netboot.img itself. We propose that mk-images.ppc script be changed. David Howells added a line to run addnote on the ppc64.img file. I would like something like: + ADDNOTE=$KERNELROOT/kernel/arch/powerpc/boot/addnote + if [ -x "$ADDNOTE" ] + then + cp $TOPDESTPATH/images/netboot/ppc64.img $TOPDESTPATH/images/netboot/pmac.img + $ADDNOTE $TOPDESTPATH/images/netboot/ppc64.img + fi this will create 2 images. ppc64.img will have the rpa config setting in the header the other pmac.img will not. This should help to keep developers from inadvertantly trying a harmful image on their powermac systems.
That seems reasonable; would it be worth renaming ppc64.img to pseries.img?
>would it be worth renaming ppc64.img to pseries.img? sure that should make everything very clear
So it seems like the propose anaconda patch doesn't work because KERNELROOT isn't what people think it is. After talking with Peter Jones, he suggested I add to the spec file a dependency on ppc64-utils and stick the addnote binary into /usr/share/pp64-utils, where it seems like it should belong. Anyone have any comments on that? -Don
Don, anaconda-11.1.2.140-1 will use /usr/share/ppc64-utils/addnote as the path for addnote.
Created attachment 320060 [details] new path patch Updated the spec file to put the addnote binary in /usr/share/ppc64-utils and the other necessary magic to make rpmbuild happy.
in kernel-2.6.18-119.el5 You can download this test kernel from http://people.redhat.com/dzickus/el5
looks like the latest attempted fix has failed a tree using: * kernel-2.6.18-119.el5 * anaconda-11.1.2.142-1 did not succeed ...
can I get a copy of the ppc64.img or pseries.img that was used for the install attempt? if you reboot to the OF prompt (select 8 at ibm splash screen) and type the following commands what do you get? 'printenv real-base' 'printenv load-base' was this failure on a POWER 5 or POWER 6 system?
Here is the console log: E209 E20A E20F E200 E20B E20D E211 E201 E212 E202 E213 E214 E215 E216 E217 E218 E204 E201 E219 E21A E21C E21D E21E E21F E21B E210 E21B E203 E206 E20C E13A E134 E19D E138 E440 E441 E139 E442 E443 D010 D011 E13A E134 E19D E138 E440 E441 E139 E149 E14C E101 E102 E10A E10B E19E E150 E154 E154 E154 E442 E443 D012 D00E D00D E170 E172 U8842.P2C.23GDY2N-P1 E151 U8842.P2C.23GDY2N-P1 E152 U8842.P2C.23GDY2N-P1 E153 U8842.P2C.23GDY2N-P1 E152 U8842.P2C.23GDY2N-P1 E153 U8842.P2C.23GDY2N-P1 E172 U8842.P2C.23GDY2N-P1 EAA1 U8842.P2C.23GDY2N-P1 E152 U8842.P2C.23GDY2N-P1-T6 E153 U8842.P2C.23GDY2N-P1-T6 E152 U8842.P2C.23GDY2N-P1-T7 E153 U8842.P2C.23GDY2N-P1-T7 EAA1 U8842.P2C.23GDY2N-P1 E172 U8842.P2C.23GDY2N-P1 EAA1 U8842.P2C.23GDY2N-P1 E152 U8842.P2C.23GDY2N-P1 E153 U8842.P2C.23GDY2N-P1 E152 U8842.P2C.23GDY2N-P1 E153 U8842.P2C.23GDY2N-P1 EAA1 U8842.P2C.23GDY2N-P1 E172 U8842.P2C.23GDY2N-P1 EAA1 U8842.P2C.23GDY2N-P1-C5 D001 D003 D004 E139 E14A D008 E1F0 E1F1 D099 D5BB 5 4 3 2 1 E1AA E1AD 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 = 0 d 60 1e 89 75 BOOTP: gateway IP = 0.0.0.0 BOOTP: device /pci@8000000f8000000/pci@0/ethernet@1,1 BOOTP: loc-code U8842.P2C.23GDY2N-P1-T7 BOOTP R = 1 BOOTP S = 2 FILE: /ppc/C0A821E9/netboot Packet Count = 100 Packet Count = 200 Packet Count = 300 Packet Count = 400 Packet Count = 500 Packet Count = 600 Packet Count = 700 Packet Count = 800 Packet Count = 900 Packet Count = 1000 Packet Count = 1100 Packet Count = 1200 Packet Count = 1300 Packet Count = 1400 Packet Count = 1500 Packet Count = 1600 Packet Count = 1700 Packet Count = 1800 Packet Count = 1900 Packet Count = 2000 Packet Count = 2100 Packet Count = 2200 Packet Count = 2300 Packet Count = 2400 Packet Count = 2500 Packet Count = 2600 Packet Count = 2700 Packet Count = 2800 Packet Count = 2900 Packet Count = 3000 Packet Count = 3100 Packet Count = 3200 Packet Count = 3300 Packet Count = 3400 Packet Count = 3500 Packet Count = 3600 Packet Count = 3700 Packet Count = 3800 Packet Count = 3900 Packet Count = 4000 Packet Count = 4100 Packet Count = 4200 Packet Count = 4300 Packet Count = 4400 Packet Count = 4500 Packet Count = 4600 Packet Count = 4700 Packet Count = 4800 Packet Count = 4900 Packet Count = 5000 Packet Count = 5100 Packet Count = 5200 Packet Count = 5300 Packet Count = 5400 Packet Count = 5500 Packet Count = 5600 Packet Count = 5700 Packet Count = 5800 Packet Count = 5900 Packet Count = 6000 Packet Count = 6100 Packet Count = 6200 Packet Count = 6300 Packet Count = 6400 Packet Count = 6500 Packet Count = 6600 Packet Count = 6700 Packet Count = 6800 Packet Count = 6900 Packet Count = 7000 Packet Count = 7100 Packet Count = 7200 Packet Count = 7300 Packet Count = 7400 Packet Count = 7500 Packet Count = 7600 Packet Count = 7700 Packet Count = 7800 Packet Count = 7900 Packet Count = 8000 Packet Count = 8100 Packet Count = 8200 Packet Count = 8300 Packet Count = 8400 Packet Count = 8500 Packet Count = 8600 Packet Count = 8700 Packet Count = 8800 Packet Count = 8900 Packet Count = 9000 Packet Count = 9100 Packet Count = 9200 Packet Count = 9300 Packet Count = 9400 Packet Count = 9500 Packet Count = 9600 Packet Count = 9700 Packet Count = 9800 Packet Count = 9900 Packet Count = 10000 Packet Count = 10100 Packet Count = 10200 Packet Count = 10300 Packet Count = 10400 Packet Count = 10500 Packet Count = 10600 Packet Count = 10700 Packet Count = 10800 Packet Count = 10900 Packet Count = 11000 Packet Count = 11100 Packet Count = 11200 Packet Count = 11300 Packet Count = 11400 Packet Count = 11500 Packet Count = 11600 Packet Count = 11700 Packet Count = 11800 Packet Count = 11900 Packet Count = 12000 Packet Count = 12100 Packet Count = 12200 Packet Count = 12300 Packet Count = 12400 Packet Count = 12500 Packet Count = 12600 Packet Count = 12700 Packet Count = 12800 Packet Count = 12900 Packet Count = 13000 Packet Count = 13100 Packet Count = 13200 Packet Count = 13300 Packet Count = 13400 Packet Count = 13500 Packet Count = 13600 Packet Count = 13700 Packet Count = 13800 Packet Count = 13900 Packet Count = 14000 Packet Count = 14100 Packet Count = 14200 Packet Count = 14300 Packet Count = 14400 Packet Count = 14500 Packet Count = 14600 Packet Count = 14700 Packet Count = 14800 Packet Count = 14900 Packet Count = 15000 Packet Count = 15100 Packet Count = 15200 Packet Count = 15300 Packet Count = 15400 Packet Count = 15500 Packet Count = 15600 Packet Count = 15700 Packet Count = 15800 Packet Count = 15900 Packet Count = 16000 Packet Count = 16100 Packet Count = 16200 Packet Count = 16300 Packet Count = 16400 Packet Count = 16500 Packet Count = 16600 Packet Count = 16700 Packet Count = 16800 Packet Count = 16900 Packet Count = 17000 Packet Count = 17100 Packet Count = 17200 Packet Count = 17300 Packet Count = 17400 Packet Count = 17500 Packet Count = 17600 Packet Count = 17700 Packet Count = 17800 Packet Count = 17900 Packet Count = 18000 Packet Count = 18100 Packet Count = 18200 Packet Count = 18300 Packet Count = 18400 Packet Count = 18500 Packet Count = 18600 Packet Count = 18700 Packet Count = 18800 Packet Count = 18900 Packet Count = 19000 Packet Count = 19100 FINAL Packet Count = 19126 FINAL File Size = 9792024 bytes. load-base=0x4000 real-base=0xc00000 -\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/- Elapsed time since release of system processors: 0 mins 39 secs E105 Config file read, 1024 bytes Welcome Welcome to yaboot version 1.3.12 Enter "help" to get some basic usage information Default supplied on the command line: The above is from the log shows the system loading the netboot image and then falling back to the locally installed yaboot.
Created attachment 320556 [details] ppc64.img from RHEL5.3-Server-20081015.nightly test tree
This failed because anaconda could not find the addnote binary. So the image continues to fail as before and needs to be addressed internally. Building boot images for kernel kernel Building ppc64 initrd Wrote /tmp/makebootdisk.initrdimage.27495 (7320k compressed) /mnt/redhat/nightly/RHEL5.3-Server-20081015.nightly/work/ppc-global/ppc/ppc64 / CLEANING UP removed `/tmp/vmlinuz.gz.x30826' removed `/tmp/zImage.bits.X30830' Could not find addnote, skipping I need to talk with Peter J. about what happened.
Was addnote actually installed on the server by the kernel RPM you had installed where you specified in the spec file (/usr/share/ppc64-utils/addnote)? Do you need to add %dir directives in the specfile to indicate /usr/share/ppc64-utils/ should be included in the RPM?
So we have a script fix to point to the correct directory holding the addnote binary. Now the current problem is, the kernel is built in a 64-bit environment, creating a 64-bit addnote binary. The chrooted environment in which the netboot image is created only has 32-bit libraries, so addnote fails to link in its dynamic 64-bit libraries. Either we pass a -m32 when compiling the addnote binary or we stick the addnote.c file into the ppc64-utils rpm like it seems it should belong (rather than in the kernel).
at the bottom of the log in the preceding comment I see: FINAL File Size = 9792024 bytes. load-base=0x4000 real-base=0xc00000 the real-base value here isn't what we want to see. It should be 2000000. I'm wondering if addnote was run on the install image. If you do the following command od -c <install-image-name> | less do you see something like this: 0000000 177 E L F 001 002 001 \0 \0 \0 \0 \0 \0 \0 \0 \0 0000020 \0 002 \0 024 \0 \0 \0 001 \0 0 \0 \0 \0 \0 \0 4 0000040 \0 224 375 ( \0 \0 200 \0 \0 4 \0 \0 004 \0 ( 0000060 \0 \b \0 005 \0 \0 \0 001 \0 001 \0 \0 \0 0 \0 \0 0000100 \0 0 \0 \0 \0 223 373 R \0 224 274 200 \0 \0 \0 \a 0000120 \0 001 \0 \0 d t 345 Q \0 \0 \0 \0 \0 \0 \0 \0 0000140 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \a 0000160 \0 \0 \0 004 \0 \0 \0 004 \0 \0 \0 264 \0 \0 \0 \0 0000200 \0 \0 \0 \0 \0 \0 \0 , \0 \0 \0 \0 \0 \0 \0 \0 0000220 \0 \0 \0 \0 \0 \0 \0 004 \0 \0 \0 340 \0 \0 \0 \0 0000240 \0 \0 \0 \0 \0 \0 \0 L \0 \0 \0 \0 \0 \0 \0 \0 0000260 \0 \0 \0 \0 \0 \0 \0 \b \0 \0 \0 030 \0 \0 022 u 0000300 P o w e r P C \0 377 377 377 377 002 \0 \0 \0 0000320 377 377 377 377 377 377 377 377 377 377 377 377 \0 \0 @ \0 0000340 \0 \0 \0 026 \0 \0 \0 ( 022 u 231 231 I B M , 0000360 R P A - C l i e n t - C o n f i 0000400 g \0 \0 \0 \0 \0 \0 001 \0 \0 \0 200 \0 \0 \0 \0 notice the last 2 lines you can see "RPA-Client-Config. That indicates that addnote was run on the image and the RPA note section is filled out. I received a copy of the ppc64.img that failed the latest QA run -rw-r--r-- 1 mjwolf mjwolf 9792024 2008-10-16 09:28 ppc64.img when I use od to look at the header I see: 0000000 177 E L F 001 002 001 \0 \0 \0 \0 \0 \0 \0 \0 \0 0000020 \0 002 \0 024 \0 \0 \0 001 \0 0 \0 \0 \0 \0 \0 4 0000040 \0 225 ] h \0 \0 200 \0 \0 4 \0 \0 002 \0 ( 0000060 \0 \b \0 005 \0 \0 \0 001 \0 001 \0 \0 \0 0 \0 \0 0000100 \0 0 \0 \0 \0 224 [ 224 \0 225 034 200 \0 \0 \0 \a 0000120 \0 001 \0 \0 d t 345 Q \0 \0 \0 \0 \0 \0 \0 \0 0000140 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \a 0000160 \0 \0 \0 004 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0000200 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0200000 H \0 \0 005 | \b 002 246 = \0 0 9 ) \0 004 0200020 | \t \0 Q A 202 \0 < = \0 1 9 ) 253 324 0200040 = \0 \0 1 9 \b 255 200 } \t @ Q A 202 \0 $ 0200060 U \b 360 277 } \t 003 246 } J 024 201 \t \0 \0 0200100 } \b 002 024 221 \t \0 \0 9 ) \0 004 B \0 377 360 0200120 = \0 0 } J 024 = \0 \0 1 9 \b 226 270 0200140 } \0 B 024 | \0 H 254 | \0 O 254 9 ) \0 0200160 ( \t \0 \b A 200 377 360 | \0 004 254 L \0 001 , 0200200 | & \v x H \0 * 240 8 243 377 377 8 204 377 377 0200220 214 004 \0 001 , \0 \0 \0 234 005 \0 001 @ 202 377 364 0200240 N 200 \0 , 005 \0 \0 M 202 \0 | 251 003 246 0200260 8 303 377 377 8 204 377 377 214 004 \0 001 , \0 \0 \0 0200300 234 006 \0 001 @ 002 377 364 N 200 \0 8 243 377 377 what I'm not seeing in this is the RPA config. I dont have access to the scripts that build the install image can someone verify the mk-images.ppc is patched and runs addnote on the ppc64.img?
> od -c <install-image-name> | less Better still, try: readelf -n <install-image-name> That should list all the notes in the binary in a more readable form.
I have reverted the patch from comment #65 that was included in the -119.el5 build. The other patch included in the -118.el5 (the one that changed addnote.c) is _still_ included. As mentioned above the patch was reverted to move the changes to the ppc64-utils package. The next time the bugzilla goes to MODIFIED, the patch from c#65 and _only_ c#65 will have been reverted. This bugzilla will continue on to ON_QA because the patch from c#19 is still included in the kernel and valid for this bugzilla. Clear as mud, right? -Don
in kernel-2.6.18-120.el5 You can download this test kernel from http://people.redhat.com/dzickus/el5
There is still conflict between ppc64-utils' addnote and kernel's addnote. Any progress in this?
$ rpm -qlp /mnt/redhat/rel-eng/RHEL5.3-Server-20081020.1/5/ppc/os/Server/kernel-2.6.18-120.el5.ppc64.rpm | grep addnote $ rpm -qlp /mnt/redhat/rel-eng/RHEL5.3-Server-20081020.1/5/ppc/os/Server/ppc64-utils-0.11-10.el5.ppc.rpm | grep addnote /usr/share/ppc64-utils/addnote It looks like the addnote binary has been removed from the latest kernel package. Roman, which version of kernel and ppc64-utils were you testing with?
(In reply to comment #91) > $ rpm -qlp > /mnt/redhat/rel-eng/RHEL5.3-Server-20081020.1/5/ppc/os/Server/kernel-2.6.18-120.el5.ppc64.rpm > | grep addnote > $ rpm -qlp > /mnt/redhat/rel-eng/RHEL5.3-Server-20081020.1/5/ppc/os/Server/ppc64-utils-0.11-10.el5.ppc.rpm > | grep addnote > /usr/share/ppc64-utils/addnote > > It looks like the addnote binary has been removed from the latest kernel > package. Roman, which version of kernel and ppc64-utils were you testing with? Actually, I was the one who bugged Roman about the issue so I can answer that.. We were testing with kernel -119, -120 is not yet synced to our Brno mirror. Provided that addnote is no longer in -120 kernel, the issue should be OK. Thanks for checking, Dennis!
I hopped on a partition booted to OF and did a wipe-nvram to get the OF back to a base state. I was then able to successfully netboot the rhel5 u3 beta installer and install the system
worked on a power6 partition as well. marking this as closed
the beta loaded fine on a p5 and p6. Marking this as closed
Release note added. If any revisions are required, please set the "requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Cause: Netbooting on PPC is presently broken, likely because the size of the netboot image has grown beyond the ability of OpenFirmware to support. Consequence: Users will simply see the system die on netboot with the following messages: Please wait, loading kernel... /pci@8000000f8000000/ide@4,1/disk@0:2,vmlinux-anaconda: No such file or directory boot: Fix: If this happens, use the following work-around. This will need to be done each time the kernel is netbooted. First, boot to the OpenFirmware prompt, by pressing the '8' key early in boot, (when the IBM splash screen is displayed) Execute: "setenv real-base 2000000" Then proceed to boot into SMS with: "0> dev /packages/gui obe" Result: From there, you can select to do a network boot as usual.
For the release notes we might want to add the fact that using the 'addnote' binary on the kernel image permanently sets the address in the kernel image such that one does have to do this manually everytime on boot. This is how we can accomplish it for the ppc isos (we run the addnote binary during the creation of the tree).
Release note updated. If any revisions are required, please set the "requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1,21 +1,15 @@ -Cause: Netbooting on PPC is presently broken, likely because the size of the netboot -image has grown beyond the ability of OpenFirmware to support. -Consequence: Users will -simply see the system die on netboot with the following messages: +The size of the PPC kernel image is too large for OpenFirmware to support. Consequently, network booting will fail, resulting in the following error message: + Please wait, loading kernel... -/pci@8000000f8000000/ide@4,1/disk@0:2,vmlinux-anaconda: No such file or -directory +/pci@8000000f8000000/ide@4,1/disk@0:2,vmlinux-anaconda: No such file or directory boot: -Fix: If this happens, use the following work-around. This will need to be done each -time the kernel is netbooted. -First, boot to the OpenFirmware prompt, by pressing the '8' key early in boot, -(when the IBM splash screen is displayed) +To work around this: -Execute: -"setenv real-base 2000000" +1. Boot to the OpenFirmware prompt, by pressing the '8' key when the IBM splash screen is displayed. -Then proceed to boot into SMS with: -"0> dev /packages/gui obe" +2. Run the following command: +setenv real-base 2000000 -Result: From there, you can select to do a network boot as usual.+3. Boot into System Managment Services (SMS) with the command: +0> dev /packages/gui obe
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2009-0225.html