Red Hat Bugzilla – Bug 162046
Partitioning and yaboot fail on Blue and White G3 Power Macintosh
Last modified: 2009-01-09 01:53:11 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050323 Epiphany/1.4.4
Description of problem:
Disk druid and/or Yaboot don't seem to work on Power Mac Blue&White G3
Version-Release number of selected component (if applicable):
Steps to Reproduce:
This is a Blue & White G3, which are notorious for firmware "issues." The machine was previously running MacOS 10.3 with all updates, including all firmware updates.
Initial attempts to boot the FC4 CD failed. The internal HP CD-RW was replaced with a generic (possibly Toshiba? but the label was removed) 24x ATAPI CD-ROM and I was able to manually boot via Command+Option+O+F (to enter Open Firmware) followed by ejecting the CD, re-inserting it, and then running "boot cd:,\\:tbxi". (Without ejecting and re-inserting I got an error that OF failed to read Block 0.)
Once into Anaconda, all seemed to go well. Using Disk Druid, I created a 1MiB Apple_Bootstrap partition, a 1GiB swap, and the remainder of the disc (about 114GiB) root partition. (No LVM) The installation ("Personal Desktop" with all defaults) proceeded normally, and the "Finished (Reboot)" screen appeared.
After ejecting the CD and rebooting, the firmware displayed the "Where is the System folder?" flashing icon.
Manually launching via OF did not work using either of "hd:1,\\:tbxi" nor "hd:1,\yaboot" nor even my guess of "hd:1,yaboot" and various possible other parititions numbers (1..5).
Booting again from the CD-ROM, "boot cd:,\\:tbxi" - "linux rescue" the root partition mounted sucessfully under /mnt/sysimage. "parted" showed that the disklabel type was "msdos" with the partitions assigned: hda1 => bootstrap, hda2 => root, hda3 => swap. "mkofboot" and "ybin" ran, apparently successfully, from the chroot, and "hmount"/"hdir" from hfsutils showed the expected 3 files on the bootstrap partition.
Suspicious of the MS-DOS disklabel type, I wiped with Parted and recreated a Macintosh disklabel. This re-arranged the partition numbers, since the Macintosh disklabel itself is considered "partition 1," 2 => bootstrap, 3 => swap, 4 => root. I also set the "root," "boot," and "swap" flags in parted.
For paranoia's sake, I also ran "mkswap", "mke2fs"+"tune2fs -j", and "hformat" on the appropriate partitions.
Re-running Anaconda, however, brings up an error in the Disk Druid step. I can sucessfully tell Anaconda to use the swap and root partitions, however, the Apple_Bootstrap partition brings up an error saying,
"The size of the Apple_Bootstrap ( 1.000 M) is bigger than the maximum allowed size of 1M"
I've tried this now with the Apple_Bootstrap size at precisely 1M (running "from 1 to 2" in parted) and slightly under (running from 0.032 - just after the disklabel - to 2), to no avail.
*** Bug 162047 has been marked as a duplicate of this bug. ***
i've also come up aganist this on a g3 powerbook.
i had started out on the false assumption that i was messing with a 'new world'
machine, but some googling suggests it may be because the machine is the 'old
the difference is essentially where the system goes looking for the boot image:
old world its in rom, and new world they use the little partition on the first hd.
.. or at least thats my conclusion after one day on apple hardware :)
i had a macOSX 10.0 disk lying about, and also open darwing 7.2.x, and did a bit
ofcircle work around being able to install various combinations, but to no
avail, could not ever successfully boot from the install, on any of the OS's (
actually couldnt install darwin...)
i believe the solution is going to be for me to hunt down the original macos 9
system disk, reinstall that, then do an install using the 'xboot' trickery from
yellow dog or something, this all being cos the mac is 'old world'
Unfortunately(?), the Blue and White G3 is a New World machine.
Old World machines contain a boot ROM that's essentially a part of the MacOS
System; New World machines use Open Firmware, and run a bootstrap from disc
The problem may be two-part:
(a) The B&W G3 has a nasty primordial implementation of Open Firmware;
(b) The installer seems to have a bad bug with partitioning or two:
(1) It creates an msdos partition table, which I'm fairly sure isn't a Good
(2) It can't use a pre-existing partition table sucessfully.
can you boot into rescue mode, remove the msdos partition table and use parted
to create a blank mac partition table. (mklabel mac).
Can you attach the output of cat /proc/cpuinfo please, how we determine if it's
a Mac or pSeries/iSeries machine may break down on the B&W G3 firmware.
This bug seems to affect Powerbook G4 667 also.
Here is some info on this bug that I sent to the linux-ppc-yaboot list. I am
pretty sure it is related to this bug. It appears that linux ppc is nowhere
near as mature as linux on x86.
Greetings Everyone -
I have a rather messy problem with an old Powermac G3 (blue and white) that I
want to install Fedora Core 4 PPC on. The installation seems to go through
fine and it even appears that the system installs the bootloader at the end
but after a reboot the mac cannot run the boot loader. Right now the system
has an internal AHA 2940U2B scsi card that is supposedly bootable. The layout
of the disk partitions is as follows
/dev/sda1 -> 800k Apple Boot Strap Partition
/dev/sda2 -> 100 Mb boot partition mounted under /boot
/dev/sda3 -> 8.0 Gb logical volume partition which is later mounted under /
The following is the /boot/etc/yaboot.conf file
# yaboot.conf generated by anaconda
init-message=Welcome to Fedora Core\!
Hit <TAB> for boot options
I had to indent each line so stupid ms outlook wouldn't capitalize the first
letter but in the original file there are no spaces at the beginning of each
I am able to use the FC4 install cd 1 to boot linux in rescue mode, mount the
disk partitions mentioned above and then chroot /mnt/sysimage. Using the
ofpath on the disks I have determined that the openfirmware path for /dev/sda
is /pci@80000000/pci-bridge@d/scsi@4/@0:1, so I reboot the mac and then go
into the openfirmware (ver 3.1.1) and set the boot-device environment variable
to /pci@80000000/pci-bridge@d/scsi@4/@0:1,\yaboot but when I reboot the yaboot
loader never runs. I have tried many variations of this including setting the
boot-file openfirmware environment variable to yaboot, \\yaboot, \\:yaboot and
none of them have worked. I even tried performing an install of FC4 PPC Linux
on an ide drive attached to the primary ide controller of the mother board
(while disconnecting the scsi system) and I experience the same problem. So I
don't think it is the scsi controller or its firmware code that is the
problem. Any one have any ideas what I am doing wrong here? I could really
use some help with this.
Yes this seems related - can you confirm if you have an msdos partition table or
mac partition table.
Boot into rescue mode and
parted /dev/sda print
can you also attach the output of cat /proc/cpuinfo
Booting from CD 1 into rescue mode and then chrooting /mnt/sysimage the parted
command above gives me the following...
Disk geometry for /dev/sda: 0.000-8748.164 megabytes
Disk label type: msdos
Minor Start End Type Filesystem Flags
1 0.031 7.844 primary hfs boot
2 7.844 109.819 primary ext3
3 109.819 8746.325 primary lvm
cat /proc/cpuinfo gives me
cpu : 740/750
temperature : 39 C (uncalibrated)
clock : 350Mhz
revision : 2.2 (pvr 0008 0202)
bogomips : 696.32
machine : PowerMac1,1
motherboard : PowerMac1,1 MacRISC Power Macintosh
detected as : 66 (Blue&White G3)
pmac flags : 00000000
L2 cache : 1024K unified
memory : 768MB
pmac-generation : NewWorld
It does look like the disk type label is msdos.
Do you think that booting into rescue mode from cd 1 and then
chroot /mnt/sysimage and then changing the label on /dev/sda might help?
Reviewing comment #4 you seem to think this is fixable? Can you give me some
more details about how to do this? I have little experience with Mac hardware
and the tools that come with Linux PPC.
Certainly it is fixable by manually converting the partition - however I want to
understand *why* this is occuring.
Any chance you could attach the logs from the install - from rescue mode
/mnt/sysimage/var/log/anaconda* and /mnt/sysimage/root/*log as individual
uncompressed attachments to this bugzilla please.
I will try but it will have to be tomorrow. If you would be so kind as to
post the steps for the fix I promise that tomorrow I will send you the logs
that I can find under the root file system. Right now I have to leave work
Created attachment 119408 [details]
Created attachment 119409 [details]
Created attachment 119410 [details]
Created attachment 119411 [details]
Anaconda ks cfg
Created attachment 119412 [details]
Powermac G3 B&W Anaconda Install log
Created attachment 119413 [details]
Powermac G3 B&W Anaconda Install Syslog
The above are all the logs you asked for. These are for a FC4 PPC install on
a Powermac G3 Blue and White. The same machine for which the parted
and /proc/cpuinfo I posted earlier. I hope this will help you guys fix the
I was just looking through those logs. The i/o errors mentioned occurred
because install cd 1 had was slightly corrupted. So I made another copy of cd
1 and completed the install with the new copy. I would think that the error
message is unrelated to this bug though.
I found a solution to this bug. It is not pretty *but* at least it will get
you going. First install FC4 ppc as usual. The after the install is complete
reboot from cd 1 and at the yaboot prompt type "linux rescue". After the
system boots and mounts your system partitions under /mnt/sysimage it will
drop you into a root shell. From there issue the "chroot /mnt/sysimage"
command. Then as root type the following "parted /dev/sda" (or
parted /dev/hda is using ide drives). Modify the disk label as per the
instructions on this page
http://www.gnu.org/software/parted/manual/html_node/parted_54.html. That will
effectively destroy your disk partitions. Now reboot and reinstall FC4 ppc.
After the install is complete and provide you have set the openfirmware boot-
device environment variable properly you will be able to run yaboot when the
system restarts! It worked for me so I know it will work for you. I have
given the developers on this list alot of feedback on what the problem was. I
am disappointed that they couldn't take a few minutes to explain the temporary
The issue is that although you can work around this gets me no where in
understanding why anaconda is setting this up correctly. I do not see this on
any of the hardware available to me and it seems only to affect B&W G3s.
I'm glad you've got a working install but this bug is still going to be present
on the B&W it seems. I was going to update with details later today as I work
through my bug list...
I gave you all the logs you asked for. And I did provide a fair amount of
detail of the problems I was experiencing. I hope this helps you to find the
problem. I want to point out that I pulled the scsi drive I used on this mac
from a PC. Ergo, the "msdos" disk label. I don't know if Anaconda is
supposed to write the mac disk label onto the disk before it partitions the
drive. But it might explain why an install of FC4 PPC on a mac that had an
existing bootable installation of mac os X or system 9 would work without any
problems. If Anaconda is supposed to write the disk label then there is
clearly some problem.
By the way I just noticed that install will fail if you select xfs at the file
system. I use XFS for all my x86 machines running linux and in the past I was
able use it as the default file system on all my partition including the /
and /boot. I got a kernel panic and the system froze on this mac when I
reinstalled using XFS as the default file system for all my partitions except
of course the apple bootstrap one. Maybe it is an anaconda issue or maybe it
isn't. It looks almost as if the boot kernel doesn't know how to handle the
xfs file system. Maybe the xfs kernel module is missing from the initial ram
disk. Installing using ext3 seems to work fine and gives no problems during a
Comment #23 - if you took the disk out of a pc what was the original parition
table on, what option for disk formatting did you use (delete Linux partitions,
delete all partitions?).
Comment #24 is really unrelated - xfs is not a supported install option in
anaconda, you can install using it by passing xfs on the boot command line to
yaboot (eg linux xfs) but bugs (unless they contain patches) for xfs will be
closed WONTFIX as documented in the anaconda source.
I pulled the disk out of a pc running fedora core 3. I never checked the
original partition table on disk *but* the file system on it was XFS. I would
bet the farm though that it was an msdos partition table. I did instruct
anaconda to delete *all* paritions. Effectively wiping out all the disk
slices and recreating them for the current install. This is my preferred
approach whenever I install a new OS.
I suspected XFS was not supported on FC4 PPC but I can't say I am not
disappointed. I like XFS and it seems reasonable to expect it to be available
across all supported linux platforms. Although I am a programmer with some C
experience I have no experience with operating system code or file
system/block device drivers. So I cannot really offer to support XFS in linux
There is definitely a bug here - as far as I can see we should have selected mac
partition format and didn't. The cpuinfo and logs don't reveal anything going
wrong particularly - basically I'd need to step through what's happening here.
If you are willing I can supply you with instructions on how to get some more
information that will assist me in debugging this further. I probably won't get
to writing them until next week. I can probably do it non destructively too
(just go up to and past the partitioning screen). If you have time and are
willing to do this so I can improve the support on B&W G3 please let me know
with a comment in this bug.
xfs is not supported in Fedora period - regardless of arch. You can choose to
install using it as I documented.
Ok. I am willing to offer assistance *but* the instructions must be non
destructive. I have an FC3 x86 PostgreSQL/Apache/PHP platform that I use for
a database driven retail reporting webapp. I created this mac linux platform
to use it as a test bed for my Apache/PHP code developed for this WebApp.
Although it is a test system I do plan to use it extensively and it did take
alot of work to get the system up and stable so I want to keep it intact.
When you write your instructions send them my way and I will provide you the
feedback and information you need.
Are you still looking for someone with a Powermac G3 B&W to try this on? I just
acuquired a G3 B&W and have the exact same issues. I've tried partitioning with
Yellowdog and then installing FC4, but I get the same boot issues as everyone
else. I have not seen a final resolution to this issue, and would be more than
happy to try to help iron out a full fix for this issue, but I'll need guidance
on how to get the information you need to figure this out.
John - thanks for the offer.
Can you boot into OF (Cmd Option OF at boot) and do:
and let me know what it says. If you do irc I'm on #fedora-ppc on freenode
where we could probably test more quickly than bugzilla/mail cycle.
I am not a guru on Linux. I know embedded systems very well, but when you
give me instructions on how to do things make it simple. I catch on fast but you
need to make it clear the first time (example, booting into OF. I can "linux
rescue" at this point but have no idea what you are referring to with OF option.)
I be glad to use IRC but there are many freenode listings for servers (4 in
the US) and my irc client needs a network to go along with the server (I'm using
a ircl 1.3 for the MAC). I'm on east coast time as well.
Like I mentioned before I had to partition the disk using YellowDog 4.01,
otherwise FC4 would crash when it was about to start formatting the drives. I
assume youâd rather troubleshoot the current boot problem instead of the
formatting problem (Iâm guessing their closely related.)
Last thing is do you have any suggestions on getting the error codes and
messages off of the G3. I thought a USB stick would be ok but am open to
suggestions. (not sure of the command line to mount the USB device.
Still willing to give it a try?
Took me a few to figure out you were referring to the MAC keyboard. Here is
Press l for Fedora Core,
c for CDROM,
n for Network,
o for OpenFirmware.
Stage 1 Boot:
Loading second stage bootstrap..
Apple PowerMac1,1 1.f4 BootROM built on 04/09/99 at 13:57:32
Copyright 1994-1999 Apple Computer, Inc.
All Rights Reserved.
To continue booting, type âmac-bootâ and press return.
To shut down, type âshut-downâ and press return.
3 > ok
3 > printenv boot-device
----------------Partition: common -------- Signature: 0x70 -----------------
Hereâs my disk info:
Disk geometry for /dev/hda: 0.00-12395.250 megabytes
Disk label type: mac
Minor Start End Filesystem Name Flags
1 0.000 0.031 Apple
2 0.031 1.031 hfs untitled boot
3 1.031 10295.492 ext3 untitled
4 10295.492 12295.250 linux-swap swap swap
5 12295.250 12395.250 ext3 untitled
OK - if you are seeing that menu then the first stage bootloader is installed,
which is a good sign.
If you boot off the install CD into rescue mode and can you do the following:
Please give me the output of the following two commands:
mount -t hfs -o ro /dev/hda2 /mnt/spare
in /mnt/spare there should be an ofboot.b and a yaboot.conf - if you could get
those off the machine somehow (scp, usb stick) and attach to this bug that'd be
great. If you need detailed instructions for that let me know.
Can you also try booting into OF and typing
Thanks in advance
Here are the command outputs (what there is):
sh: ofpathname: command not found
mount ât hfs âo ro /dev/hda2 /mnt/spare
mount: unknown filesystem type âhfsâ
3 > boot /pci@80000000/pci-bridge@d/pci-ata@1/@/disk@0:2,\yaboot
canât OPEN: /pci@80000000/pci-bridge@d/pci-ata@1/@/disk@0:2,\yaboot canât OPEN:
Failed to boot ok
DEFAULT CATCH!, code=300 @
Can we continue this if you have the time or would you like me to research
something else? Please let me know and I'll hop right in.
Hmm, are you sure the mount command ran in the chrooot - we should have hfs
support in mount.
You can also try this in the chroot
Obviously using /dev/hda2 in the above example
Yes using hmount /dev/hda2 did work
ofboot.b yaboot yaboot.conf
Problem is how to get them off. Trying to mount a usb drive with
mount -t vfat -o /dev/sda1 /mnt/spare1 does not seem to work. Also
even when if I get the usb mounted, how can I copy the files there as
the only way I see them is with the hls command. I can not use the
Created attachment 122435 [details]
Created attachment 122436 [details]
Created attachment 122437 [details]
Is this all the info you needed? What else can I do to keep this thing rolling?
Could I get a little help here? I know that this bug is pretty low on the list
but I would like to get my G3 up and running. It seems that Juan's fix has to do
with how the partitions get laid out on the disk. I have tried manually setting
the disk up with no luck. This is because I'm not sure how that disk partition
and firmware settings tie together. Any assistance would be appreciated.
If you still tracking this problem I hopefully have a few new rinkles.
After checking to see what hardware was specifically on the G3 using the "dev /
ls" command, I noticed that the path listing of the drive was:
/ata-4@0 --------------> looks different from just @?
The boot-device path we have been using was:
/pci@80000000/pci-bridge@d/pci-ata@1/@/disk@0:2,\\yaboot (Is this missing /ata-4@0)
I tried to boot using the added ata-4@0 in place of the @ and received:
3 > boot /pci@80000000/pci-bridge@d/pci-ata@1/ata-4@0/disk@0:2,\\yaboot MAC-PARTS:
LOAD (noninterposed) not supportedload-size=0 adler32=1
can't OPEN pci@80000000/pci-bridge@d/pci-ata@1/@/disk@0:2,
This seems a little bit better than just the can't open failure from post #35.
What I was wondering now is how do I go about changing ofboot.b to get the same
path that I've put into the OpenFirmware? Could it be that FC4 install is simply
getting the incorrect boot device path?
*** Bug 158026 has been marked as a duplicate of this bug. ***
This looks like it's likely to be a bug in ofpath then. Can you tar up
/proc/device-tree and attach that for me please.
Created attachment 125427 [details]
/proc/device from B+W G3 w/ 1 PATA HD + 1 PATA CD drive
[root@g3 ~]# ofpath /dev/hda
[root@g3 ~]# ofpath /dev/hde
ignacio - can you supply a tarball of sysfs. and run
ofpath --debug /dev/hda
Created attachment 125811 [details]
tree output of /sys
I cannot unfortunately; tar is giving me all sorts of grief. I have attached
the output of tree instead; let me know if you need the contents of specific
# ofpath --debug /dev/hda
ofpath: DEBUG: DEVSPEC=/pci@80000000/pci-bridge@d/pci-ata@1
Can you try just /sys/block and /sys/devices
Created attachment 126332 [details]
/sys/block and /sys/devices
Could've sworn I put this on already, sorry.
Has anyone found a solution to the G3 B&W yaboot issue? I just downloaded and installed RH FC/5, and
it's still there. Install seemed to go fine, but yaboot gives me "Unable to open file, Invalid device" etc.
Naturally I don't want to destroy all of my data in the process, but I can if that's the only way.
TIA for any help.
Think I see whats going on here, I had this bug with Fedora 7. Its a G3 B&W.
Just upgraded from core 6. Funny thing was that 6 worked fine.
I would see stage 1, but choosing fedora from the menu would yield second stage
bootloader... then it would just die... after many hours of poking around and
reading this bug and similar ones...
----------- My Open Firmware ------------------------------------
Apple PowerMac1,1 1.f4 BootROM built on 04/09/99 at 13:57:32
Copyright 1994-1999 Apple Computer, Inc.
All Rights Reserved.
0 > printenv boot-device
--------- Partition: common ------- Signature: 0x70 ---------------
boot-device /disk@0:2,\\:tbxi hd:,\\:tbxi
now if I was to do boot /disk@0:2,\\yaboot it would fail from the openfirmware...
then if i tried boot hd:2,\\yaboot it worked...
Now if i boot the rescue disk and mount the hfs partition /dev/sda2... looking
at my ofboot.b ... at this line....
--- snip ---
: bootyaboot " Loading second stage bootstrap..." .printf 100ms load-base
release-load-area " /disk@0:2,\\yaboot" $boot ;
--- snip ---
I changed it to the other reference name of hd:2
--- snip ---
: bootyaboot " Loading second stage bootstrap..." .printf 100ms load-base
release-load-area " hd:2,\\yaboot" $boot ;
--- snip ---
And now my mac boots f7 just fine...
I don't know why this version of OF doesn't like referencing as /disk@0:2 or how
this translates into a fix of yaboot .... but its on the right track
(In reply to comment #55)
> Think I see whats going on here, I had this bug with Fedora 7. Its a G3 B&W.
Holy carp, your suggestion made my B&W actually boot instead of spewing some
version or another of "DEFAULT CATCH!" It looks like there's a workaround:
After the install (but before rebooting!), go to VT2 (the console) and run:
$ chroot /mnt/sysimage
sh-3.2# /sbin/ybin -o hd:2
Lo and behold, there's my Fedora 7 install.
It looks like by default ybin gets the ofboot device name from `ofpath` --
i.e., `ofpath /dev/sda2`. So I'm guessing OF might be what's reporting that as
the device to use (but not honoring it -- thanks guys!). Not sure what to make
Mind, I believe you also have to run ybin again after upgrading your kernel,
else it'll probably blow away your corrected device name.
User email@example.com's account has been closed
Confirmed that ybin -o fixes the boot, and that installing a new kernel breaks
it, and that rerunning ybin -o fixes it again.
(In reply to comment #58)
> Confirmed that ybin -o fixes the boot, and that installing a new kernel breaks
> it, and that rerunning ybin -o fixes it again.
I had this problem, and Paul King's suggestion did fix it. But after deciding
to swap out for a bigger HDD, and expecting a fresh install to run smoothly
(with Paul's little changes) I'm now stuck.
The new install seems to run just fine, but when all the packages are installed
and its time to reboot the system for the 'first time', i get the MacOS
"Question Mark" folder icon, and then the system just boots to OpenFirmware.
I've tried using Paul King's fix at this point, but reboot just gets me the same
I have a G3 B&W, 256m Ram, and trying to install Fedora 8.
Can someone please be more explicit on how to run the ybin -o fix? On a system
thats booting to OpenFirmware? Is there a way to fix this via Linux-Rescue
(which seems to recognize the existing installation)?
(In reply to comment #59)
> Can someone please be more explicit on how to run the ybin -o fix? On a system
> thats booting to OpenFirmware? Is there a way to fix this via Linux-Rescue
> (which seems to recognize the existing installation)?
> Please help.
Did you try Paul King's suggestion from comment #55?
It's worked for me after I forgot to run `ybin -o hd:2` after a kernel upgrade.
Is this bug still present in Fedora 8?
I haven't verified it in 8, but it's certainly still present in 7.
It's definitely still a bug in Fedora 8. Verified on two B&Ws.
Add one more to that list & everything here is not helping. Why is this not on
there known problems. It's just funny that it's taking this long for a fix or
not at all.
Confirmed on core 9. Same problem.
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:
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.