Bug 166625 - Want single boot.iso for all PPC machines
Want single boot.iso for all PPC machines
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Anaconda Maintenance Team
Mike McLean
Depends On:
  Show dependency treegraph
Reported: 2005-08-23 19:14 EDT by David Woodhouse
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-03-29 11:41:29 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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

  None (edit)
Description David Woodhouse 2005-08-23 19:14:46 EDT
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 19:17:27 EDT
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
Comment 2 David Woodhouse 2005-08-23 19:19:35 EDT
Evil attempt to avoid having more than one instance of '&device;'. Unfortunately
still doesn't work on the POWER5 though: "/cpus, unknown word".

: 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 )
        R> +
: strdup ( addr len -- dupaddr duplen addr len )
         dup                          ( addr len len)
         alloc-mem                    ( addr len dupaddr )
         swap                         ( addr dupaddr len )
         2dup >r >r
         r> r>                        ( dupaddr len )
 " /cpus/@0" find-package if
 " 64-bit" rot get-package-property 0= if 
  2drop " 64" 
  else " 32" 
 else " 32"
" &device;"
256 alloc-mem 
" boot "
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"
Comment 3 David Woodhouse 2005-09-02 10:05:20 EDT
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 12:31:37 EDT
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 11:50:23 EDT
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 10:07:59 EDT
Resulting CD image verified on CHRP32 too. Please apply.
Comment 7 Paul Nasrat 2005-09-21 13:18:53 EDT
Confirmed booting here and changes look ok.  


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