Bug 149618 - Anaconda installs ppc32 SMP kernel on ppc64 machine.
Anaconda installs ppc32 SMP kernel on ppc64 machine.
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Paul Nasrat
Mike McLean
Depends On:
Blocks: fedora-ppc
  Show dependency treegraph
Reported: 2005-02-24 10:58 EST by David Woodhouse
Modified: 2007-11-30 17:11 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-08-23 18:37:28 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Possible fix. (1.57 KB, patch)
2005-02-24 11:01 EST, David Woodhouse
no flags Details | Diff

  None (edit)
Description David Woodhouse 2005-02-24 10:58:19 EST
The base PPC64 kernel is SMP; but the ppc32 arch has a separate SMP
kernel. Anaconda works out that it's running on an SMP box, tries to
install the kernel-smp package and doesn't care that it's a kernel for
ppc32 not ppc64. The hardware is more picky.
Comment 1 David Woodhouse 2005-02-24 11:01:59 EST
Created attachment 111381 [details]
Possible fix.

This attempts to fix the problem by requiring that the kernel-smp (or hugemem,
etc) package is a precise match. If my understanding of rhpl.arch.canonArch is
correct, this ought to work for i586, i686 etc. as before while fixing the
problem for ppc/ppc64. I didn't want to just disable the kernel-smp bit for
ppc64; that seemed like a bit of a hack.

Caveats about me not having done any python before last weekend still apply.
The intention was that the select() function would remain compatible for
anything that didn't provide a specific architecture -- is that what I've
actually done? :)
Comment 2 Paul Nasrat 2005-03-01 12:22:53 EST
Patch looks reasonable to me.  Chris can you look at it too, and give me a
secondary ack then I'll commit.
Comment 3 Jeremy Katz 2005-03-01 13:42:20 EST

This causes a) package selection to be slower and, more importantly, b) package
selection to not necessarily pick the best arch when you don't specify the arch.

It also doesn't take into account that you can end up with canonArch being
things like athlon when there isn't an athlon kernel (anymore)
Comment 4 David Woodhouse 2005-03-01 17:40:29 EST
Thanks for the feedback. Do you have a preferred approach? I still don't much
like the idea of just making the -smp kernel 'ifnarch ppc64' although that's the
obvious quick hack to fix the problem.

Should we add a separate function for selecting extra kernels instead of
extending the existing 'select()' function and making it slower? I didn't
realise that select() was in a performance-critical fast path.

This new function could succeed in selecting the new 'kernel-XXX' package _only_
if that package exists for the _same_ architecture as the 'kernel' package we're
actually going to install. We can get at that information, right?

So on athlon we'd install the kernel-smp.i686 package because we were already
going to install the kernel.i686 package. But on ppc64 we'd ignore the
kernel-smp.ppc package because we were going to install the kernel.ppc64
package. Does that seem reasonable?
Comment 5 Andrew Cagney 2005-03-18 09:58:51 EST
Workaround for fc4test1:

First the symptom: After the install the machine boots "linux" and then after a
very short time, crashes - it booted that 32-bit kernel.

- have a finger hovering over the <TAB> key while resetting the machine

- as soon as "boot: " is seen, hit <TAB>, YOU ONLY HAVE 5 SECONDS
You'll see two choices "linux" and "linux-up".

- enter "linux-up" and hit return
things will proceed as normal


Workaound 2:
(it might be possible to do this before the reboot, and I'm sure there's a more
"PC" way of doing this :-)

- hmount your bootstrap partition, e.g., 
  # hmount /dev/sda3
  Volume name is "bootstrap"

- find your yaboot.conf file:
  # hdir
  f  tbxi/UNIX         0      2675 Mar 17 17:00 ofboot.b
  f  boot/UNIX         0    141972 Mar 17 17:00 yaboot
  f  conf/UNIX         0       504 Mar 17 17:00 yaboot.conf

- copy it in
  # hcopy :yaboot.conf /tmp/yaboot.conf

- compare it to your "master copy" in /etc
  # diff /tmp/yaboot.conf /etc/yaboot.conf
  (if they're different go back to the first step :-)

- edit the master version reversing the order of "linux" and "linux-up"
  # ed /etc/yaboot.conf

- install the edited version
  # hcopy /etc/yaboot.conf :yaboot.conf
Comment 6 Paul Nasrat 2005-03-18 10:00:57 EST
mount -t hfs /dev/sda3 /mnt should work
Comment 7 David Woodhouse 2005-03-18 10:07:21 EST
Alternative workaround: Switch to tty2 before rebooting, run 'rpm -e kernel-smp'.
Or just edit /etc/yaboot.conf and then run 'ybin' to install it to the bootstrap

This really shouldn't be hard to fix properly though.
Comment 8 David Woodhouse 2005-04-18 23:14:09 EDT
Still broken in FC4T2. 
Comment 9 Joe Hoot 2005-04-22 08:09:49 EDT
This is happening to me on my dual proc g5 before I get to anaconda.  It looks
like although there may be a vmlinuz kernel that has support for ppc64 + smp,
yaboot doesn't give me the option to run it.  Instead the cd boots up, I hit tab
and see 1 kernel available-- linux.  I've tried booting it and appending
maxcpus=2, but have had no luck.  I still get this message and then get frozen
at OpenFirmware:

opening display /pci@0,fd000000/NVDA,Parent@10/NVDA,Display-B@1... ok 
copying 0F device tree...done 
starting cpu /cpus/PowerPC,G5...failed: 0000000 
Initializing fake screen: NVDA,Display-A 
Calling quiesce ... 
returning 0x01400000 from prom_init 

Invalid memory access at    SRR0:  00000000.01403b7c    SRR1: 10000000.000083030 

Apple PowerMac7,3 5.1.8f7 BootROM build on 10/26/04 at 16:30:32 16:30:32 
Comment 10 David Lawrence 2005-04-22 11:05:54 EDT
Verified this still happens in rawhide-2005-04-21. Booting into 'linux-up' works
fine and shows two processors on a dual G5 box.
Comment 11 Jeremy Katz 2005-04-26 22:22:10 EDT
Fixed differently in CVS
Comment 12 David Miller 2005-05-10 19:30:15 EDT
Current FC4 test3 CDROMs fail to boot similarly.  Should I
give "linux-up" to the CDROM bootloader prompt even
though "linux" is the only image listed?  Or is CDROM
booting still not expected to work on SMP G5 systems?
Comment 13 David Woodhouse 2005-05-11 02:06:15 EDT
If it's the _CD_ which fails to boot, then it sounds like you're using the wrong
boot.iso. At the moment we have a separate ISO for 32-bit and for 64-bit Macs.
Comment 14 Paul Nasrat 2005-05-11 10:07:19 EDT
Just to add to comment #13

The mac64 boot.iso is on CD1 in images/mac64 or here


You'll need to boot off that and then use the CD/DVD.
Comment 15 David Woodhouse 2005-05-11 10:09:12 EDT
One of these days we really ought to figure out how to do a single bootable CD
which boots on all of {mac,chrp}{32,64} though.
Comment 16 Rahul Sundaram 2005-08-23 18:37:28 EDT
David Woodhouse,

Using a single bootable CD for all architectures should probably be filed as a
independant RFE. I am closing this one
Comment 17 David Woodhouse 2005-08-23 19:15:38 EDT
Agreed. Filed as bug #166625

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