Bug 435532 - Fail loading second stage bootstrap
Fail loading second stage bootstrap
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: yaboot (Show other bugs)
8
powerpc Linux
low Severity high
: ---
: ---
Assigned To: Paul Nasrat
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-29 23:01 EST by John C.
Modified: 2009-01-09 02:41 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-09 02:41:20 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Tared device tree (64.28 KB, application/x-gzip)
2008-03-03 18:07 EST, John C.
no flags Details
ofpath script (65.71 KB, application/octet-stream)
2008-03-03 18:08 EST, John C.
no flags Details
requested ofpath (4.86 KB, application/octet-stream)
2008-03-11 22:44 EDT, John C.
no flags Details

  None (edit)
Description John C. 2008-02-29 23:01:03 EST
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 &lt;
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.
Comment 1 Hans de Goede 2008-03-01 02:26:03 EST
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?

Comment 2 Hans de Goede 2008-03-01 17:09:59 EST
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!
Comment 3 Paul Nasrat 2008-03-01 17:26:01 EST
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. 
Comment 4 John C. 2008-03-01 22:42:43 EST
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.
Comment 5 Paul Nasrat 2008-03-02 04:20:37 EST
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
Comment 6 John C. 2008-03-02 10:29:08 EST
Booting into Open Firmware:

prntenv boot-device

------------Partition:common --------------Signature : 0x70  ----------------
boot-device         /disk@0:2,\\:tbxi   hd:,\\:tbxi
    ok


John C.
Comment 7 John C. 2008-03-02 10:43:01 EST
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.
Comment 8 Paul Nasrat 2008-03-03 03:36:00 EST
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


Comment 9 John C. 2008-03-03 18:07:07 EST
Created attachment 296687 [details]
Tared device tree

Here is the device tree
Comment 10 John C. 2008-03-03 18:08:23 EST
Created attachment 296688 [details]
ofpath script

Here is the ofpath. If you need anything else please let me know.

Thanks,
    John C.
Comment 11 Paul Nasrat 2008-03-04 03:19:04 EST
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'
Comment 12 John C. 2008-03-04 07:49:25 EST
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.
Comment 13 John C. 2008-03-04 08:01:19 EST
Here is the ofpathname while in Live:

[root@localhost ~]# ofpathname /dev/sda
/pci@f2000000/AppleKiwi@15/scsi@0/sd@0,0
[root@localhost ~]# 
Comment 14 Paul Nasrat 2008-03-04 18:04:04 EST
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.
Comment 15 John C. 2008-03-10 22:41:49 EDT
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.
Comment 16 Paul Nasrat 2008-03-11 03:40:04 EDT
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)
Comment 17 John C. 2008-03-11 22:43:40 EDT
rpm -qf $(which ofpathname)
ppc64-utils-0.12-3.fc8
[root@localhost ~]# ls
Comment 18 John C. 2008-03-11 22:44:40 EDT
Created attachment 297698 [details]
requested ofpath
Comment 19 John C. 2008-03-11 22:46:03 EDT
Anything else, please let me know.

Thanks, 
       John C.
Comment 20 John C. 2008-04-04 16:09:10 EDT
Any chance we could get this fix in Fedora 9?

Thanks,
     John C.
Comment 21 David Woodhouse 2008-04-06 16:55:11 EDT
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.
Comment 22 David Woodhouse 2008-04-06 17:04:38 EDT
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.
Comment 23 David Woodhouse 2008-04-06 18:02:59 EDT
/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.





Comment 24 John C. 2008-04-07 18:39:02 EDT
Anything you want to try I'm ready...
Comment 25 John C. 2008-07-10 23:41:37 EDT
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.
Comment 26 Bug Zapper 2008-11-26 04:59:02 EST
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
Comment 27 Bug Zapper 2009-01-09 02:41:20 EST
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.

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