Bug 458438 - Network boot installs on Power 6 fail
Network boot installs on Power 6 fail
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: yaboot (Show other bugs)
11
ppc64 All
medium Severity medium
: ---
: ---
Assigned To: Tony Breeds
Fedora Extras Quality Assurance
:
Depends On:
Blocks: F11Target
  Show dependency treegraph
 
Reported: 2008-08-08 08:50 EDT by IBM Bug Proxy
Modified: 2013-01-09 23:46 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-12-18 07:49:42 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
contents of /proc/device-tree (16.97 KB, application/x-bzip)
2008-09-15 07:31 EDT, IBM Bug Proxy
no flags Details
Yaboot booting on P6 (OF version EM320_040 (9.43 KB, application/octet-stream)
2008-10-07 13:01 EDT, IBM Bug Proxy
no flags Details
DEBUG patch for helping yaboot along (9.76 KB, text/plain)
2009-01-12 16:02 EST, IBM Bug Proxy
no flags Details
DEBUG patch for helping yaboot along v2 (9.66 KB, text/plain)
2009-01-12 20:01 EST, IBM Bug Proxy
no flags Details
version 3 debug patch (10.91 KB, text/plain)
2009-01-15 16:02 EST, IBM Bug Proxy
no flags Details
version 4 debug patch (13.69 KB, text/plain)
2009-01-26 11:43 EST, IBM Bug Proxy
no flags Details
another debug patch. this one uses bootpath to get the gateway (13.72 KB, text/plain)
2009-01-27 12:43 EST, IBM Bug Proxy
no flags Details
version 6 debug patch. ignore gateway in bootreply_packet (13.75 KB, text/plain)
2009-01-27 14:21 EST, IBM Bug Proxy
no flags Details
New patched version of yaboot to test. (76.84 KB, application/octet-stream)
2009-03-04 23:21 EST, IBM Bug Proxy
no flags Details
Verify's the IP that we parse from Open Firmware (2.86 KB, patch)
2009-05-05 18:02 EDT, Arlinton Bourne
no flags Details | Diff
This hack works on pre and post GA3 OF. Tested on JS22, JS21 (pre + post), VIOS on Power5 (1.30 KB, patch)
2009-05-06 22:03 EDT, Arlinton Bourne
no flags Details | Diff

  None (edit)
Description IBM Bug Proxy 2008-08-08 08:50:17 EDT
Problem description:
=====================
During the network boot for installation of fedora 10-Alpha on Power6
machine failed to fetch yaboot.conf giving error message as shown below.

Network boot is having no problem on power5 system with same configuration of
network server setup.

Network server Files:
/tftpboot/yaboot
/tftpboot/etc/yaboot.conf
/tftpboot/ppc/ppc64/vmlinuz
/tftpboot/ppc/ppc64/ramdisk.image.gz

==============================

FILE        : yaboot
BLKSIZE     : 512 
TFTP-RETRIES: 5 
FINAL PACKET COUNT = 298 
FINAL FILE SIZE = 152524  BYTES

Elapsed time since release of system processors: 103913 mins 16 secs

/lhea@23c00200/ethernet@23e00100::-1,/etc/yaboot.conf: Unknown or corrupt filesystem
Can't open config file
Welcome to yaboot version 1.3.13 (Red Hat 1.3.13-12.fc9)
Enter "help" to get some basic usage information
boot: 
=============================== 

Hardware Environment
    Cpu type (Power4, Power5, IA-64, etc.):Power 6

=Comment: #1=================================================
Anoop V. Chakkalakkal <anoop.vijayan@in.ibm.com> - 2008-08-08 00:44 EDT
Pavan, do you need to do any additional configuration for yaboot to take
yaboot.conf over the network, like specifying the file in dhcp configuration? 

=Comment: #2=================================================
Pavan Naregundi <pavan.naregundi@in.ibm.com> - 2008-08-08 02:08 EDT
yaboot.conf is searched by yaboot in /tftpboot/etc/yaboot.conf path. yaboot will
be specified in dhcp configuration file.
Comment 1 Roman Rakus 2008-08-11 08:10:57 EDT
Just to be sure, file system where you want to read yaboot.conf is which? ext2?
Comment 2 IBM Bug Proxy 2008-09-11 10:10:30 EDT
(In reply to comment #8)
> ------- Comment From rrakus@redhat.com 2008-08-11 08:10:57 EDT-------
> Just to be sure, file system where you want to read yaboot.conf is which? ext2?

Its ext3 file system.
Comment 3 Paul Nasrat 2008-09-14 04:31:40 EDT
Can you try yaboot HEAD from ozlabs built with DEBUG=1.

The file system of the tftp server should have no effect on the network boot.

What is the OF version on the Power 6 box, can you give the OF path to the network device you are booting from (or better from a booted/installed system get a tarball of /proc/device-tree and upload it to this bug).

The double colon in the output below looks suspicious and is probably giving an invalid PROM HANDLE, which could be a bug in the parser for the device, or a firmware specific issue:

/lhea@23c00200/ethernet@23e00100::-1,/etc/yaboot.conf

static int
of_net_open(struct boot_file_t* file, const char* dev_name,
            struct partition_t* part, const char* file_name)
{
     static char        buffer[1024];
     char               *filename;
     char               *p;

     DEBUG_ENTER;
     DEBUG_OPEN;

     strncpy(buffer, dev_name, 768);
     if (file_name && strlen(file_name)) {
          strcat(buffer, ",");
          filename = strdup(file_name);
          for (p = filename; *p; p++)
               if (*p == '/')
                    *p = '\\';
          strcat(buffer, filename);
          free(filename);
     }

     DEBUG_F("Opening: \"%s\"\n", buffer);

     file->of_device = prom_open(buffer);

     DEBUG_F("file->of_device = %p\n", file->of_device);

     file->pos = 0;
     if ((file->of_device == PROM_INVALID_HANDLE) || (file->of_device == 0))
     {
          DEBUG_LEAVE(FILE_ERR_BAD_FSYS);
          return FILE_ERR_BAD_FSYS;
     }
Comment 4 IBM Bug Proxy 2008-09-15 07:30:55 EDT
(In reply to comment #10)
> ------- Comment From pauln@truemesh.com 2008-09-14 04:31:40 EDT-------
Below is output when I tried to boot with yaboot-1.3.14 built with DEBUG=1:
=====================================
FILE        : yaboot
BLKSIZE     : 512
TFTP-RETRIES: 5
FINAL PACKET COUNT = 366
FINAL FILE SIZE = 187122  BYTES

Elapsed time since release of system processors: 18805 mins 5 secs

Adding OF methods...
prom_init - OF interface initialized.
yaboot_start - Malloc buffer allocated at 00300000 (1048576 bytes)
yaboot_start - reloc_offset :  0         (should be 0)
yaboot_start - test_bss     :  0         (should be 0)
yaboot_start - test_data    :  0         (should be 0)
yaboot_start - &test_data   :  00229a4c
yaboot_start - &test_bss    :  00229a50
yaboot_start - linked at    :  0x00200000
yaboot_start - Running on _machine = 4
yaboot_main - /chosen/bootargs =
yaboot_main - /chosen/bootpath =
/lhea@23c00200/ethernet@23e00100:speed=auto,duplex=auto,9.124.111.85,,9.124.111.249,9.124.111.1,5,5,255.255.255.000,512
netdev_path_to_filename - path =
/lhea@23c00200/ethernet@23e00100:speed=auto,duplex=auto,9.124.111.85,,9.124.111.249,9.124.111.1,5,5,255.255.255.000,512
netdev_path_to_filename - null filename
netdev_path_to_dev - path =
/lhea@23c00200/ethernet@23e00100:speed=auto,duplex=auto,9.124.111.85,,9.124.111.249,9.124.111.1,5,5,255.255.255.000,512
yaboot_main - After parse_device_path:
dev=/lhea@23c00200/ethernet@23e00100:, part=-1, file=
yaboot_main - After path kludgeup: dev=/lhea@23c00200/ethernet@23e00100:,
part=-1, file=/etc/yaboot.conf
Try to netboot
prom_get_netinfo - using /chosen/bootp-response
open_file - dev_path = /lhea@23c00200/ethernet@23e00100:
file_name = /etc/01-00-1a-64-a9-0c-41
partition = -1
open_file - device is a network device
--> of_net_open
of_net_open - dev=/lhea@23c00200/ethernet@23e00100:, part=0x00000000 (-1),
file_name=/etc/01-00-1a-64-a9-0c-41
of_net_open - Opening:
"/lhea@23c00200/ethernet@23e00100:,\etc\01-00-1a-64-a9-0c-41"
of_net_open - file->of_device = 00000000
<-- of_net_open - FILE_ERR_BAD_FSYS
/lhea@23c00200/ethernet@23e00100::-1,/etc/01-00-1a-64-a9-0c-41: Unknown or
corrupt filesystem
Can't open config file
Welcome to yaboot version 1.3.14
Enter "help" to get some basic usage information
boot:
==================================

OF version is:
# lsmcode
Version of System Firmware is EM320_040 (t) EM320_031 (p) EM320_040 (t)
Comment 5 IBM Bug Proxy 2008-09-15 07:31:03 EDT
Created attachment 316724 [details]
contents of /proc/device-tree
Comment 6 Paul Nasrat 2008-09-15 08:50:28 EDT
We're getting a bad handle for the open call:

of_net_open - Opening:
"/lhea@23c00200/ethernet@23e00100:,\etc\01-00-1a-64-a9-0c-41"
of_net_open - file->of_device = 00000000


Compare with a working network boot on a (Power V lpar):

    of_net_open - dev=/vdevice/l-lan@30000002:, part=0x00000000 (-1), file_name=/etc/01-46-2a-b0-00-30-02
    of_net_open - Opening: "/vdevice/l-lan@30000002:,\etc\01-46-2a-b0-00-30-02"
    of_net_open - file->of_device = 018fef00 

When you get to the boot: prompt can you try to force a config load again:

device=network partition=-1 filename=/etc/yaboot.conf
Comment 7 IBM Bug Proxy 2008-09-16 01:20:31 EDT
(In reply to comment #13)
> ------- Comment From pauln@truemesh.com 2008-09-15 08:50:28 EDT-------
> When you get to the boot: prompt can you try to force a config load again:
>
> device=network partition=-1 filename=/etc/yaboot.conf
I got same error with command "conf [device=device] [partition=partno]
[file=/path/to/configfile]" on yaboot's boot prompt:

boot: conf device=network partition=-1 file=/etc/yaboot.conf
get_params - Loading user-specified config file: conf
get_params - conf device: network
get_params - conf partition: -1
get_params - conf file: /etc/yaboot.conf
Loading config file...
open_file - dev_path = network
file_name = /etc/yaboot.conf
partition = -1
open_file - device is a network device
--> of_net_open
of_net_open - dev=network, part=0x00000000 (-1), file_name=/etc/yaboot.conf
of_net_open - Opening: "network,\etc\yaboot.conf"
of_net_open - file->of_device = 00000000
<-- of_net_open - FILE_ERR_BAD_FSYS
network:-1,/etc/yaboot.conf: Unknown or corrupt filesystem
Can't open config file
Restoring default values.
boot:
Comment 8 Jesse Keating 2008-09-23 18:22:53 EDT
Moving off of Beta blockers.  ppc64 netboot is not something I'd hold the beta for.
Comment 9 IBM Bug Proxy 2008-09-30 07:31:24 EDT
I could reproduce this issue in F10 beta.
Comment 10 IBM Bug Proxy 2008-10-07 13:01:10 EDT
Created attachment 319669 [details]
Yaboot booting on P6 (OF version EM320_040

This bug was fixed mainline, please get the patch attached into [1]. We are assuming those Patches commented at [2] and [3] have been applied into git HEAD, because we're using some structures purposed by him.

The attached file shows a fixed version of Yaboot HEAD booting on Power 6 machine with the same firmware version reported previously (EM320_040).


Kind Regards,
Carlos.

[1] http://ozlabs.org/pipermail/yaboot-devel/2008-October/000234.html
[2] http://ozlabs.org/pipermail/yaboot-devel/2008-September/000224.html
[3] http://ozlabs.org/pipermail/yaboot-devel/2008-September/000227.html
Comment 11 David Woodhouse 2008-10-27 11:31:46 EDT
None of these patches appear to have been applied to git.

Paul?
Comment 12 Paul Nasrat 2008-10-29 02:48:39 EDT
I've been on holiday and busy with the day job. These patches are in my queue to review and commit for 1.3.15.

I'll try look at today.
Comment 13 IBM Bug Proxy 2008-11-18 06:30:57 EST
To RedHat

Have the above mentioned yaboot related patches been included in the F10 preview release ?
Comment 14 Josh Boyer 2008-11-18 14:09:46 EST
The patches are not included in F-10 at the moment as there has been no upstream activity on them.  I have done a build with the various patches included.  Please test the builds from here:

http://kojipkgs.fedoraproject.org/scratch/jwboyer/task_938260/

and report results.
Comment 15 Paul Nasrat 2008-11-18 14:37:20 EST
Josh thanks for building the test packages, if I can get some testing confirmation via the fedora ppc machines (I don't have POWER 6).
Comment 16 Jesse Keating 2008-11-18 14:58:47 EST
FWIW I tested this yaboot on a ppc mini and it continues to boot fine after running ybin.  So from a regression on other hardware POV this seems OK.
Comment 17 IBM Bug Proxy 2008-11-19 01:20:35 EST
I have tested this bug on power 6. It picks up the yaboot.conf but fails to
boot with vmlinuz and ramdisk as shown below

Here size of ramdisk.image.gz  differs from its actual size 18910328 Bytes.
Should I open a separate bug to track this issue?

0 > printenv real-base
-------------- Partition: common -------- Signature: 0x70 ---------------
real-base                2000000             2000000
ok

=====================
boot: linux64
Please wait, loading kernel...

TFTP BOOT ---------------------------------------------------
Server IP.....................9.124.111.85

Client IP.....................9.124.111.249

Subnet Mask...................255.255.255.0
( 1  ) Filename.................\ppc\ppc64\vmlinuz
TFTP Retries..................5
Block Size....................512

FILE        : /ppc/ppc64/vmlinuz
BLKSIZE     : 512
TFTP-RETRIES: 5
FINAL PACKET COUNT = 18903
FINAL FILE SIZE = 9677864  BYTES
Elf64 kernel loaded...
Loading ramdisk...

TFTP BOOT ---------------------------------------------------
Server IP.....................9.124.111.85

Client IP.....................9.124.111.249

Subnet Mask...................255.255.255.0
( 1  ) Filename.................\ppc\ppc64\ramdisk.image.gz
TFTP Retries..................5
Block Size....................512

FILE        : /ppc/ppc64/ramdisk.image.gz
BLKSIZE     : 512
TFTP-RETRIES: 5
FINAL FILE SIZE = 16777216  BYTES
ramdisk loaded at 04040000, size: 16383 Kbytes
OF stdout device is: /vdevice/vty@30000000
Hypertas detected, assuming LPAR !
command line: ro
memory layout at init:
alloc_bottom : 0000000005040000
alloc_top    : 0000000008000000
alloc_top_hi : 0000000008000000
rmo_top      : 0000000008000000
ram_top      : 0000000008000000
Looking for displays
instantiating rtas at 0x0000000007632000 ... done
boot cpu hw idx 0000000000000000
starting cpu hw idx 0000000000000002... done
copying OF device tree ...
Building dt strings...
Building dt structure...
Device tree strings 0x0000000005041000 -> 0x000000000504252e
Device tree struct  0x0000000005043000 -> 0x0000000005051000
Calling quiesce ...
returning from prom_init
Phyp-dump disabled at boot time
Using pSeries machine description
Using 1TB segments
Found initrd at 0xc000000004040000:0xc00000000503fe00
console [udbg0] enabled
Partition configured for 4 cpus.
CPU maps initialized for 2 threads per core
Starting Linux PPC64 #1 SMP Thu Oct 30 00:16:53 EDT 2008
-----------------------------------------------------
ppc64_pft_size                = 0x1a
physicalMemorySize            = 0x100000000
htab_hash_mask                = 0x7ffff
-----------------------------------------------------
Initializing cgroup subsys cpuset
Initializing cgroup subsys cpu
Linux version 2.6.27.4-68.fc10.ppc64 (mockbuild@ppc10.fedora.phx.redhat.com)
(gcc version 4.3.2 20081007 (Red Hat 4.3.2-6) (GCC) ) #1 SMP Thu Oct 30
00:16:53 EDT 2008
[boot]0012 Setup Arch
EEH: No capable adapters found
PPC64 nvram contains 15360 bytes
Zone PFN ranges:
DMA      0x00000000 -> 0x00100000
Normal   0x00100000 -> 0x00100000
Movable zone start PFN for each node
early_node_map[2] active PFN ranges
0: 0x00000000 -> 0x00084000
1: 0x00084000 -> 0x00100000
[boot]0015 Setup Done
Built 2 zonelists in Node order, mobility grouping on.  Total pages: 1034240
Policy zone: DMA
Kernel command line: ro
[boot]0020 XICS Init
[boot]0021 XICS Done
PID hash table entries: 4096 (order: 12, 32768 bytes)
clocksource: timebase mult[7d0000] shift[22] registered
Console: colour dummy device 80x25
console handover: boot [udbg0] -> real [hvc0]
Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
freeing bootmem node 0
freeing bootmem node 1
Memory: 4084644k/4194304k available (8212k kernel code, 109660k reserved, 960k
data, 1026k bss, 396k init)
SLUB: Genslabs=13, HWalign=128, Order=0-3, MinObjects=0, CPUs=4, Nodes=16
Calibrating delay loop... 1021.95 BogoMIPS (lpj=510976)
Security Framework initialized
SELinux:  Initializing.
Mount-cache hash table entries: 256
Initializing cgroup subsys ns
Initializing cgroup subsys cpuacct
Initializing cgroup subsys devices
Processor 1 found.
Processor 2 found.
Processor 3 found.
Brought up 4 CPUs
net_namespace: 1552 bytes
NET: Registered protocol family 16
IBM eBus Device Driver
PCI: Probing PCI hardware
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
NetLabel: Initializing
NetLabel:  domain hash size = 128
NetLabel:  protocols = UNLABELED CIPSOv4
NetLabel:  unlabeled traffic allowed by default
tracer: 1286 pages allocated for 65536 entries of 80 bytes
actual entries 65586
NET: Registered protocol family 2
IP route cache hash table entries: 131072 (order: 8, 1048576 bytes)
TCP established hash table entries: 262144 (order: 10, 4194304 bytes)
TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
TCP: Hash tables configured (established 262144 bind 65536)
TCP reno registered
NET: Registered protocol family 1
checking if image is initramfs...it isn't (invalid compressed format (err=1));
looks like an initrd
Freeing initrd memory: 16383k freed
IOMMU table initialized, virtual merging enabled
audit: initializing netlink socket (disabled)
type=2000 audit(1227083054.574:1): initialized
HugeTLB registered 16 MB page size, pre-allocated 0 pages
HugeTLB registered 16 GB page size, pre-allocated 0 pages
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
msgmni has been set to 8009
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252)
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
pciehp: PCI Express Hot Plug Controller Driver version: 0.4
Linux agpgart interface v0.103
Serial: 8250/16550 driver4 ports, IRQ sharing enabled
TX39/49 Serial driver version 1.11
brd: module loaded
loop: module loaded
input: Macintosh mouse button emulation as /devices/virtual/input/input0
Uniform Multi-Platform E-IDE driver
Driver 'sd' needs updating - please use bus_type methods
Driver 'sr' needs updating - please use bus_type methods
USB Universal Host Controller Interface driver v3.0
mice: PS/2 mouse device common for all mice
platform ppc-rtc.0: rtc core: registered ppc_md as rtc0
device-mapper: uevent: version 1.0.3
device-mapper: ioctl: 4.14.0-ioctl (2008-04-23) initialised:
dm-devel@redhat.com
usbcore: registered new interface driver hiddev
usbcore: registered new interface driver usbhid
usbhid: v2.6:USB HID core driver
nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
CONFIG_NF_CT_ACCT is deprecated and will be removed soon. Plase use
nf_conntrack.acct=1 kernel paramater, acct=1 nf_conntrack module option or
sysctl net.netfilter.nf_conntrack_acct=1 to enable it.
ip_tables: (C) 2000-2006 Netfilter Core Team
TCP cubic registered
Initializing XFRM netlink socket
NET: Registered protocol family 17
ieee80211: 802.11 data/management/control stack, git-1.1.13
ieee80211: Copyright (C) 2004-2005 Intel Corporation <jketreno@linux.intel.com>
registered taskstats version 1
md: Autodetecting RAID arrays.
md: Scanned 0 and added 0 devices.
md: autorun ...
md: ... autorun DONE.
RAMDISK: Compressed image found at block 0
RAMDISK: incomplete write (-28 != 32768) 16777216
RAMDISK: ran out of compressed data
invalid compressed format (err=1)
List of all partitions:
No filesystem could mount root, tried:  ext3 iso9660
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)
Rebooting in 180 seconds..
======================
Comment 18 IBM Bug Proxy 2008-11-19 01:30:42 EST
Forgot to mention I tried it on Fedora 10 Preview.
Comment 19 IBM Bug Proxy 2008-11-19 04:11:04 EST
(In reply to comment #25)
> Forgot to mention I tried it on Fedora 10 Preview.
>
Pavan did you test it using the build mentioned by the link in comment #21? Or you used the original F10 preview without any change?
Comment 20 IBM Bug Proxy 2008-11-19 05:01:03 EST
(In reply to comment #26)
> Pavan did you test it using the build mentioned by the link in comment #21? Or
> you used the original F10 preview without any change?
>
Tested through build mentioned by the link in comment #21.
Comment 21 Bill Nottingham 2008-11-20 13:01:46 EST
At this point, I don't think this will make final release - it will have to be fixed in an update.
Comment 22 Bug Zapper 2008-11-25 21:42:27 EST
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 23 James Laska 2008-12-05 07:53:23 EST
Perhaps rrakus can assist with comment#22 ?
Comment 24 James Laska 2008-12-05 07:54:39 EST
Please ignore comment#23 ... that was intended for another bug :(
Comment 25 IBM Bug Proxy 2009-01-08 22:40:50 EST
To avoid confusion summarising the bug once gain, I tested the yaboot build mentioned in comment #14(https://bugzilla.redhat.com/show_bug.cgi?id=458438) on Fedora 10 Preview it solved the problem(yaboot couldn't pick up yaboot.conf) for which bug was raised. However, while testing the build it produced a new problem while picking up the vmlinuz and ramdisk.image.gz as stated in comment #17(https://bugzilla.redhat.com/show_bug.cgi?id=458438).
Comment 26 IBM Bug Proxy 2009-01-12 16:02:57 EST
Created attachment 328787 [details]
DEBUG patch for helping yaboot along



This patch has been tested on a variety of ppc (32 and 64bit) machines and it is close to complete.  it is DEBUG only at the moment.  The output from yaboot is very verbose now :)  Please try it in the original environment.  If it fails post the boot log and I can investigate.
Comment 27 IBM Bug Proxy 2009-01-12 20:01:26 EST
Created attachment 328809 [details]
DEBUG patch for helping yaboot along v2



My last patch was a little too debug only as it would refuse to boot the loaded kernel.  This version boots the F-10 installer (http://download.fedora.redhat.com/pub/fedora/linux/releases/10/Fedora/ppc/os/ppc/ppc64/) on my machine.

It's clearly not ready for mainline.  Feedback welcome.
Comment 28 IBM Bug Proxy 2009-01-12 20:30:59 EST
For a quick test I've placed a compiled verion at:
http://ozlabs.au.ibm.com/~tony/yaboot/mainline/debug/yaboot
Comment 29 IBM Bug Proxy 2009-01-13 00:40:53 EST
Tested the patch in power 6 machine. It is reporting the old issue(yaboot could not pick the yaboot.conf) now. Pasting the log..

================================
0 > boot /lhea@23c00200/ethernet@23e00100:speed=auto,duplex=auto,9.124.111.85,yaboot.fedora,9.124.111.249,9.124.111.1,5,5,255.255.255.0,512

TFTP BOOT ---------------------------------------------------
Server IP.....................9.124.111.85

Client IP.....................9.124.111.249

Gateway IP....................9.124.111.1

Subnet Mask...................255.255.255.0
( 1  ) Filename.................yaboot.fedora
TFTP Retries..................5
Block Size....................512

FILE        : yaboot.fedora
BLKSIZE     : 512
TFTP-RETRIES: 5
FINAL PACKET COUNT = 373
FINAL FILE SIZE = 190482  BYTES

Elapsed time since release of system processors: 191246 mins 7 secs

Adding OF methods...
prom_init - OF interface initialized.
prom_claim - Attempting to claim 00300000 -> 00400000 align=0
yaboot_start - Malloc buffer allocated at 00300000 (1048576 bytes)
yaboot_start - reloc_offset :  0         (should be 0)
yaboot_start - test_bss     :  0         (should be 0)
yaboot_start - test_data    :  0         (should be 0)
yaboot_start - &test_data   :  0022a460
yaboot_start - &test_bss    :  0022a464
yaboot_start - linked at    :  0x00200000
yaboot_start - Running on _machine = 4
yaboot_main - /chosen/bootargs =
yaboot_main - /chosen/bootpath = /lhea@23c00200/ethernet@23e00100:speed=auto,duplex=auto,9.124.111.85,yaboot.fedora,9.124.111.249,9.124.111.1,5,5,255.255.255.0,512
netdev_path_to_filename - path = /lhea@23c00200/ethernet@23e00100:speed=auto,duplex=auto,9.124.111.85,yaboot.fedora,9.124.111.249,9.124.111.1,5,5,255.255.255.0,512
netdev_path_to_filename - filename = yaboot.fedora
netdev_path_to_dev - path = /lhea@23c00200/ethernet@23e00100:speed=auto,duplex=auto,9.124.111.85,yaboot.fedora,9.124.111.249,9.124.111.1,5,5,255.255.255.0,512
yaboot_main - After parse_device_path: dev=/lhea@23c00200/ethernet@23e00100:, part=-1, file=yaboot.fedora
yaboot_main - After path kludgeup: dev=/lhea@23c00200/ethernet@23e00100:, part=-1, file=/etc/yaboot.conf
Try to netboot
open_file - dev_path = /lhea@23c00200/ethernet@23e00100:
file_name = /etc/00-
partition = -1
open_file - device is a network device
--> of_net_open
of_net_open - dev=/lhea@23c00200/ethernet@23e00100:, part=0x00000000 (-1), file_name=/etc/00-
of_net_open - Opening: "/lhea@23c00200/ethernet@23e00100:,\etc\00-,,"
of_net_open - file->of_device = 00000000
<-- of_net_open - FILE_ERR_BAD_FSYS
/lhea@23c00200/ethernet@23e00100::-1,/etc/00-: Unknown or corrupt filesystem
Can't open config file
Welcome to yaboot version 1.3.14
Enter "help" to get some basic usage information
--> prom_dump_memory
: 0000000000004000 00000000001fc000  0000000000219e34 00000000000101cc
: 000000000023fabc 00000000000c0544  0000000000400000 0000000001c00000
: 0000000003420000 0000000004be0000  000000000000000<-- prom_dump_memory - ""
boot:
===========================
Comment 30 James Laska 2009-01-15 15:26:59 EST
Additional logs available from emails between Tony, Mike and myself. ...

> here is from the results from using your yaboot binary
> http://pastebin.com/m78cd519e

> here is using the old yaboot that scott hand built (included in cobbler)
> http://pastebin.com/m42e4a71b
Comment 31 IBM Bug Proxy 2009-01-15 16:02:18 EST
Created attachment 329141 [details]
version 3 debug patch



The problem in the attempt above is that the bootp-response packet is not properly read from openfirmware.  The version 2 patch works in my test environment so I added debug statements to the 
routine that reads and returns the packet.  Please apply the patch, retest and post the results.  I need
to see which part is failing.
Comment 32 James Laska 2009-01-15 17:05:41 EST
(In reply to comment #31)
> Created an attachment (id=329141) [details]
> version 3 debug patch
> 
> Please apply the patch, retest and
> post the results.  I need to see which part is failing.

Patch applied, yaboot built, addnote run:
http://pastebin.com/m54dae273

Test Results:
http://pastebin.com/m5bced56d
Comment 33 IBM Bug Proxy 2009-01-16 11:51:24 EST
Yes, I'm using an POWER6 L4 server.

The problem being reported is due to the response packet not being found by yaboot.
from prom.h
static const struct bootp_property_offset bootp_response_properties[] = {
{ .name = "bootp-response", .offset = 0 },
{ .name = "dhcp-response", .offset = 0 },
{ .name = "bootpreply-packet", .offset = 0x2a },
};

from prom.c
for (i = 0; i < ARRAY_SIZE(bootp_response_properties); i++) {
propname = bootp_response_properties[i].name;
size = prom_getproplen(chosen, propname);
if (size <= 0)
continue;

DEBUG_F("using /chosen/%s\n", propname);
offset = bootp_response_properties[i].offset;
break;
}

DEBUG_F("size=%d\n",size);
if (size <= 0) {
return NULL;
}

from the log above:
prom_get_netinfo - size=-1

so it is spinning through the loop and never finding bootp-response, dhcp-response, or bootreply-packet.

On my p6 when I do the netboot I get back to the yaboot prompt and then type 'bye' to get to
openfirmware.  From there I type  'dev /chosen'  then '.properties' and I get:
0 > .properties
name                    chosen
stdin                   01b74b00
stdout                  01be7580
memory                  01be6e00
nvram                   01be7400
mmu                     01be6c00
cpu                     01be6c00
bootpath                /vdevice/l-lan@30000002:bootp,9.5.252.216,,9.5.166.223
bootargs
ibm,client-architecture-support-reboot
00000000
bootp-response          02010600 3ffdcbe5 00000000 0905a6df 0905a6df 0905fcd8 00000000 3e24d6c3
38020000 00000000 00000000 6a617761 362e7263 686c616e 642e6962 6d2e636f
6d000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 2f796162 6f6f742e 63757272 656e742e 6d696b65
2e746f6e 79000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 63825363 0104ff00 00000d02 0177ff00 00000000
... 0000012cbytes total

So you can see I my p6 system there is something to read.

So please try the version 3 patch again.  When you get to the 'boot:' prompt run the following commands post the results

bye
dev /chosen
.properties
Comment 34 IBM Bug Proxy 2009-01-16 12:31:36 EST
the firmware level for my p6 is
[root@tundro3 ~]# lsmcode
Version of System Firmware is EM320_076 (t) EM320_076 (p) EM320_076 (t)

might be old FW isnt setting up /chosen correctly
Comment 35 James Laska 2009-01-16 13:37:35 EST
(In reply to comment #33)
> So please try the version 3 patch again.  When you get to the 'boot:' prompt
> run the following commands post the results
> 
> bye
> dev /chosen
> .properties

http://pastebin.com/m3db8378f

(In reply to comment #34)
> might be old FW isnt setting up /chosen correctly

The power5 systems I am testing on are at firmware level 358

hscroot@ibm-p5-hmc:~> lslic -m 505 -t sys -F mtms,activated_level,installed_level,curr_level_primary
9115-505*100E80A,358,358,358
Comment 36 IBM Bug Proxy 2009-01-19 08:00:40 EST
(In reply to comment #42)
>
> So please try the version 3 patch again.  When you get to the 'boot:' prompt
> run the following commands post the results
>
> bye
> dev /chosen
> .properties
>

boot: bye
Bye.
yaboot_start - Malloc buffer released. Exiting with code 0
EXIT called ok
0 > dev /chosen  ok
0 > .properties
name                    chosen
stdin                   02fc5100
stdout                  02fe7580
memory                  02fe6e00
nvram                   02fe7400
mmu                     02fe6c00
cpu                     02fe6c00
bootpath                /lhea@23c00200/ethernet@23e00100:speed=auto,duplex=auto,9.124.111.85,yaboot.fedora,9.124.111.249,9.124.111.1,5,5,255.255.255.000,512
bootargs
ibm,client-architecture-support-reboot
00000000

ok
0 >
==================

llm62:/proc/device-tree/openprom # lsprop ibm,fw-vernum_encoded
ibm,fw-vernum_encoded
"EM320_040"
Comment 37 James Laska 2009-01-19 09:45:25 EST
Same as my previous comment, just updated with fw-vernum_encoded value.

> bye
> dev /chosen
> .properties

http://pastebin.com/m3db8378f

(In reply to comment #34)
> might be old FW isnt setting up /chosen correctly

The power5 systems I am testing on are at firmware level 358

# cat /proc/device-tree/openprom/ibm,fw-vernum_encoded
SF240_358
Comment 38 IBM Bug Proxy 2009-01-26 11:43:22 EST
Created attachment 330001 [details]
version 4 debug patch



Attaching adding debug patch.  Please give this a try and post results.  The difference in this one is to get the gateway from the boot-device openfirmware variable
Comment 39 James Laska 2009-01-27 11:09:25 EST
> Attaching adding debug patch.  Please give this a try and post results.  The
> difference in this one is to get the gateway from the boot-device openfirmware
> variable

I think we're getting the gateway IP wrong.

http://pastebin.com/f441d93b1
Comment 40 Paul Nasrat 2009-01-27 11:34:02 EST
Yeah this line shows that:

#
    of_net_open - Opening: "/pci@800000020000002/pci@2/ethernet@1:192.168.33.125,\etc\01-00-11-25-7e-28-64,192.168.33.2,192.168.32.2"
Comment 41 IBM Bug Proxy 2009-01-27 12:43:52 EST
Created attachment 330128 [details]
another debug patch.  this one uses bootpath to get the gateway



Another debug patch.  This one attempts to get the gateway info from /chosen/bootpath
Comment 42 IBM Bug Proxy 2009-01-27 14:21:49 EST
Created attachment 330139 [details]
version 6 debug patch.  ignore gateway in bootreply_packet



In this version, ignore the gateway in the bootreply-packet and use the gateway in the bootpath
Comment 43 James Laska 2009-01-27 14:38:21 EST
(In reply to comment #42)
> In this version, ignore the gateway in the bootreply-packet and use the gateway
> in the bootpath

Output using latest patch - http://pastebin.com/m6dbe4e17

For comparison, output using yaboot included in cobbler - http://pastebin.com/m6acf6c40
Comment 44 IBM Bug Proxy 2009-02-11 06:01:46 EST
This issue is still present in Fedora 11 Alpha.
Comment 45 IBM Bug Proxy 2009-03-04 01:31:25 EST
Now issue is seen in power5 machines also, hence raising the severity.
Comment 46 IBM Bug Proxy 2009-03-04 23:21:34 EST
Created attachment 334090 [details]
New patched version of yaboot to test.


------- Comment (attachment) From tbreeds@au1.ibm.com 2009-03-04 23:18 EDT-------


This tarball contains:
   * bz-47086/diff_from_yaboot-1.3.14.patch
   * bz-47086/diff_from_master.patch
   * bz-47086/yaboot.debug

The two patches are there for reference.  Anyone that has seen this problem please test the "yaboot.debug", and report successes or failures here.

This version works on the power5 and 32-bit systems I've tested it on.  It's based on Chandra's changes for IPv6 support but doesn't actually add IPv6 support.
Comment 47 IBM Bug Proxy 2009-03-05 02:22:01 EST
(In reply to comment #57)
> The two patches are there for reference.  Anyone that has seen this problem
> please test the "yaboot.debug", and report successes or failures here.

Worked fine in power5 and power6 blade(JS22 and JS12).
Comment 48 James Laska 2009-04-27 08:51:16 EDT
Test results for the yaboot image provided in comment#46 on a power5 system:

 Machine type-model: 9115-505
 Serial number: 100E80A
 Firmware: SF240_358

DISTRO    VMLINUZ RAMDISK RESULT
========================================================================
Rawhide   15M     21M     FAIL (see http://cobbler.pastebin.com/f1a1ac13d)
F-11-Beta 17M     21M     FAIL (see http://cobbler.pastebin.com/f6088df3a)  [1]
F-10      8.9M    19M     PASS (see http://cobbler.pastebin.com/f1e7f0b)
RHEL5-U3  6.5M    7.3M    PASS (see http://cobbler.pastebin.com/f5ae58816)
RHEL4-U7  5.1M    5.1M    PASS (see http://cobbler.pastebin.com/f743c28)
RHEL3-U9  3.6M    6.2M    PASS (see http://cobbler.pastebin.com/f88e961a)


[1] F-11-Beta failure looks similar to recent problems where the yaboot binary doesn't have the relocatable kernel patch?  The error there is ... "/images/F-11-Beta-ppc64/vmlinuz: Not a valid ELF image"
Comment 49 James Laska 2009-04-27 13:00:55 EDT
Update to my previous comment (redhat comment#48).  F-11-Beta fails the same as rawhide (I suspect due to image sizes).  There is not a problem with relocatable kernels.
Comment 50 Tony Breeds 2009-04-27 19:47:28 EDT
(In reply to comment #49)
> Update to my previous comment (redhat comment#48).  F-11-Beta fails the same as
> rawhide (I suspect due to image sizes).  There is not a problem with
> relocatable kernels.  

Hi James, 
   Can you please re-run these tests with the yaboot from rawhide?
---
[tony@ago ~]$ rpm -q yaboot
yaboot-1.3.14-12.fc11.ppc
---
When today's mirror is complete
http://download.fedora.redhat.com/pub/fedora/linux/development/ppc/os/ppc/chrp/yaboot
Comment 51 IBM Bug Proxy 2009-04-28 01:11:46 EDT
------- Comment From pavan.naregundi@in.ibm.com 2009-04-28 01:03 EDT-------
(In reply to comment #59)
========================================================================
> Rawhide   15M     21M     FAIL (see http://cobbler.pastebin.com/f1a1ac13d)
> F-11-Beta 17M     21M     FAIL (see http://cobbler.pastebin.com/f6088df3a)  [1]

James, fails may be because of real-base size being only 0xc00000. So please set the real-base with following command in OF and retry,

> setenv real-base 3000000

Thanks
Pavan
Comment 52 Tony Breeds 2009-04-28 01:26:45 EDT
(In reply to comment #51)
> ------- Comment From pavan.naregundi@in.ibm.com 2009-04-28 01:03 EDT-------
>
> James, fails may be because of real-base size being only 0xc00000. So please
> set the real-base with following command in OF and retry,

No those boot failed because the initramfs is 21Mb and yaboot only allocated a 20Mb buffer to load into.  The yaboot in rawhide allocates a 25Mb buffer, which should be enough for F-11.  A longer term solution is being worked on.
 
> > setenv real-base 3000000

Changing real-base is only required if booting the ppc64.img (combined initramfs and kernel).  When (net)booting yaboot real-base of 0xc00000 is the preferred setting.
Comment 53 James Laska 2009-04-28 09:58:21 EDT
(In reply to comment #52)
> (In reply to comment #51)
> > ------- Comment From pavan.naregundi@in.ibm.com 2009-04-28 01:03 EDT-------
> >
> > James, fails may be because of real-base size being only 0xc00000. So please
> > set the real-base with following command in OF and retry,
> 
> No those boot failed because the initramfs is 21Mb and yaboot only allocated a
> 20Mb buffer to load into.  The yaboot in rawhide allocates a 25Mb buffer, which
> should be enough for F-11.  A longer term solution is being worked on.

Great!  Retesting with the yaboot-1.3.14-12.fc11 from Rawhide shows:

 Machine type-model: 9115-505
 Serial number: 100E80A
 Firmware: SF240_358

DISTRO    VMLINUZ RAMDISK RESULT
========================================================================
Rawhide   15M     21M     PASS (see http://cobbler.pastebin.com/f5e3bddb3)
F-11-Beta 17M     21M     PASS (see http://cobbler.pastebin.com/f2166e8f2)
F-10      8.9M    19M     PASS (see http://cobbler.pastebin.com/f6f76fd2)
RHEL5-U3  6.5M    7.3M    PASS (see http://cobbler.pastebin.com/f51fbc96e)
RHEL4-U7  5.1M    5.1M    PASS (see http://cobbler.pastebin.com/f78c18d3d)
RHEL3-U9  3.6M    6.2M    PASS (see http://cobbler.pastebin.com/f7d94328c)
Comment 54 IBM Bug Proxy 2009-04-28 11:31:31 EDT
------- Comment From mjwolf@us.ibm.com 2009-04-28 11:20 EDT-------
According to James' last comment it looks like yaboot is now working.  The changes are upstream and in Fedora.  Does anyone object to closing the bug as fixed?
Comment 55 James Laska 2009-04-28 12:00:21 EDT
(In reply to comment #54)
> ------- Comment From mjwolf@us.ibm.com 2009-04-28 11:20 EDT-------
> According to James' last comment it looks like yaboot is now working.  The
> changes are upstream and in Fedora.  Does anyone object to closing the bug as
> fixed?  

I haven't tested on a power6 yet.  I'll be happy to do so, but if someone has a power6 already primed and ready for testing, it would be a big help.
Comment 56 Arlinton Bourne 2009-05-04 12:19:00 EDT
Using the latest yaboot on a Power6 machine in our labs. Yaboot is still unable to determine the proper gateway address. So I'd like to bring attention to the following bootp-response and to specifically magnify the vendor specific information.

bootp-response          02010600 000314de 00000000 00000000 0a102c30 0a10400f 00000000 001a6444 
                        1c470000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
                        00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
                        00000000 00000000 00000000 7070632f 30413130 32433330 2f796162 6f6f7400 
                        00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
                        00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
                        00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
                        00000000 00000000 00000000 63825363 0104ffff f8000304 0a102ffe 06080a10 
                        ... 0000012cbytes total


Vendor specific section:
63825363 0104ffff f8000304 0a102ffe 06080a10

According to:
http://rfc.sunsite.dk/rfc/rfc1084.html

We can parse the vendor specific information of the bootp-response. In this case we have 0104ffff f800: Which is tag 01 (representing a netmask) and a length of 04 bytes and the information.

0304 0a102ffe: Tag 03 and a length 04 bytes tells us the gateway.
Comment 57 Tony Breeds 2009-05-04 20:48:57 EDT
(In reply to comment #56)
> Using the latest yaboot on a Power6 machine in our labs. 

I assume you mean "the latest in fedora", not the latest upstream right?

> We can parse the vendor specific information of the bootp-response. In this
> case we have 0104ffff f800: Which is tag 01 (representing a netmask) and a
> length of 04 bytes and the information.

Sure, we can do that.
Comment 58 IBM Bug Proxy 2009-05-05 01:21:35 EDT
------- Comment From pavan.naregundi@in.ibm.com 2009-05-05 01:16 EDT-------
(In reply to comment #66)
> I haven't tested on a power6 yet.  I'll be happy to do so, but if someone has a
> power6 already primed and ready for testing, it would be a big help.
>

Tested this on JS12 and JS22 with preview. Still problem seems still persist on P6.

Boot from Preview DVD failed as shown below
http://cobbler.pastebin.com/f24036a79

Thanks
Pavan
Comment 59 Tony Breeds 2009-05-05 02:27:23 EDT
(In reply to comment #58)
> ------- Comment From pavan.naregundi@in.ibm.com 2009-05-05 01:16 EDT-------
> (In reply to comment #66)
> > I haven't tested on a power6 yet.  I'll be happy to do so, but if someone has a
> > power6 already primed and ready for testing, it would be a big help.
> >
> 
> Tested this on JS12 and JS22 with preview. Still problem seems still persist on
> P6.
> 
> Boot from Preview DVD failed as shown below
> http://cobbler.pastebin.com/f24036a79

Can you update that URL to contain the  output from the tftp loads of yaboot, yaboot.conf, kernel and initrd?  I can not reproduce here on my JS22
Comment 60 Josh Boyer 2009-05-05 07:37:26 EDT
(In reply to comment #58)
> ------- Comment From pavan.naregundi@in.ibm.com 2009-05-05 01:16 EDT-------
> (In reply to comment #66)
> > I haven't tested on a power6 yet.  I'll be happy to do so, but if someone has a
> > power6 already primed and ready for testing, it would be a big help.
> >
> 
> Tested this on JS12 and JS22 with preview. Still problem seems still persist on
> P6.
> 
> Boot from Preview DVD failed as shown below
> http://cobbler.pastebin.com/f24036a79

How were you using the Preview DVD?  The iso was over DVD size, so you shouldn't be able to even burn it successfully.

Also, just so everyone is aware, Preview shipped with a bug in anaconda that will
install a ppc32 kernel on a ppc64 machine.  That obviously won't work when you reboot.
Comment 61 IBM Bug Proxy 2009-05-05 08:41:31 EDT
------- Comment From pavan.naregundi@in.ibm.com 2009-05-05 08:32 EDT-------
(In reply to comment #71)
> How were you using the Preview DVD?  The iso was over DVD size, so you
> shouldn't be able to even burn it successfully.
>

Here is a option to create virtual cd drive on power machines with VIOS. I did not burn any dvd.

Thanks
Pavan
Comment 62 Arlinton Bourne 2009-05-05 08:50:15 EDT
(In reply to comment #57)
> (In reply to comment #56)
> > Using the latest yaboot on a Power6 machine in our labs. 
> 
> I assume you mean "the latest in fedora", not the latest upstream right?
Of course.

> 
> > We can parse the vendor specific information of the bootp-response. In this
> > case we have 0104ffff f800: Which is tag 01 (representing a netmask) and a
> > length of 04 bytes and the information.
> 
> Sure, we can do that.
Comment 63 Arlinton Bourne 2009-05-05 18:02:57 EDT
Created attachment 342548 [details]
Verify's the IP that we parse from Open Firmware

Also I've encountered another issue (at least on my power machine). After writing a hack to get the IP from the Vendor section of the packet and that working great when issuing a:
boot network
 - or -
boot network1

..to open firmware. When trying to boot the machine automatically (on power-on or system-reset), the net boot would initially succeed in pulling in the yaboot binary and then proceed in trying to pull in yaboot again. This is all when configuring the network via SMS. After looking at what happens:

Adding OF methods...
    prom_init - OF interface initialized.
    yaboot_start - Malloc buffer allocated at 00300000 (1048576 bytes)
    yaboot_start - reloc_offset :  0         (should be 0)
    yaboot_start - test_bss     :  0         (should be 0)
    yaboot_start - test_data    :  0         (should be 0)
    yaboot_start - &test_data   :  00220460
    yaboot_start - &test_bss    :  00220464
    yaboot_start - linked at    :  0x00200000
    yaboot_start - Running on _machine = 4
    yaboot_main - /chosen/bootargs =
    yaboot_main - /chosen/bootpath = /lhea@23c00100/ethernet@23e00100:speed=auto,duplex=auto,0.0.
0.0,,0.0.0.0,0.0.0.0,5,5,0.0.0.0,512
    parse_device_path - imagepath = /lhea@23c00100/ethernet@23e00100:speed=auto,duplex=auto,0.0.0
.0,,0.0.0.0,0.0.0.0,5,5,0.0.0.0,512; defdevice <NULL>; defpart -1, deffile
    extract_netboot_args - imagepath = /lhea@23c00100/ethernet@23e00100:speed=auto,duplex=auto,0.
0.0.0,,0.0.0.0,0.0.0.0,5,5,0.0.0.0,512
    prom_get_netinfo - using /chosen/bootp-response
    extract_netinfo_args - We have a boot packet
    extract_netinfo_args -  siaddr = <a10400f>
    extract_netinfo_args -  ciaddr = <0>
    extract_netinfo_args -  yiaddr = <a102c30>
    extract_netinfo_args -  giaddr = <0>
    extract_netboot_args - siaddr = <0.0.0.0>
    extract_netboot_args - file = <>
    extract_netboot_args - ciaddr = <0.0.0.0>
    extract_netboot_args - giaddr = <0.0.0.0>
    extract_netboot_args - bootp_retries = <5>
    extract_netboot_args - tftp_retries = <5>
    extract_netboot_args - addl_params = <0.0.0.0,512>
    netdev_path_to_dev - path = /lhea@23c00100/ethernet@23e00100:speed=auto,duplex=auto,0.0.0.0,,
0.0.0.0,0.0.0.0,5,5,0.0.0.0,512
    yaboot_main - After parse_device_path: dev=/lhea@23c00100/ethernet@23e00100:, part=-1, file=
    yaboot_main - After path kludgeup: dev=/lhea@23c00100/ethernet@23e00100:, part=-1, file=/etc/
yaboot.conf
Try to netboot
    prom_get_netinfo - using /chosen/bootp-response
    open_file - dev_path = /lhea@23c00100/ethernet@23e00100:
file_name = /etc/01-00-1a-64-44-1c-47
partition = -1
    open_file - device is a network device
--> of_net_open
    of_net_open - dev=/lhea@23c00100/ethernet@23e00100:, part=0x00000000 (-1), file_name=/etc/01-
00-1a-64-44-1c-47
    of_net_open - Entire buffer: /lhea@23c00100/ethernet@23e00100: ;
 siaddr <0.0.0.0>; filename <\etc\01-00-1a-64-44-1c-47>; ciaddr <0.0.0.0>; giaddr <0.0.0.0>;
    of_net_open - Opening: "/lhea@23c00100/ethernet@23e00100:0.0.0.0,\etc\01-00-1a-64-44-1c-47,0.
0.0.0,0.0.0.0,5,5,0.0.0.0,512"

    of_net_open - file->of_device = 02f60700
    prom_claim_chunk - claimed 25165824 at 0x3440000 (0x1000000)
    of_net_open - TFP...

TFTP BOOT ---------------------------------------------------
Server IP.....................10.16.64.15

Client IP.....................10.16.44.48

Gateway IP....................10.16.47.254

Subnet Mask...................255.255.248.0
( 1  ) Filename.................ppc/0A102C30/yaboot
TFTP Retries..................5 
Block Size....................512 


FILE        : ppc/0A102C30/yaboot
BLKSIZE     : 512 
TFTP-RETRIES: 5 
FINAL PACKET COUNT = 684 
FINAL FILE SIZE = 349743  BYTES
    of_net_open - result: 349743
<-- of_net_open - FILE_ERR_OK
Config file read, 32768 bytes
--> of_close
    of_close - <@02f60700>
    of_close - of_close called
<-- of_close - 0
Resetting image table
ItemA device = <NULL>

... there's more but it's a failure
-------

This is my boot-device variable contents:
boot-device              /lhea@23c00100/ethernet@23e00100:speed=auto,duplex=auto,0.0.0.0,,0.0.0.0
,0.0.0.0,5,5,0.0.0.0,512 /pci@800000020000200/pci1014,02BD@1/sas/disk@30000

I wrote a patch to check if the IP coming from OF is legitimate and if it isn't use the IP information provided by the BOOTP packet. In this case 0.0.0.0 basically means use DHCP/BOOTP and is regarded an invalid IP configuration (in regards to the patch).
Comment 64 Tony Breeds 2009-05-06 00:13:44 EDT
Please try the yaboot (or yaboot.debug) from:
http://kojipkgs.fedoraproject.org/scratch/tbreeds/task_1338033/yaboot-1.3.14-13.fc11.ppc.rpm

I've added code to parse the vendor options (and store the gateway), and to only save the IP's from boot-path if they seem to be "real" IPs.

This version shouldn't break any setups that currently work :)
Comment 65 Tony Breeds 2009-05-06 00:15:06 EDT
(In reply to comment #61)

> Here is a option to create virtual cd drive on power machines with VIOS. I did
> not burn any dvd.

So you're netbooting the yaboot from the DVD right?
Comment 66 IBM Bug Proxy 2009-05-06 01:11:32 EDT
------- Comment From pavan.naregundi@in.ibm.com 2009-05-06 01:04 EDT-------
(In reply to comment #75)
>
> > Here is a option to create virtual cd drive on power machines with VIOS. I did
> > not burn any dvd.
>
> So you're netbooting the yaboot from the DVD right?
>

No, it is not netbooting . It is a equivalent to directly booting from DVD drive.

Thanks
Pavan
Comment 67 Tony Breeds 2009-05-06 01:48:52 EDT
(In reply to comment #66)

> No, it is not netbooting . It is a equivalent to directly booting from DVD
> drive.

Okay.  For the sake of my sanity please open a new bug to track your problem as it's /probably/ not netboot releated.  Please mark it as blocking "F11Target"

Please also:
1. Provide details on how to mount the DVD iso on the VIOS, I've not done that before.
2. Replace the yaboot in the DVD iso with the yaboot.debug from: http://kojipkgs.fedoraproject.org/scratch/tbreeds/task_1338033/yaboot-1.3.14-13.fc11.ppc.rpm
3. Try the kernel and initrd from: http://download.fedora.redhat.com/pub/fedora/linux/development/ppc/os/ppc/ppc64/
Comment 68 Arlinton Bourne 2009-05-06 06:35:18 EDT
(In reply to comment #64)
> Please try the yaboot (or yaboot.debug) from:
> http://kojipkgs.fedoraproject.org/scratch/tbreeds/task_1338033/yaboot-1.3.14-13.fc11.ppc.rpm
> 
> I've added code to parse the vendor options (and store the gateway), and to
> only save the IP's from boot-path if they seem to be "real" IPs.
> 
> This version shouldn't break any setups that currently work :)  

It's working great on the JS22 I have! I'll test it on other types of power machines later.
Comment 69 IBM Bug Proxy 2009-05-06 07:01:36 EDT
------- Comment From pavan.naregundi@in.ibm.com 2009-05-06 06:59 EDT-------
(In reply to comment #77)
> (In reply to comment #66)
>
> > No, it is not netbooting . It is a equivalent to directly booting from DVD
> > drive.
>
> Okay.  For the sake of my sanity please open a new bug to track your problem as
> it's /probably/ not netboot releated.  Please mark it as blocking "F11Target"

OK.

> Please also:
> 1. Provide details on how to mount the DVD iso on the VIOS, I've not done that
> before.

http://www.ibm.com/developerworks/wikis/display/WikiPtype/VIOLoadISO

> 2. Replace the yaboot in the DVD iso with the yaboot.debug from:
> http://kojipkgs.fedoraproject.org/scratch/tbreeds/task_1338033/yaboot-1.3.14-13.fc11.ppc.rpm
> 3. Try the kernel and initrd from:
> http://download.fedora.redhat.com/pub/fedora/linux/development/ppc/os/ppc/ppc64/
>
You mean to recreate a bootable iso replacing yaboot, kernel and initrd. Can you please mention the steps to create a bootable iso from '-o loop' mounted dvd image?

Thanks
Pavan
Comment 70 Arlinton Bourne 2009-05-06 09:12:59 EDT
(In reply to comment #68)
> (In reply to comment #64)
> > Please try the yaboot (or yaboot.debug) from:
> > http://kojipkgs.fedoraproject.org/scratch/tbreeds/task_1338033/yaboot-1.3.14-13.fc11.ppc.rpm
> > 
> > I've added code to parse the vendor options (and store the gateway), and to
> > only save the IP's from boot-path if they seem to be "real" IPs.
> > 
> > This version shouldn't break any setups that currently work :)  
> 
> It's working great on the JS22 I have! I'll test it on other types of power
> machines later.  

Apparently we run into this issue when we have yaboot feed a sane bootline to something that's 'older':
 
http://ozlabs.org/pipermail/yaboot-devel/2007-October/000179.html

This occurs on:
model                   IBM,SF240_338
Comment 71 Arlinton Bourne 2009-05-06 18:08:48 EDT
(In reply to comment #70)
> (In reply to comment #68)
> > (In reply to comment #64)
> > > Please try the yaboot (or yaboot.debug) from:
> > > http://kojipkgs.fedoraproject.org/scratch/tbreeds/task_1338033/yaboot-1.3.14-13.fc11.ppc.rpm
> > > 
> > > I've added code to parse the vendor options (and store the gateway), and to
> > > only save the IP's from boot-path if they seem to be "real" IPs.
> > > 
> > > This version shouldn't break any setups that currently work :)  
> > 
> > It's working great on the JS22 I have! I'll test it on other types of power
> > machines later.  
> 
> Apparently we run into this issue when we have yaboot feed a sane bootline to
> something that's 'older':
> 
> http://ozlabs.org/pipermail/yaboot-devel/2007-October/000179.html
> 
> This occurs on:
> model                   IBM,SF240_338  

The server IP on the older open firmware boxes refer to the BOOTP server and not the TFTP server. The BOOTP server in turn gives the next-server argument to OF and it fetches the file. After configuring an older machine to do the static network configuration it seems to be working.

The behaviour on the Power 6 or newer Open Firmware machines is, the server IP is the TFTP server. Alas on these newer firmware versions, we cannot use the BOOTP server as the server IP.

This is a case where the BOOTP/DHCP server is different from the TFTP server. Also, on this network, the TFTP server may be on a completely different network.

The only solution I can think up is trying both the BOOTP/DHCP server and the TFTP server as yaboot is looking for its config file.
Comment 72 Tony Breeds 2009-05-06 19:44:24 EDT
(In reply to comment #69)
> ------- Comment From pavan.naregundi@in.ibm.com 2009-05-06 06:59 EDT-------
>
> http://www.ibm.com/developerworks/wikis/display/WikiPtype/VIOLoadISO

Nice.

> You mean to recreate a bootable iso replacing yaboot, kernel and initrd. Can
> you please mention the steps to create a bootable iso from '-o loop' mounted
> dvd image?

Essentially yes, You'll need to extract the iso, modify the files and the rebuild the iso.  I haven't done it but:
 http://penguinppc.org/ppc64/power-bootable-iso/
Looks like it covers off most of the details.  It'll make doign the Virtual optical device slightly painful sorry.
Comment 73 Arlinton Bourne 2009-05-06 22:03:30 EDT
Created attachment 342757 [details]
This hack works on pre and post GA3 OF. Tested on JS22, JS21 (pre + post), VIOS on Power5

It's a pretty ugly hack but works on POWER 6 & POWER 5.
I've tested it with on an IBM JS22, JS21 (Pre and Post GA3 FW), & VIOS On a pre GA3 Power5 machine:

boot network
boot <network-device>,0.0.0.0,,0.0.0.0,0.0.0.0 

I'm pretty sure there's a better way to do it :)
Comment 74 Tony Breeds 2009-05-07 00:24:50 EDT
(In reply to comment #73)
> Created an attachment (id=342757) [details]
> This hack works on pre and post GA3 OF. Tested on JS22, JS21 (pre + post), VIOS
> on Power5
> 
> It's a pretty ugly hack but works on POWER 6 & POWER 5.
> I've tested it with on an IBM JS22, JS21 (Pre and Post GA3 FW), & VIOS On a pre
> GA3 Power5 machine:
> 
> boot network
> boot <network-device>,0.0.0.0,,0.0.0.0,0.0.0.0 
> 
> I'm pretty sure there's a better way to do it :)  

The patch looks to me like it will break "old crufty firmwares" where the tftp server is on a different network.  Does your setup cover that?
Comment 75 Arlinton Bourne 2009-05-07 10:01:24 EDT
(In reply to comment #74)
> (In reply to comment #73)
> > Created an attachment (id=342757) [details] [details]
> > This hack works on pre and post GA3 OF. Tested on JS22, JS21 (pre + post), VIOS
> > on Power5
> > 
> > It's a pretty ugly hack but works on POWER 6 & POWER 5.
> > I've tested it with on an IBM JS22, JS21 (Pre and Post GA3 FW), & VIOS On a pre
> > GA3 Power5 machine:
> > 
> > boot network
> > boot <network-device>,0.0.0.0,,0.0.0.0,0.0.0.0 
> > 
> > I'm pretty sure there's a better way to do it :)  
> 
> The patch looks to me like it will break "old crufty firmwares" where the tftp
> server is on a different network.  Does your setup cover that?  

Yup our setup does cover it, and it's the reason for the patch. After playing with the old crufty firmware, I discovered when you specify the TFTP server as the server address things broke as the old firmware looked for a BOOTP server, in which the BOOTP server handed off the 'next-server' which was the TFTP server and all was happy.

Today I plan to test the old_crufty stuff against things on the same network.
Comment 76 Arlinton Bourne 2009-05-07 20:18:35 EDT
(In reply to comment #75)
> (In reply to comment #74)
> > (In reply to comment #73)
> > > Created an attachment (id=342757) [details] [details] [details]
> > > This hack works on pre and post GA3 OF. Tested on JS22, JS21 (pre + post), VIOS
> > > on Power5
> > > 
> > > It's a pretty ugly hack but works on POWER 6 & POWER 5.
> > > I've tested it with on an IBM JS22, JS21 (Pre and Post GA3 FW), & VIOS On a pre
> > > GA3 Power5 machine:
> > > 
> > > boot network
> > > boot <network-device>,0.0.0.0,,0.0.0.0,0.0.0.0 
> > > 
> > > I'm pretty sure there's a better way to do it :)  
> > 
> > The patch looks to me like it will break "old crufty firmwares" where the tftp
> > server is on a different network.  Does your setup cover that?  
> 
> Yup our setup does cover it, and it's the reason for the patch. After playing
> with the old crufty firmware, I discovered when you specify the TFTP server as
> the server address things broke as the old firmware looked for a BOOTP server,
> in which the BOOTP server handed off the 'next-server' which was the TFTP
> server and all was happy.
> 
> Today I plan to test the old_crufty stuff against things on the same network.  

I've tested the hack on the following systems with complete success:
 - Apple PowerMac3
 - IBM JS20
 - IBM JS21
 - IBM JS22
 - IBM Squadrons
Comment 77 IBM Bug Proxy 2009-05-09 10:41:34 EDT
------- Comment From vinaysridhar@in.ibm.com 2009-05-09 10:32 EDT-------
(In reply to comment #77)
> (In reply to comment #66)
>
> > No, it is not netbooting . It is a equivalent to directly booting from DVD
> > drive.
>
> Okay.  For the sake of my sanity please open a new bug to track your problem as
> it's /probably/ not netboot releated.  Please mark it as blocking "F11Target"

Opened Fedora bug 499957 for this issue..
Comment 78 Arlinton Bourne 2009-05-09 12:49:05 EDT
(In reply to comment #76)
> (In reply to comment #75)
> > (In reply to comment #74)
> > > (In reply to comment #73)
> > > > Created an attachment (id=342757) [details] [details] [details] [details]
> > > > This hack works on pre and post GA3 OF. Tested on JS22, JS21 (pre + post), VIOS
> > > > on Power5
> > > > 
> > > > It's a pretty ugly hack but works on POWER 6 & POWER 5.
> > > > I've tested it with on an IBM JS22, JS21 (Pre and Post GA3 FW), & VIOS On a pre
> > > > GA3 Power5 machine:
> > > > 
> > > > boot network
> > > > boot <network-device>,0.0.0.0,,0.0.0.0,0.0.0.0 
> > > > 
> > > > I'm pretty sure there's a better way to do it :)  
> > > 
> > > The patch looks to me like it will break "old crufty firmwares" where the tftp
> > > server is on a different network.  Does your setup cover that?  
> > 
> > Yup our setup does cover it, and it's the reason for the patch. After playing
> > with the old crufty firmware, I discovered when you specify the TFTP server as
> > the server address things broke as the old firmware looked for a BOOTP server,
> > in which the BOOTP server handed off the 'next-server' which was the TFTP
> > server and all was happy.
> > 
> > Today I plan to test the old_crufty stuff against things on the same network.  
> 
> I've tested the hack on the following systems with complete success:
>  - Apple PowerMac3
>  - IBM JS20
>  - IBM JS21
>  - IBM JS22
>  - IBM Squadrons  

I should also mention that, the old crufty server actually does the right thing when it's handed a 0.0.0.0 address.
Comment 79 Arlinton Bourne 2009-05-11 16:30:12 EDT
Hey Tony,

Testing yaboot-1.3.14-14, doesn't work on the older crufty stuff. This is how it fails:

BOOTP: ARP request fail: 0 
BOOTP: ARP request fail: 1 
BOOTP: ARP request fail: 2 
BOOTP ERROR: ARP failed, QUIT
        !BA010000 !

I found that specifying any (maybe we can get away with the gateway -- I don't remember) IP information on the older firmware results in a failure similar to the one above.

I did notice that the bootpreply-packet does have the bootp server information in the offset we discard. We can probably parse the offset to get the proper bootp server.
Comment 80 Tony Breeds 2009-05-11 20:59:12 EDT
(In reply to comment #79)
> Hey Tony,
> 
> Testing yaboot-1.3.14-14, doesn't work on the older crufty stuff. This is how
> it fails:

Not that I doubt you in the slightest, but can you give me the output from yaboot.debug.  yaboot-1.3.14-14 is working here on my old crufty machines
(and 32-bit), so I'm slightly confused.
Comment 81 Arlinton Bourne 2009-05-11 22:14:52 EDT
Sure, here I'm booting from the network device with no parameters.

0 > boot network 
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 =   9e 70 1 a6 61 4
BOOTP: gateway  IP =        0.0.0.0
BOOTP: device    /vdevice/l-lan@30000004
BOOTP: loc-code  U9131.52A.063381G-V5-C4-T1


BOOTP R = 1 BOOTP S = 2 
FILE: Netboot/yaboot/yaboot
FINAL Packet Count = 867 
FINAL File Size = 443849 bytes.
load-base=0x4000 
real-base=0xc00000 

Elapsed time since release of system processors: 103812 mins 57 secs

Adding OF methods...
    prom_init - OF interface initialized.
    yaboot_start - Malloc buffer allocated at 00300000 (1048576 bytes)
    yaboot_start - reloc_offset :  0         (should be 0)
    yaboot_start - test_bss     :  0         (should be 0)
    yaboot_start - test_data    :  0         (should be 0)
    yaboot_start - &test_data   :  00234734
    yaboot_start - &test_bss    :  00234730
    yaboot_start - linked at    :  0x00200000
    yaboot_start - Running on _machine = 4
    yaboot_main - /chosen/bootargs = 
    yaboot_main - /chosen/bootpath = /vdevice/l-lan@30000004
    parse_device_path - imagepath = /vdevice/l-lan@30000004; defdevice <NULL>; defpart -1, deffile 
    prom_get_netinfo - using /chosen/bootpreply-packet
    extract_netinfo_args - We have a boot packet
    extract_netinfo_args -  siaddr = <a103c13>
    extract_netinfo_args -  ciaddr = <0>
    extract_netinfo_args -  yiaddr = <a10286c>
    extract_netinfo_args -  giaddr = <0>
    extract_vendor_options - tag= 1, len= 4, data=fffff800
    extract_vendor_options - tag= 3, len= 4, data=0a102ffe
    extract_vendor_options - Storing 10.16.47.254 as gateway from options
    extract_vendor_options - tag= 6, len= 8, data=0a10ff020a10ff03
    extract_vendor_options - tag=42, len=12, data=0a102ffe0a10ff020a10ff03
    extract_vendor_options - tag=28, len= 4, data=0a102fff
    netdev_path_to_dev - path = /vdevice/l-lan@30000004
    yaboot_main - After parse_device_path: dev=/vdevice/l-lan@30000004, part=-1, file=/vdevice/l-lan@30000004
    yaboot_main - After path kludgeup: dev=/vdevice/l-lan@30000004, part=-1, file=/etc/yaboot.conf
Try to netboot
    prom_get_netinfo - using /chosen/bootpreply-packet
    open_file - dev_path = /vdevice/l-lan@30000004
file_name = /etc/01-9e-70-01-a6-61-04
partition = -1
    open_file - device is a network device
--> of_net_open
    of_net_open - dev=/vdevice/l-lan@30000004, part=0x00000000 (-1), file_name=/etc/01-9e-70-01-a6-61-04
    of_net_open - Using old tftp style
    of_net_open - siaddr <10.16.60.19>; filename <\etc\01-9e-70-01-a6-61-04>; ciaddr <10.16.40.108>; giaddr <10.16.47.254>;
    of_net_open - Opening: "/vdevice/l-lan@30000004:,\etc\01-9e-70-01-a6-61-04,10.16.40.108,10.16.47.254"
    of_net_open - file->of_device = 01bd5b80
    prom_claim_chunk - claimed 25165824 at 0x1c00000 (0x1000000)
    of_net_open - TFP...

BOOTP: chosen-network-type = ethernet,auto,none,auto
BOOTP: server   IP =        0.0.0.0
BOOTP: requested filename = \etc\01-9e-70-01-a6-61-04
BOOTP: client   IP =        10.16.40.108
BOOTP: client   HW addr =   9e 70 1 a6 61 4
BOOTP: gateway  IP =        10.16.47.254
BOOTP: device    /vdevice/l-lan@30000004
BOOTP: loc-code  U9131.52A.063381G-V5-C4-T1

BOOTP: ARP request fail: 0 
BOOTP: ARP request fail: 1 
BOOTP: ARP request fail: 2 
BOOTP ERROR: ARP failed, QUIT
        !BA010000 !

method 'load' failed ffffffff
    of_net_open - result: 0
<-- of_net_open - FILE_ERR_OK
Error, can't read config file
--> of_close
    of_close - <@01bd5b80>
    of_close - of_close called
<-- of_close - 0
    open_file - dev_path = /vdevice/l-lan@30000004
file_name = /etc/0a10286c
partition = -1
    open_file - device is a network device
--> of_net_open
    of_net_open - dev=/vdevice/l-lan@30000004, part=0x00000000 (-1), file_name=/etc/0a10286c
    of_net_open - Using old tftp style
    of_net_open - siaddr <10.16.60.19>; filename <\etc\0a10286c>; ciaddr <10.16.40.108>; giaddr <10.16.47.254>;
    of_net_open - Opening: "/vdevice/l-lan@30000004:,\etc\0a10286c,10.16.40.108,10.16.47.254"
    of_net_open - file->of_device = 01bd5b00
    prom_claim_chunk - claimed 25165824 at 0x1c00000 (0x1000000)
    of_net_open - TFP...

BOOTP: chosen-network-type = ethernet,auto,none,auto
BOOTP: server   IP =        0.0.0.0
BOOTP: requested filename = \etc\0a10286c
BOOTP: client   IP =        10.16.40.108
BOOTP: client   HW addr =   9e 70 1 a6 61 4
BOOTP: gateway  IP =        10.16.47.254
BOOTP: device    /vdevice/l-lan@30000004
BOOTP: loc-code  U9131.52A.063381G-V5-C4-T1

BOOTP: ARP request fail: 0 
BOOTP: ARP request fail: 1 
BOOTP: ARP request fail: 2 
BOOTP ERROR: ARP failed, QUIT
        !BA010000 !
Comment 82 Tony Breeds 2009-05-12 00:45:24 EDT
(In reply to comment #81)
> Sure, here I'm booting from the network device with no parameters.

Thanks, I can only surmise that my network is "strange" somehow.

Please try the yaboot from:
http://kojipkgs.fedoraproject.org/scratch/tbreeds/task_1349490/yaboot-1.3.14-15.fc11.ppc.rpm

It attempts to detect "old crufty" and then only specifies the filename in the
load method.

James, if you wouldn't mind giving this one a spin as well.  If we're lucky we'll have a working netboot'able yaboot in F-11 :)
Comment 83 Tony Breeds 2009-05-14 23:17:22 EDT
... Any news on the testing of the latest yaboot package?
Comment 84 IBM Bug Proxy 2009-05-14 23:25:44 EDT
(In reply to comment #39)
> Created an attachment (id=42389) [details]
> The problem in the attempt above is that the bootp-response packet is not
> properly read from openfirmware.  The version 2 patch works in my test
> environment so I added debug statements to the
> routine that reads and returns the packet.  Please apply the patch, retest and
> post the results.  I need
> to see which part is failing.

If you are not trying on power6 please try on it. yaboot works perfectly on power5 in case of picking up the yaboot.conf.
Here is the log
===================
0 > boot /lhea@23c00200/ethernet@23e00100:speed=auto,duplex=auto,9.124.111.85,yaboot.fedora,9.124.111.249,9.124.111.1,5,5,255.255.255.000

TFTP BOOT ---------------------------------------------------
Server IP.....................9.124.111.85

Client IP.....................9.124.111.249

Gateway IP....................9.124.111.1

Subnet Mask...................255.255.255.0
( 1  ) Filename.................yaboot.fedora
TFTP Retries..................5
Block Size....................512

FILE        : yaboot.fedora
BLKSIZE     : 512
TFTP-RETRIES: 5
FINAL PACKET COUNT = 924
FINAL FILE SIZE = 472672  BYTES

Elapsed time since release of system processors: 195684 mins 31 secs

prom_claim - Attempting to claim 00300000 -> 00400000 align=0
yaboot_start - &test_data   :  002334b4
yaboot_start - &test_bss    :  002334b0
yaboot_main - /chosen/bootpath = /lhea@23c00200/ethernet@23e00100:speed=auto,duplex=auto,9.124.111.85,yaboot.fedora,9.124.111.249,9.124.111.1,5,5,255.255.255.000,512
netdev_path_to_filename - path = /lhea@23c00200/ethernet@23e00100:speed=auto,duplex=auto,9.124.111.85,yaboot.fedora,9.124.111.249,9.124.111.1,5,5,255.255.255.000,512
netdev_path_to_filename - filename = yaboot.fedora
netdev_path_to_dev - path = /lhea@23c00200/ethernet@23e00100:speed=auto,duplex=auto,9.124.111.85,yaboot.fedora,9.124.111.249,9.124.111.1,5,5,255.255.255.000,512
yaboot_main - After parse_device_path: dev=/lhea@23c00200/ethernet@23e00100:, part=-1, file=yaboot.fedora
yaboot_main - After path kludgeup: dev=/lhea@23c00200/ethernet@23e00100:, part=-1, file=/etc/yaboot.conf
prom_get_netinfo - chosen=34136056
open_file - dev_path = /lhea@23c00200/ethernet@23e00100:
file_name = /etc/00-
of_net_open - dev=/lhea@23c00200/ethernet@23e00100:, part=0x00000000 (-1), file_name=/etc/00-
prom_get_netinfo - chosen=34136056
prom_get_netinfo - size=-1
of_net_open - Opening: "/lhea@23c00200/ethernet@23e00100:,\etc\00-,,"
of_net_open - file->of_device = 00000000
<-- of_net_open - FILE_ERR_BAD_FSYS
/lhea@23c00200/ethernet@23e00100::-1,/etc/00-: Unknown or corrupt filesystem
Can't open config file
Welcome to yaboot version 1.3.14
Enter "help" to get some basic usage information
--> prom_dump_memory
: 0000000000004000 00000000001fc000  0000000000220d58 00000000000102a8
: 0000000000246abc 00000000000b9544  0000000000400000 0000000001c00000
: 0000000003420000 0000000004be0000  000000000000000<-- prom_dump_memory - ""
boot:
=================





prom_get_netinfo - size=-1























> Created an attachment (id=42755) [details]
> version 6 debug patch.  ignore gateway in bootreply_packet

Output on power6 machine, with latest patch version 6.

0 > boot /lhea@23c00200/ethernet@23e00100:speed=auto,duplex=auto,9.124.111.85,yaboot.fedora,9.124.111.249,9.124.111.1,5,5,255.255.255.0,512

TFTP BOOT ---------------------------------------------------
Server IP.....................9.124.111.85

Client IP.....................9.124.111.249

Gateway IP....................9.124.111.1

Subnet Mask...................255.255.255.0
( 1  ) Filename.................yaboot.fedora
TFTP Retries..................5
Block Size....................512

FILE        : yaboot.fedora
BLKSIZE     : 512
TFTP-RETRIES: 5
FINAL PACKET COUNT = 932
FINAL FILE SIZE = 476912  BYTES

Elapsed time since release of system processors: 212821 mins 59 secs

Adding OF methods...
prom_init - OF interface initialized.
prom_claim - Attempting to claim 00300000 -> 00400000 align=0
yaboot_start - Malloc buffer allocated at 00300000 (1048576 bytes)
yaboot_start - reloc_offset :  0         (should be 0)
yaboot_start - test_bss     :  0         (should be 0)
yaboot_start - test_data    :  0         (should be 0)
yaboot_start - &test_data   :  002344b4
yaboot_start - &test_bss    :  002344b0
yaboot_start - linked at    :  0x00200000
yaboot_start - Running on _machine = 4
yaboot_main - /chosen/bootargs =
yaboot_main - /chosen/bootpath = /lhea@23c00200/ethernet@23e00100:speed=auto,duplex=auto,9.124.111.85,yaboot.fedora,9.124.111.249,9.124.111.1,5,5,255.255.255.0,512
netdev_path_to_filename - path = /lhea@23c00200/ethernet@23e00100:speed=auto,duplex=auto,9.124.111.85,yaboot.fedora,9.124.111.249,9.124.111.1,5,5,255.255.255.0,512
netdev_path_to_filename - filename = yaboot.fedora
netdev_path_to_dev - path = /lhea@23c00200/ethernet@23e00100:speed=auto,duplex=auto,9.124.111.85,yaboot.fedora,9.124.111.249,9.124.111.1,5,5,255.255.255.0,512
yaboot_main - After parse_device_path: dev=/lhea@23c00200/ethernet@23e00100:, part=-1, file=yaboot.fedora
yaboot_main - After path kludgeup: dev=/lhea@23c00200/ethernet@23e00100:, part=-1, file=/etc/yaboot.conf
Try to netboot
prom_get_netinfo - chosen=34136056
prom_get_netinfo - size=-1
open_file - dev_path = /lhea@23c00200/ethernet@23e00100:
file_name = /etc/00-
of_net_open - dev=/lhea@23c00200/ethernet@23e00100:, part=0x00000000 (-1), file_name=/etc/00-
prom_get_netinfo - chosen=34136056
prom_get_netinfo - size=-1
prom_get_gateway - gateway extracted from bootpath IP is 9.124.111.1
of_net_open - Opening: "/lhea@23c00200/ethernet@23e00100:,\etc\00-,,9.124.111.1"
of_net_open - file->of_device = 00000000
<-- of_net_open - FILE_ERR_BAD_FSYS
/lhea@23c00200/ethernet@23e00100::-1,/etc/00-: Unknown or corrupt filesystem
Can't open config file
Welcome to yaboot version 1.3.14
Enter "help" to get some basic usage information
--> prom_dump_memory
: 0000000000004000 00000000001fc000  0000000000221004 0000000000010ffc
: 0000000000247abc 00000000000b8544  0000000000400000 0000000001c00000
: 0000000003420000 0000000004be0000  000000000000000<-- prom_dump_memory - ""
boot:









(In reply to comment #51)


































































Adding OF methods...
prom_init - OF interface initialized.
yaboot_start - Malloc buffer allocated at 00300000 (1048576 bytes)
yaboot_start - reloc_offset :  0         (should be 0)
yaboot_start - test_bss     :  0         (should be 0)
yaboot_start - test_data    :  0         (should be 0)
yaboot_start - linked at    :  0x00200000
yaboot_start - Running on _machine = 4
yaboot_main - /chosen/bootargs =
Try to netboot
partition = -1
open_file - device is a network device
--> of_net_open



partition = -1
open_file - device is a network device
--> of_net_open
Comment 85 Arlinton Bourne 2009-05-15 11:10:04 EDT
(In reply to comment #83)
> ... Any news on the testing of the latest yaboot package?  

It's been working, so far so good.
Comment 86 Tony Breeds 2009-05-15 16:09:41 EDT
Great,

Sorry to bug you (okay that was a bad pun) but if you can James and list 
the configs you've tried I can tag a build and make a case to rel-eng to
include it in F-11.

The more positive results the better!
Comment 87 Arlinton Bourne 2009-06-01 12:25:25 EDT
(In reply to comment #86)
> Great,
> 
> Sorry to bug you (okay that was a bad pun) but if you can James and list 
> the configs you've tried I can tag a build and make a case to rel-eng to
> include it in F-11.
> 
> The more positive results the better!  

No problems here, so far.

Testing in our automated test system yeilded no failures thus far.
Comment 88 Bug Zapper 2009-06-09 05:39:54 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 89 James Laska 2009-07-07 15:21:56 EDT
I've tested a yaboot binary provided by Arlinton on several Power5 LPARs.  All tested distributions netbooted as expected.  My test results are below:

                    ibm-505-lp1 ibm-sf2b-lp1
        RHEL-3-U9       X       X
        RHEL-4-U7       X       X
        RHEL-5-U3       X       X
        F-9             X       X
        F-10            X       X
        F-11            X       X
        rawhide         X       X
Comment 90 Tony Breeds 2009-11-25 20:10:35 EST
I think the yaboot in F-12 is okay, so we can close this right?
Comment 91 James Laska 2009-12-16 14:45:25 EST
I believe so, but my power6 system is out of action.  Can someone confirm power6 behavior?
Comment 92 IBM Bug Proxy 2009-12-18 00:01:03 EST
------- Comment From pavan.naregundi@in.ibm.com 2009-12-17 23:50 EDT-------
With F12 yaboot and real-base set to c00000, power6 machines gave no problem in network booting.
Comment 93 James Laska 2009-12-18 07:49:42 EST
Once again, thanks for the feedback Pavan :)

Closing this issue out based on feedback in rh comment#92 and comment#89.

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