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.
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? :)
Patch looks reasonable to me. Chris can you look at it too, and give me a secondary ack then I'll commit.
NAK. 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)
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?
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
mount -t hfs /dev/sda3 /mnt should work
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 partition. This really shouldn't be hard to fix properly though.
Still broken in FC4T2.
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
Verified this still happens in rawhide-2005-04-21. Booting into 'linux-up' works fine and shows two processors on a dual G5 box.
Fixed differently in CVS
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?
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.
Just to add to comment #13 The mac64 boot.iso is on CD1 in images/mac64 or here http://download.fedora.redhat.com/pub/fedora/linux/core/test/3.92/ppc/os/images/mac64/boot.iso You'll need to boot off that and then use the CD/DVD.
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.
David Woodhouse, Using a single bootable CD for all architectures should probably be filed as a independant RFE. I am closing this one
Agreed. Filed as bug #166625