Bug 462663 - Netboot image for ppc too large
Netboot image for ppc too large
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
5.3
powerpc Linux
medium Severity medium
: beta
: ---
Assigned To: Brad Peters
Martin Jenner
http://rhts.redhat.com/cgi-bin/rhts/t...
: TestBlocker
Depends On:
Blocks: RHEL5u3_relnotes 467477
  Show dependency treegraph
 
Reported: 2008-09-17 20:25 EDT by Jeff Burke
Modified: 2009-06-20 01:30 EDT (History)
21 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
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 boot: To work around this: 1. Boot to the OpenFirmware prompt, by pressing the '8' key when the IBM splash screen is displayed. 2. Run the following command: setenv real-base 2000000 3. Boot into System Managment Services (SMS) with the command: 0> dev /packages/gui obe
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-20 15:09:10 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch to update RPA notes in addnote.c and prom_init.c (2.21 KB, text/plain)
2008-09-25 14:40 EDT, IBM Bug Proxy
no flags Details
rebased patch to the rhel5u2 kernel (2.08 KB, text/plain)
2008-09-26 22:00 EDT, IBM Bug Proxy
no flags Details
Patch to set set real-base (2.68 KB, text/plain)
2008-10-01 14:46 EDT, IBM Bug Proxy
no flags Details
Install addnote in the kernel RPMs (1.09 KB, patch)
2008-10-08 13:32 EDT, David Howells
no flags Details | Diff
Add note to bootable kernel image (829 bytes, patch)
2008-10-08 14:23 EDT, David Howells
no flags Details | Diff
new path patch (2.30 KB, patch)
2008-10-10 17:18 EDT, Don Zickus
no flags Details | Diff
ppc64.img from RHEL5.3-Server-20081015.nightly test tree (9.34 MB, application/octet-stream)
2008-10-16 10:06 EDT, Brock Organ
no flags Details

  None (edit)
Description Jeff Burke 2008-09-17 20:25:21 EDT
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
Comment 1 Joel Andres Granados 2008-09-18 10:14:35 EDT
Can you please run the test with the 20080918 that is the last compose.
Comment 3 Bill Peck 2008-09-18 11:02:11 EDT
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.
Comment 5 Jeff Burke 2008-09-18 13:14:07 EDT
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
Comment 6 Joel Andres Granados 2008-09-19 13:14:37 EDT
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.
Comment 7 Chris Lumens 2008-09-19 16:02:48 EDT
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.
Comment 8 Jeff Burke 2008-09-19 16:16:07 EDT
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.
Comment 9 Joel Andres Granados 2008-09-22 05:41:41 EDT
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.
Comment 12 Joel Andres Granados 2008-09-25 08:41:11 EDT
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?
Comment 14 IBM Bug Proxy 2008-09-25 10:40:45 EDT
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.
Comment 15 Bill Peck 2008-09-25 10:59:37 EDT
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.
Comment 16 Bill Peck 2008-09-25 11:10:29 EDT
I figured it out. 

So far this seems to have done the trick.
Comment 17 IBM Bug Proxy 2008-09-25 11:10:51 EDT
at e1f1 hit '8' key.  otherwise with the SMS screens come up it will say to
press 1 for SMS and 8 for OF
Comment 18 Bill Peck 2008-09-25 12:34:21 EDT
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?
Comment 19 IBM Bug Proxy 2008-09-25 14:40:53 EDT
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).
Comment 20 John Jarvis 2008-09-26 12:30:17 EDT
IBM, have you successfully tested this patch?
Comment 21 IBM Bug Proxy 2008-09-26 15:10:34 EDT
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
Comment 23 IBM Bug Proxy 2008-09-26 22:00:39 EDT
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 24 IBM Bug Proxy 2008-09-30 17:01:57 EDT
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
Comment 25 IBM Bug Proxy 2008-10-01 00:45:57 EDT
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.
Comment 26 IBM Bug Proxy 2008-10-01 10:37:58 EDT
Ameet Paranjape <ameet@austin.ibm.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
Comment 27 IBM Bug Proxy 2008-10-01 14:46:37 EDT
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.
Comment 28 IBM Bug Proxy 2008-10-01 21:01:26 EDT
Please consider this under the exception process
Comment 29 John Jarvis 2008-10-02 16:08:11 EDT
Requesting release note.  IBM, please propose release note text.
Comment 30 IBM Bug Proxy 2008-10-02 17:37:02 EDT
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.
Comment 31 IBM Bug Proxy 2008-10-02 18:37:23 EDT
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.
Comment 34 IBM Bug Proxy 2008-10-03 11:17:10 EDT
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.
Comment 35 IBM Bug Proxy 2008-10-03 12:03:33 EDT
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"
Comment 36 Don Zickus 2008-10-06 11:56:18 EDT
in kernel-2.6.18-118.el5
You can download this test kernel from http://people.redhat.com/dzickus/el5
Comment 38 IBM Bug Proxy 2008-10-06 15:01:07 EDT
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.
Comment 39 Bill Peck 2008-10-07 09:58:54 EDT
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
Comment 40 IBM Bug Proxy 2008-10-07 10:30:52 EDT
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.
Comment 41 Bill Peck 2008-10-07 10:37:11 EDT
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.
Comment 42 IBM Bug Proxy 2008-10-07 11:16:43 EDT
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?
Comment 43 Bill Peck 2008-10-07 11:23:20 EDT
We netboot the install image directly
Comment 44 IBM Bug Proxy 2008-10-07 11:33:19 EDT
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
Comment 45 IBM Bug Proxy 2008-10-07 12:16:22 EDT
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?
Comment 46 IBM Bug Proxy 2008-10-07 12:46:09 EDT
also tried the workaround with this install image and that didnt work either.  Go right to a message that says 'No Operating System installed'
Comment 47 Ameet Paranjape 2008-10-07 17:38:32 EDT
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.
Comment 48 Ameet Paranjape 2008-10-07 17:52:35 EDT
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.
Comment 49 David Howells 2008-10-08 06:32:29 EDT
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.
Comment 50 IBM Bug Proxy 2008-10-08 10:34:49 EDT
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.
Comment 51 David Howells 2008-10-08 13:32:01 EDT
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.
Comment 52 David Howells 2008-10-08 14:23:26 EDT
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.
Comment 53 Don Zickus 2008-10-08 15:17:33 EDT
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?
Comment 54 Peter Jones 2008-10-08 15:30:50 EDT
The patch in comment #52 should be applied in anaconda-11.1.2.138-1 .
Comment 55 IBM Bug Proxy 2008-10-08 15:33:53 EDT
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
Comment 56 David Howells 2008-10-08 20:44:18 EDT
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.
Comment 57 IBM Bug Proxy 2008-10-09 04:42:13 EDT
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.
Comment 58 IBM Bug Proxy 2008-10-09 13:51:40 EDT
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
Comment 59 IBM Bug Proxy 2008-10-09 16:01:21 EDT
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).
Comment 60 IBM Bug Proxy 2008-10-09 21:31:03 EDT
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.
Comment 61 David Howells 2008-10-10 08:44:12 EDT
That seems reasonable; would it be worth renaming ppc64.img to pseries.img?
Comment 62 IBM Bug Proxy 2008-10-10 10:51:39 EDT
>would it be worth renaming ppc64.img to pseries.img?

sure that should make everything very clear
Comment 63 Don Zickus 2008-10-10 14:15:00 EDT
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
Comment 64 Peter Jones 2008-10-10 17:09:55 EDT
Don, anaconda-11.1.2.140-1 will use /usr/share/ppc64-utils/addnote as the path for addnote.
Comment 65 Don Zickus 2008-10-10 17:18:22 EDT
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.
Comment 66 Don Zickus 2008-10-13 11:09:32 EDT
in kernel-2.6.18-119.el5
You can download this test kernel from http://people.redhat.com/dzickus/el5
Comment 70 Brock Organ 2008-10-15 18:14:30 EDT
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 ...
Comment 72 IBM Bug Proxy 2008-10-15 18:31:08 EDT
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?
Comment 73 Jeff Burke 2008-10-15 20:14:30 EDT
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.
Comment 74 Brock Organ 2008-10-16 10:06:50 EDT
Created attachment 320556 [details]
ppc64.img from RHEL5.3-Server-20081015.nightly test tree
Comment 75 Don Zickus 2008-10-16 10:40:42 EDT
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.
Comment 76 David Howells 2008-10-16 12:47:06 EDT
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?
Comment 78 Don Zickus 2008-10-16 16:04:07 EDT
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).
Comment 83 IBM Bug Proxy 2008-10-17 08:13:28 EDT
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?
Comment 84 David Howells 2008-10-17 08:21:57 EDT
> 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.
Comment 86 Don Zickus 2008-10-17 18:03:40 EDT
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
Comment 87 Don Zickus 2008-10-20 11:13:06 EDT
in kernel-2.6.18-120.el5
You can download this test kernel from http://people.redhat.com/dzickus/el5
Comment 90 Roman Rakus 2008-10-21 09:36:14 EDT
There is still conflict between ppc64-utils' addnote and kernel's addnote. Any progress in this?
Comment 91 Dennis Gregorovic 2008-10-21 09:56:01 EDT
$ 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?
Comment 92 Jakub Hrozek 2008-10-21 10:02:47 EDT
(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!
Comment 96 IBM Bug Proxy 2008-10-30 15:15:11 EDT
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
Comment 97 IBM Bug Proxy 2008-10-30 17:14:37 EDT
worked on a power6 partition as well.  marking this as closed
Comment 98 IBM Bug Proxy 2008-11-03 14:57:16 EST
the beta loaded fine on a p5 and p6.  Marking this as closed
Comment 101 Roman Rakus 2008-11-19 07:00:24 EST
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.
Comment 102 Don Zickus 2008-11-19 09:30:49 EST
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).
Comment 104 Ryan Lerch 2008-11-24 18:36:57 EST
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
Comment 106 errata-xmlrpc 2009-01-20 15:09:10 EST
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

Note You need to log in before you can comment on or make changes to this bug.