Description of problem:
Fail loading second stage bootstrap
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
I installed Fedora 8 from DVD fine but after reboot the system hangs. Booting up
on Fedora Live and using parted I get:
GNU Parted 1.8.6
Welcome to GNU Parted! Type 'help' to view a list of commands.
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
[root@localhost sda1]# ls
ofboot.b yaboot yaboot.conf
The yaboot.conf file looks like:
# yaboot.conf generated by anaconda
init-message=Welcome to Fedora!\nHit <TAB> for boot options
The ofboot.b file looks like:
[root@localhost sda1]# more ofboot.b
MacRISC MacRISC3 MacRISC4
Fedora First Stage Bootstrap
: .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
1 interactive !
0 interactive @ = if
" "(0000000000aa00aa0000aaaaaa0000aa00aaaa5500aaaaaa) " drop 0 7 set-colors
" "(5555555555ff55ff5555ffffff5555ff55ffffff55ffffff) " drop 8 15 set-colors
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 * +
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
dup get-msecs <
" "(0d 0a)" .printf bootyaboot
Hopefully this is something simple as this failure has been seen before but
I can't find a clear answer.
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:
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.
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:
------------Partition:common --------------Signature : 0x70 ----------------
boot-device /disk@0:2,\\:tbxi hd:,\\:tbxi
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?
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:
bash -x /sbin/ofpath --debug /dev/sda
Created attachment 296687 [details]
Tared device tree
Here is the device tree
Created attachment 296688 [details]
Here is the ofpath. If you need anything else please let me know.
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:
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.
Here is the ofpathname while in Live:
[root@localhost ~]# ofpathname /dev/sda
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
bash -x $(which ofpathname) /dev/sda
And rpm -qf $(which ofpathname)
rpm -qf $(which ofpathname)
[root@localhost ~]# ls
Created attachment 297698 [details]
Anything else, please let me know.
Any chance we could get this fix in Fedora 9?
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.
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:
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.