Description of problem: Fail loading second stage bootstrap How reproducible: Just install on a MAC Xserve G4 Steps to Reproduce: 1. Install Fedora 8 2. On reboot after install is complete you get fail loading second stage bootstrap Additional info: I installed Fedora 8 from DVD fine but after reboot the system hangs. Booting up on Fedora Live and using parted I get: parted /dev/sda GNU Parted 1.8.6 Using /dev/sda Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) print Model: ATA IBM-IC35L180AVV2 (scsi) Disk /dev/sda: 185GB Sector size (logical/physical): 512B/512B Partition Table: mac Number Start End Size File system Name Flags 1 512B 32.8kB 32.3kB Apple 2 32.8kB 1081kB 1049kB hfs untitled boot 3 1081kB 211MB 210MB ext3 untitled 4 211MB 185GB 185GB untitled lvm Then I mounted the sda1 boot partition: mount -t hfs /dev/sda2 /home/sda1 cd /home/sda1 [root@localhost sda1]# ls ofboot.b yaboot yaboot.conf The yaboot.conf file looks like: --------------------------------------------------------------------------- more yaboot.conf # yaboot.conf generated by anaconda boot=/dev/sda2 init-message=Welcome to Fedora!\nHit <TAB> for boot options partition=3 timeout=80 install=/usr/lib/yaboot/yaboot delay=5 enablecdboot enableofboot enablenetboot magicboot=/usr/lib/yaboot/ofboot image=/vmlinuz-2.6.23.1-42.fc8smp label=linux read-only initrd=/initrd-2.6.23.1-42.fc8smp.img root=/dev/VolGroup00/LogVol00 append="rhgb quiet" --------------------------------------------------------------------------- The ofboot.b file looks like: --------------------------------------------------------------------------- [root@localhost sda1]# more ofboot.b <CHRP-BOOT> <COMPATIBLE> MacRISC MacRISC3 MacRISC4 </COMPATIBLE> <DESCRIPTION> Fedora First Stage Bootstrap </DESCRIPTION> <BOOT-SCRIPT> : .printf fb8-write drop ; : bootyaboot " Loading second stage bootstrap..." .printf 100 ms load-base relea se-load-area " /disk@0:2,\\yaboot" $boot ; : bootcd " Booting CDROM..." .printf 100 ms load-base release-load-area " cd:,\\ :tbxi" $boot ; : bootnet " Booting Network..." .printf 100 ms load-base release-load-area " ene t:0" $boot ; : bootof " Booting OpenFirmware..." .printf 100 ms quit ; " screen" output variable interactive 1 interactive ! 0 interactive @ = if bootyaboot then dev screen " "(0000000000aa00aa0000aaaaaa0000aa00aaaa5500aaaaaa) " drop 0 7 set-colors " "(5555555555ff55ff5555ffffff5555ff55ffffff55ffffff) " drop 8 15 set-colors device-end f to foreground-color 0 to background-color " "(0C)" .printf " First Stage Fedora Bootstrap"(0d 0a)" .printf " "(0d 0a)" .printf " Press l for Fedora,"(0d 0a)" .printf " c for CDROM,"(0d 0a)" .printf " n for Network,"(0d 0a)" .printf " o for OpenFirmware."(0d 0a)" .printf " "(0d 0a)" .printf " Stage 1 Boot: " .printf get-msecs d# 5 3E8 * + begin key? if key case ascii l of " l "(0d 0a)" .printf bootyaboot endof ascii c of " c "(0d 0a)" .printf bootcd endof ascii n of " n "(0d 0a)" .printf bootnet endof ascii o of " o "(0d 0a)" .printf bootof endof endcase then dup get-msecs < until drop " "(0d 0a)" .printf bootyaboot </BOOT-SCRIPT> <OS-BADGE-ICONS> 1010 000000000000F8FEACF6000000000000 0000000000F5FFFFFEFEF50000000000 00000000002BFAFEFAFCF70000000000 0000000000F65D5857812B0000000000 0000000000F5350B2F88560000000000 0000000000F6335708F8FE0000000000 00000000005600F600F5FD8100000000 00000000F9F8000000F5FAFFF8000000 000000008100F5F50000F6FEFE000000 000000F8F700F500F50000FCFFF70000 00000088F70000F50000F5FCFF2B0000 0000002F582A00F5000008ADE02C0000 00090B0A35A62B0000002D3B350A0000 000A0A0B0B3BF60000505E0B0A0B0A00 002E350B0B2F87FAFCF45F0B2E090000 00000007335FF82BF72B575907000000 000000000000ACFFFF81000000000000 000000000081FFFFFFFF810000000000 0000000000FBFFFFFFFFAC0000000000 000000000081DFDFDFFFFB0000000000 000000000081DD5F83FFFD0000000000 000000000081DDDF5EACFF0000000000 0000000000FDF981F981FFFF00000000 00000000FFACF9F9F981FFFFAC000000 00000000FFF98181F9F981FFFF000000 000000ACACF981F981F9F9FFFFAC0000 000000FFACF9F981F9F981FFFFFB0000 00000083DFFBF981F9F95EFFFFFC0000 005F5F5FDDFFFBF9F9F983DDDD5F0000 005F5F5F5FDD81F9F9E7DF5F5F5F5F00 0083DD5F5F83FFFFFFFFDF5F835F0000 000000FBDDDFACFBACFBDFDFFB000000 000000000000FFFFFFFF000000000000 0000000000FFFFFFFFFFFF0000000000 0000000000FFFFFFFFFFFF0000000000 0000000000FFFFFFFFFFFF0000000000 0000000000FFFFFFFFFFFF0000000000 0000000000FFFFFFFFFFFF0000000000 0000000000FFFFFFFFFFFFFF00000000 00000000FFFFFFFFFFFFFFFFFF000000 00000000FFFFFFFFFFFFFFFFFF000000 000000FFFFFFFFFFFFFFFFFFFFFF0000 000000FFFFFFFFFFFFFFFFFFFFFF0000 000000FFFFFFFFFFFFFFFFFFFFFF0000 00FFFFFFFFFFFFFFFFFFFFFFFFFF0000 00FFFFFFFFFFFFFFFFFFFFFFFFFFFF00 00FFFFFFFFFFFFFFFFFFFFFFFFFF0000 000000FFFFFFFFFFFFFFFFFFFF000000 </OS-BADGE-ICONS> </CHRP-BOOT> [root@localhost sda1]# --------------------------------------------------------------------------- Hopefully this is something simple as this failure has been seen before but I can't find a clear answer. Thanks, John C.
Erm, Looks like you misclicked the component, as I'm pretty sure you didn't want to file this against 8Kingdoms. Please choose a more appropriate component and also select: " Reassign bug to owner and QA contact of selected component" please?
This is a very good detailed bug report about yaboot which originally got mis filed (wrong component) changing assignment to default yaboot owner, please read the original bug report its well written!
Can you boot into OF and tell me what printenv boot-device shows, also from rescue what ofpath /dev/sda gives. A tarred up /proc/device-tree would also be useful.
booting from a rescue disk: ofpath /dev/sda /disk@0 Can you tell me what you mean by boot into OF? Can I get you the /proc/device-tree if I boot from Live? When I boot from Live and can simply get directly to the web without aving to fiddle around with trying to mount a USB drive to get you the info. If not I can get it through rescue. Let me know. Thanks, John C.
Yes booting into the live CD and tarring up /proc/device-tree will be sufficient. If you have a keyboard attached you should be able to boot into OF using Cmd + Option O + F as it boots (not sure about Xserve - most macs have a tone) or hitting 'o' in the first stage boot loader
Booting into Open Firmware: prntenv boot-device ------------Partition:common --------------Signature : 0x70 ---------------- boot-device /disk@0:2,\\:tbxi hd:,\\:tbxi ok John C.
When I try to tar up the device-tree I get tar errors saying: file x: File changed as we read it Is there a specific option on tar that I need to use? Thanks, John C.
You can ignore those as they will be from eg CPU nodes, which I'm not intereted in, just give me the created tar file from tar czvf /tmp/device-tree.tar.gz /proc/device-tree Also can you attach ofpath.out generated from: script ofpath.out bash -x /sbin/ofpath --debug /dev/sda Ctrl-D
Created attachment 296687 [details] Tared device tree Here is the device tree
Created attachment 296688 [details] ofpath script Here is the ofpath. If you need anything else please let me know. Thanks, John C.
OK ofpath isn't correctly resolving your linux device to the correct ofpath. The information you've given is probably enough to come up with a patch (might take some back and forth) if you have time to test. In the short term can you see if ofpathname /dev/sda gives you something better looking (and paste that in here) - based on looking at the device-tree I'd expect: /pci@f2000000/AppleKiwi@15/ata-6@0/disk@0 Short term you can probably get it booting by setting boot-device whilst in the live env as root : nvsetenv boot-device 'hd:2,\\:tbxi'
I appreciate the time you've spent and any testing you need I can do. The Live environment and your exact command line instructions has made this process much easier. Let me know what you would like to try. Thanks again, John C.
Here is the ofpathname while in Live: [root@localhost ~]# ofpathname /dev/sda /pci@f2000000/AppleKiwi@15/scsi@0/sd@0,0 [root@localhost ~]#
OK so ofpathname is not working for that either - although getting a better stab. Thanks for the testing offer and the excellent feedback so far.
Tried this in Live but had not luck. nvsetenv boot-device 'hd:2,\\:tbxi' Please let me know when you have something you'd like to try.
Sorry weekend was far busier than I anticipated. Can you give me the output file (ofpathname.out) from script ofpathname.out bash -x $(which ofpathname) /dev/sda Ctrl-D And rpm -qf $(which ofpathname)
rpm -qf $(which ofpathname) ppc64-utils-0.12-3.fc8 [root@localhost ~]# ls
Created attachment 297698 [details] requested ofpath
Anything else, please let me know. Thanks, John C.
Any chance we could get this fix in Fedora 9? Thanks, John C.
A workaround is to set ofpath= manually in /etc/yaboot.conf. Please could you attach a tar of /proc/scsi/? For some reason, ofpath isn't correctly detecting the hostadapter type.
Oh, don't bother. I can see from the source that the pata_pdc2027x driver doesn't provide a proc_info() routine and thus won't appear in /proc/scsi/ We should be able to get the same information from sysfs instead of from /proc/scsi.
/me is lost in a twisty maze of sysfs symlinks, all alike. We should be able to work out $SCSI_DRIVER from /sys/class/scsi_host/host$DEVICE_HOST/proc_name instead of relying on the directories in /proc/scsi/* I'm fairly unconvinced that the thing with $SCSI_HOSTNUMBER is at all sane, but we could probably reproduce it through sysfs too, somehow.
Anything you want to try I'm ready...
Could you tell me where in the source tree I could find the these files? I've begun working on some uboot code at work and might be able to scrounge up some help in finding the issue. Thanks, John C.
This message is a reminder that Fedora 8 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 8. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '8'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 8's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 8 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.