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.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.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.
Just to be sure, file system where you want to read yaboot.conf is which? ext2?
(In reply to comment #8) > ------- Comment From rrakus 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.
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; }
(In reply to comment #10) > ------- Comment From pauln 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)
Created attachment 316724 [details] contents of /proc/device-tree
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
(In reply to comment #13) > ------- Comment From pauln 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:
Moving off of Beta blockers. ppc64 netboot is not something I'd hold the beta for.
I could reproduce this issue in F10 beta.
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
None of these patches appear to have been applied to git. Paul?
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.
To RedHat Have the above mentioned yaboot related patches been included in the F10 preview release ?
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.
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).
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.
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.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 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.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.. ======================
Forgot to mention I tried it on Fedora 10 Preview.
(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?
(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.
At this point, I don't think this will make final release - it will have to be fixed in an update.
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
Perhaps rrakus can assist with comment#22 ?
Please ignore comment#23 ... that was intended for another bug :(
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).
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.
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.
For a quick test I've placed a compiled verion at: http://ozlabs.au.ibm.com/~tony/yaboot/mainline/debug/yaboot
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: ===========================
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
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.
(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
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
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
(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
(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"
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
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
> 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
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"
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
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
(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
This issue is still present in Fedora 11 Alpha.
Now issue is seen in power5 machines also, hence raising the severity.
Created attachment 334090 [details] New patched version of yaboot to test. ------- Comment (attachment) From tbreeds.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.
(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).
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"
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.
(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 From pavan.naregundi.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
(In reply to comment #51) > ------- Comment From pavan.naregundi.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.
(In reply to comment #52) > (In reply to comment #51) > > ------- Comment From pavan.naregundi.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 From mjwolf.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?
(In reply to comment #54) > ------- Comment From mjwolf.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.
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.
(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 From pavan.naregundi.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
(In reply to comment #58) > ------- Comment From pavan.naregundi.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
(In reply to comment #58) > ------- Comment From pavan.naregundi.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 From pavan.naregundi.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
(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.
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).
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 :)
(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 From pavan.naregundi.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
(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/
(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 From pavan.naregundi.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
(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
(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.
(In reply to comment #69) > ------- Comment From pavan.naregundi.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.
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 :)
(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?
(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.
(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 From vinaysridhar.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..
(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.
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.
(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.
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 !
(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 :)
... Any news on the testing of the latest yaboot package?
(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
(In reply to comment #83) > ... Any news on the testing of the latest yaboot package? It's been working, so far so good.
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!
(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.
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
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
I think the yaboot in F-12 is okay, so we can close this right?
I believe so, but my power6 system is out of action. Can someone confirm power6 behavior?
------- Comment From pavan.naregundi.com 2009-12-17 23:50 EDT------- With F12 yaboot and real-base set to c00000, power6 machines gave no problem in network booting.
Once again, thanks for the feedback Pavan :) Closing this issue out based on feedback in rh comment#92 and comment#89.