Bug 166625 - Want single boot.iso for all PPC machines
Summary: Want single boot.iso for all PPC machines
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Mike McLean
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-08-23 23:14 UTC by David Woodhouse
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2006-03-29 16:41:29 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
mk-images.ppc (et al) patch. (14.70 KB, patch)
2005-08-23 23:17 UTC, David Woodhouse
no flags Details | Diff
Replacement patch (15.24 KB, patch)
2005-09-20 15:50 UTC, David Woodhouse
no flags Details | Diff

Description David Woodhouse 2005-08-23 23:14:46 UTC
T'would be nice to have a single boot CD which handles all CHRP and Mac, 32-bit
and 64-bit machines.

Comment 1 David Woodhouse 2005-08-23 23:17:27 UTC
Created attachment 118031 [details]
mk-images.ppc (et al) patch.

This patch attempts it, and works on Mac32, Mac64 and apparently also CHRP32.
Unfortunately it seems to have tripped over a firmware bug on some CHRP64 (IBM
POWER5) boxen -- they don't like having &device; appear multiple times in the
boot-script.

Comment 2 David Woodhouse 2005-08-23 23:19:35 UTC
Evil attempt to avoid having more than one instance of '&device;'. Unfortunately
still doesn't work on the POWER5 though: "/cpus, unknown word".


<boot-script>
: STRING+ ( bufaddr buftextlen addr len -- bufaddr buftextlen+len )
        2OVER +         ( ba btl a l bta+btl )
        SWAP DUP >R     ( ba btl a bta+btl l ) ( r: l )
        MOVE
        R> +
;
: strdup ( addr len -- dupaddr duplen addr len )
         dup                          ( addr len len)
         alloc-mem                    ( addr len dupaddr )
         swap                         ( addr dupaddr len )
         2dup >r >r
         move                         
         r> r>                        ( dupaddr len )
;
 " /cpus/@0" find-package if
 " 64-bit" rot get-package-property 0= if 
  2drop " 64" 
  else " 32" 
 then 
 else " 32"
then
strdup
" &device;"
strdup
256 alloc-mem 
0
" boot "
string+
2over                                      \ 'device' 'boot ' 'device' '64'
string+                                    \ 'boot device' 'device' '64'
" :,\ppc\yaboot.chrp conf="                
string+                                    \ 'boot...conf=' 'device' '64'
2swap                                      \ 'device' 'boot dev...conf='
string+                                    \ 'boot...conf=device' '64'
" :,\ppc\ppc"
string+                                    \ 'boot...\ppc\ppc' '64'
2swap                                      \ '64' 'boot...\ppc\ppc'
string+                                    \ 'boot...\ppc\ppc64'
" \yaboot.conf"
string+
eval
</boot-script>

Comment 3 David Woodhouse 2005-09-02 14:05:20 UTC
According to IBM, their firmware will break if the _expanded_ boot-script
becomes longer than 256 characters. We'll need to come up with an alternative
way to choose between 64-bit and 32-bit; probably a hack in yaboot.

Comment 4 David Woodhouse 2005-09-06 16:31:37 UTC
Note to self: Make sure the resulting single CD also has instructions on
tftp-booting into the installer. 

Comment 5 David Woodhouse 2005-09-20 15:50:23 UTC
Created attachment 119031 [details]
Replacement patch

This version is tested successfully on mac32, mac64 and chrp64. It avoids the
IBM firmware problems by using a single yaboot.conf with both 32-bit and 64-bit
kernels and asking the user to choose between them instead of doing it
automatically as we'd prefer, and as we do on the Mac.

Comment 6 David Woodhouse 2005-09-21 14:07:59 UTC
Resulting CD image verified on CHRP32 too. Please apply.

Comment 7 Paul Nasrat 2005-09-21 17:18:53 UTC
Confirmed booting here and changes look ok.  

Commited.


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