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): How reproducible: Always 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. Additional info:
*** 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 world' mac. 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' regards, j.dwyer
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 (type :tbxi). 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 Thing; (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 boot=/dev/sda1 init-message=Welcome to Fedora Core\! Hit <TAB> for boot options partition=2 timeout=80 install=/usr/lib/yaboot/yaboot delay=5 enablecdboot enableofboot enablenetboot magicboot=/usr/lib/yaboot/ofboot image=/vmlinuz-2.6.11-1.1369_FC4 label=linux read-only initrd=/initrd-2.6.11-1.1369_FC4.img root=/dev/VolGroup00/LogVol00 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 line. 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. Thanks, Juan Casero
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 Thanks
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 processor :0 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. Thanks, Juan
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 early. Thanks, Juan
Created attachment 119408 [details] Anaconda log
Created attachment 119409 [details] Anaconda syslog
Created attachment 119410 [details] Anaconda xlog
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 problem. Thanks, Juan
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. Juan
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 fix.
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 reboot. Juan
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 ppc.
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. Thanks, John C.
John - thanks for the offer. Can you boot into OF (Cmd Option OF at boot) and do: printenv boot-device 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.
Paul, Couple things. 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? Thanks, John C.
Paul, Took me a few to figure out you were referring to the MAC keyboard. Here is the output. 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. OpenFirmware 3.1.1 To continue booting, type âmac-bootâ and press return. To shut down, type âshut-downâ and press return. ok 3 > ok 3 > printenv boot-device ----------------Partition: common -------- Signature: 0x70 ----------------- boot-device /pci@80000000/pci-bridge@d/pci-ata@1/@/disk@0:2,\\:tbxi hd:,\\:tbxi John C.
Paul, Hereâs my disk info: parted Using /dev/hda (parted) print 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 (parted)
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: chroot /mnt/sysimage Please give me the output of the following two commands: ofpath /dev/hda ofpathname /dev/hda mkdir /mnt/spare 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 boot /pci@80000000/pci-bridge@d/pci-ata@1/@/disk@0:2,\yaboot Thanks in advance
Here are the command outputs (what there is): chroot /mnt/sysimage ofpath /dev/hda /pci@80000000/pci-bridge@d/pci-ata@1/@/disk@0: ofpathname /dev/hda 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: /pci@80000000/pci-bridge@d/pci-ata@1/@/disk@0:2,\\:tbxi Failed to boot ok 0 > DEFAULT CATCH!, code=300 @
Paul, 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. Thanks, John C.
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 hmount /dev/sda2 hls
Obviously using /dev/hda2 in the above example
Paul, Yes using hmount /dev/hda2 did work hls shows 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 copy command. Thanks, John C.
Created attachment 122435 [details] ofboot.b
Created attachment 122436 [details] yaboot
Created attachment 122437 [details] yaboot.conf
Paul, Is this all the info you needed? What else can I do to keep this thing rolling? John C.
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. John C.
Paul, 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: pci@80000000 /pci-bridge@d /pci-ata@1 /ata-4@0 --------------> looks different from just @? /disk@0 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? Thanks, John C.
*** 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 As requested. [root@g3 ~]# ofpath /dev/hda /pci@80000000/pci-bridge@d/pci-ata@1/@0/disk@0: [root@g3 ~]# ofpath /dev/hde /pci@80000000/pci-bridge@d/mac-io@5/ata-3@20000/disk@0:
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 files. # ofpath --debug /dev/hda ofpath: DEBUG: DEVSPEC=/pci@80000000/pci-bridge@d/pci-ata@1 /pci@80000000/pci-bridge@d/pci-ata@1/@0/disk@0:
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. ~Ben
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. OpenFirmware 3.1.1 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 of that. 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 pnasrat'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 result. 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)? Please help. thanks.
(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. > thanks. Did you try Paul King's suggestion from comment #55? boot hd:2,\\yaboot 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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
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.