Suggest that a feature is added to Anaconda to 1. allow the disk bootloader installer to install GRUB to a root partition, as well as 2. use the gptsync utility to handle MBR/GPT hybrid tables. It might also be beneficial it it was possible to flag partitions directly in the partitioner during install. This would greatly help users of Macintosh Intel-based computers to install Fedora on a blank-slate (firmware-only, no data on hard drives) Macintosh, as these otherwise seem to need much extra tweaking (I myself have a Macbook Pro and understand this scenario) and possible reliance on proprietary software (OSX).
What extra tweaking is currently required? I'd like to understand the problem here before we start doing some modifications.
(In reply to comment #1) > What extra tweaking is currently required? I'd like to understand the problem > here before we start doing some modifications. Hi Chris, sorry for the late reply. The ONLY way I have been able to get Fedora to run on my Macbook has been bý using Boot Camp (which should not be necessary at all, see the article below). It appears that trying redirect the boot process to hand the reins over to GRUB is not working any other way (the system simply tells me it cannot find a bootable device, or simply gives me a black screen with a flickering cursor). This article gives some good pointers on how this could be resolved, but it has not worked on my side: http://www.tuxation.com/linux-on-mac.html I need some info here: does formatting a given partition in Anaconda remove any flags on that partition? For example: assume I use a live version of Fedora (which I have succesfully managed to do), and run parted to flag a partition as "boot". I then try to boot an install dvd of Fedora, and when setting up the disc, I format that partition as "/", but with another file system. Would this kill the boot flag? In light of the above, it appears that the core of the problem is in the EFI of the Mac, which apparently looks for the boot loader in the wrong place. I am not sure how Boot Camp works around this, but if we only could try and install GRUB somewhere else during install, it could very well be solved. As a reference, I believe the OpenSUSE 11.1 installer allows such installs. Sadly, I cannot even run that installation on the Mac due to a silly systime-check on the SUSE dvd which aborts the installation.
(In reply to comment #1) > What extra tweaking is currently required? I'd like to understand the problem > here before we start doing some modifications. Addition to last post: I forgot to point out my platform, we can use it as a reference: Macbook Pro 1.1 (2006) Intel Dual Core 2.16 (not Core 2 Duo) 2 GB DDR2 667Mhz ATI X1600, 256MB As mentioned in the article I supplied before, Macs differ from PC:s as they use EFI instead of an ordinary BIOS. They also use firmware, but I dont believe the firmware itself is the root of the problem.
Jeremy - you mentioned the other day that we used to take care of the problems in this bug. Could you refresh my memory on what those fixes are so I can bring them back into the new storage code?
It looks like the old commits were e16aec2d0892f391da7cfb8d2474602b5e924698 and 43567ab91550fe33b2c8a7b0e6bd4ea595f79fbf
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
*** Bug 505128 has been marked as a duplicate of this bug. ***
*** Bug 505817 has been marked as a duplicate of this bug. ***
In the preupgrade/anaconda place, simply leaving the partition table alone if no alterations are specified would be a big help. Current F10->F11 upgrades leave an unbootable system until gptsync is run, but I'm unaware of a need to alter the partition table in that case.
*** Bug 521527 has been marked as a duplicate of this bug. ***
For the record, the following steps allowed me to install Fedora 11 on my MacBook aluminum. I have no Mac OS X install, just Fedora, directly on a MSDOS partition table on the laptop's disk. 1. Install Fedora x86_64 using network install CD. 2. Provide the kernel with the "text" argument. 3. Early in the install process (as soon as a command prompt is provided on a VT), use parted to create an msdos partition table on the disk. 4. Add to the kernel command line: vga=0x318 all_generic_ide (to allow DVD's to play) 5. After the install is done, boot using the DVD and run "grub-install /dev/sda."
*** Bug 525765 has been marked as a duplicate of this bug. ***
(In reply to comment #11) > For the record, the following steps allowed me to install Fedora 11 on my > MacBook aluminum. I have no Mac OS X install, just Fedora, directly on a MSDOS > partition table on the laptop's disk. Really an MSDOS parttable or an vfat partition? AFAIK it is necessary to have an fat32 partition containing all that efi.bin stuff, so i wonder if you got it to work without an fat32 partition or if anacoda created it ...
> > For the record, the following steps allowed me to install Fedora 11 on my > > MacBook aluminum. I have no Mac OS X install, just Fedora, directly on a MSDOS > > partition table on the laptop's disk. > Really an MSDOS parttable or an vfat partition? > > AFAIK it is necessary to have an fat32 partition containing all that efi.bin > stuff, so i wonder if you got it to work without an fat32 partition or if > anacoda created it ... An MSDOS partition label: (parted) print Model: ATA FUJITSU MHZ2250B (scsi) Disk /dev/sda: 250GB Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 32.3kB 210MB 210MB primary ext3 boot 2 210MB 250GB 250GB primary lvm Here is my grub.conf: default=0 timeout=0 splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu title Fedora (2.6.31.1-56.fc12.x86_64) root (hd0,0) kernel /vmlinuz-2.6.31.1-56.fc12.x86_64 ro root=/dev/mapper/VolGroup-lv_root quiet vga=0x318 all_generic_ide SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us initrd /initramfs-2.6.31.1-56.fc12.x86_64.img title Fedora (2.6.31.1-48.fc12.x86_64) root (hd0,0) kernel /vmlinuz-2.6.31.1-48.fc12.x86_64 ro root=/dev/mapper/VolGroup-lv_root quiet vga=0x318 all_generic_ide SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us initrd /initramfs-2.6.31.1-48.fc12.x86_64.img title Fedora (2.6.31-40.fc12.x86_64) root (hd0,0) kernel /vmlinuz-2.6.31-40.fc12.x86_64 ro root=/dev/mapper/VolGroup-lv_root quiet vga=0x318 all_generic_ide SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us initrd /initramfs-2.6.31-40.fc12.x86_64.img
I suppose you have got bootcamp installed? The correct way would be to use an gpt pt, with an fat16 partition, holindg the efi stuff an don some secondary partitions fedora.
> I suppose you have got bootcamp installed? > > The correct way would be to use an gpt pt, with an fat16 partition, holindg the > efi stuff an don some secondary partitions fedora. No Bootcamp. No Mac OS X. No Apple software or EFI stuff on the hard drive. Just Fedora. It works for me with the notes in comment #11. I added this configuration to this bug report as a reference.
This was discussed at the blocker review meeting today. It can't block the release, it's a feature request that was not put on the official feature list, and you _can_ install to these machines per comment #11. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
This is not a feature request. This is a bug report to fix booting issues on machines that used to work but haven't since the storage rewrite. Comment #11 is a hack all the way around, especially since it mentions text mode installation which we don't even recommend or particularly want people to use.
Also, comment #1 specifies a blank-slate machine, which isn't the common situation. I think something was lost when this bug got spun off from the other one. We used to be able to install to a partition on a GPT disk, leaving the other OS'es alone. This worked through Fedora 10.
chris: ah, it wasn't clear that this was something that worked okay before the storage rewrite, I understood that it had never really worked this way. still, would this be a big change to land after beta? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
FYI, bug 194001 was the original (in F6), before the storage rewrite regression.
*** Bug 530654 has been marked as a duplicate of this bug. ***
*** Bug 547976 has been marked as a duplicate of this bug. ***
Just copying over some info from 547976: The install fails *with bootcamp installed*. Syncing the mbr using refit didn't help. Reinstalling grub to /dev/sda3 failed. I managed to install ubuntu, but it uses grub2 so it is hard to see what it is doing different.
The situation just got worse with Fedora 12. Once I finish installing Fedora on my rEFIt + MacOSX system with GRUB installed on /dev/sda3 (not the MBR), Fedora fails to boot (as before with F11). However this time running gptsync does not retrieve the situation and the kernel just panics. I have tried this twice (the second time with the updates repository enabled) and the result is the same. I had initially filed the bug about the problems with F11 at: https://bugzilla.redhat.com/505817 which got marked as a duplicate of this bug.
FWIW, I can't get my brand new macbook pro 5,3 w/ rEFIt to even boot either the x64 Live CD or x64 Install DVD. The Install DVD isn't even recognized (i checked the sha and burned twice, i'm pretty sure the disc is ok), and attempting to boot the Live CD just drops me directly into a GRUB prompt, and I can't do anything from there.
In same boat with intel macmini2,1. Since F10, nada. Now trying to get F12 up. Agree with #18 that this is a bug, not a feature of the rewrite. Using gpt partitions from 10.6, f12 unity respins of x86 and x86/64, no boot camp no refit. default installs don't work, can't even get a boot disk with option at boot, but gptsync will get the boot partition, but selecting it leads to blank screen with blinking cursor. note that karmic does work on this hardware. The partitions that comes up with are much different than fedora: (parted) p Model: ATA Hitachi HTS54168 (scsi) Disk /dev/sda: 80.0GB Sector size (logical/physical): 512B/512B Partition Table: gpt Number Start End Size File system Name Flags 1 20.5kB 210MB 210MB fat32 EFI System Partition boot 2 210MB 40.1GB 39.9GB hfs+ mac 3 40.1GB 40.1GB 1000kB bios_grub 5 40.1GB 76.4GB 36.3GB ext4 6 76.4GB 78.0GB 1603MB linux-swap(v1) this boots. what is bios_grub and how can I get grub installed there for f12?
Well, this is how I got Fedora 12 too boot: http://debarshiray.wordpress.com/2010/01/15/fedora-11-12-on-an-intel-macbook-getting-it-to-boot/
I was able to get Fedora 12 to *start* to boot via a Live image on USB drive, however the installer always freezes after a graphical glitch almost immediately after booting into it (after the text-mode progress bar). I tried various workaround kernel/boot options regarding text mode and VGA driver. No go. I don't want to nuke my OS X partition, so I guess I'll just wait until there is a real solution.
From: http://www.gnu.org/software/parted/manual/parted.html ‘bios_grub’ (GPT) - Enable this to record that the selected partition is a GRUB BIOS partition.
bios_grub is only in grub2, which fedora is not using. So no wonder.
*** Bug 579826 has been marked as a duplicate of this bug. ***
Update for f13b, live 86_64. On install, get error: The following errors occurred with your partitioning: sda must havea MSDOS disk label This can happen if there is not enough space on your hard drive(s) for the installation. Press 'OK' to choose a different partitioning option. Only choice, really, and from there we get back to the "Which type of installation would you like" page, on which "replace existing linux systems" is firmly checked.
*** Bug 582398 has been marked as a duplicate of this bug. ***
(In reply to comment #33) > Update for f13b, live 86_64. On install, get error: > > The following errors occurred with your partitioning: > sda must havea MSDOS disk label Is it appropriate that you should need an msdos disklabel on the boot disk? I think that translates to "have you configured your system to boot through the BIOS?" > > Only choice, really, and from there we get back to the "Which type of > installation would you like" page, on which "replace existing linux systems" is > firmly checked. I'm working on a change that will almost certainly NOT make F13, which will create the appropriate type of disklabel on the boot disk IFF you have selected "Use All Space".
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. 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 '11'. 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 11'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 11 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
I managed to install F13. It is not nice, but it works: * Install as normal * In the rEfit menu, sync the partition tables * Boot the dvd in rescue mode * chroot * rpm -e grub * yum install grub2 * grub2-config > /boot/grub2/grub.conf * grub2-install /dev/sda3 --force * cd /boot * rm -rf grub * ln -s grub2 grub I am not sure if all those steps are necessary, but they worked for me.
For years I'm a single-boot user. Is it still required to install rEFIt? The above procedure seems awkward, why do we need to install grub2?
The above procedure was for keeping a dual boot system. I single boot might be simpler. I needed to install grub2 because grub fails :-) I don't know exactly why, but both the regular install and running grub-install /dev/sda3 fails.
*** Bug 597317 has been marked as a duplicate of this bug. ***
My system is still dual boot (Mac OS X / F13) as well. I only need(ed) to sync partition tables with refit to make it work. Grub works just fine from /dev/sda3.
Maybe the issue is where /dev/sda3 starts? Mine starts at 1.5T.
I changed this From F11 to F13. Is there a boot option to use grub2 instead of grub? That would be useful for testing #38, and for the grub2 transition.
*** Bug 604488 has been marked as a duplicate of this bug. ***
-- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Updating. I have a successful dual-boot install on a mac mini with snow leopard 10.6/F13 x86_64, although this is kind of a workaround as I didn't do partitioning in linux. Here's what I did: 1) wipe drive in os x. So, you have to use the internal drive as booting from an external drive (be it flash, usb, firewire) is dicey. So, go utitlities->Disk Utility and select drive to work on. You want a GUID partition for the mac side, and a second partition of type "Free Space" as partition two. Do it now, reboot. 2) in a linux live disk, clear out the MBR if necessary. This is symptomatic of past failed Fedora installs that installed the boot loader onto the MBR instead of the linux boot partition. Symptoms include refit finding too many linux partitions in the graphical boot, or truncated GRUB boots like GRU at boot time. Verify this with refit Partition Inspector utility http://refit.sourceforge.net/help/windows_boots_linux.html if it says: MBR contents, GRUB then you need to do this: dd if=/dev/zero of=/dev/sda bs=446 count=1 from http://www.linuxquestions.org/questions/linux-software-2/using-linuxs-fdisk-to-erase-or-fix-a-mbr-300256/ 3) in linux install, install on free space only, put boot loader on sda3 or whatever, not MBR. FYI /boot partition can be ext4. Looks like: 1 20.5kB 210MB 210MB fat32 boot, hidden 2 210MB 40.1GB 39.9GB hfs+ mac hidden 3 40.1GB 40.6GB 524MB ext4 boot 4 40.6GB 80.0GB 39.4GB lvm 4) restart, in refit menu sync MBR, restart. Select "Windows" and that will boot fedora. At this point I believe refit is optional. tried this with f14 alpha x86_64 live, and f13 x86_64 dvd install, worked in both
*** Bug 640133 has been marked as a duplicate of this bug. ***
*** Bug 641531 has been marked as a duplicate of this bug. ***
Very similar issue with f14. This time I was able to use the live cd in vesa mode, but still had to do the same steps as before: * sync gpt/mbr * install grub2
Somehow I managed to get F14 working on a MacBook Pro 2,1 with some, but not too much magic. But F15 has me totally stumped. I have tried both the methods of c38 (https://bugzilla.redhat.com/show_bug.cgi?id=503149#c38) and c47 (https://bugzilla.redhat.com/show_bug.cgi?id=503149#c47), and neither has worked for me. Even getting to the point where I could boot to the installer from the DVD required the -no-emul-boot, but that's not Very Hard, as I was able to do it. When I attempt to boot my freshly installed, refit-sync'd F15 setup (boot on sda3, lvm on sda4), I get to the grey refit penguin splash screen and that's as far as it goes. I have tried everything I've ever done to make Fedora happy on this ancient MacBook Pro, and absolutely nothing is working. Should I file a fresh bug report, or is this really part of the same chain of problems--that Anaconda is ultimately not presenting reasonable options for the user to choose?
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. 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 '13'. 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 13'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 13 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
I think we should keep this open as installing on/booting macs still has some issues.
I should say that I no longer have the macbook, so to be fair this is no longer relevant for me (although I still think it would be great to have Fedora running on these machines).
(In reply to comment #53) > I think we should keep this open as installing on/booting macs still has some > issues. Maybe those issues could be described more in detail in a fresh bug entry? This bug seems to be very general.
The problem occurs when the user chooses an installation type that requires the GPT to be updated. Any addition or subtraction of any partition to GPT causes an existing hybrid MBR to be blown away in favor of a protective MBR. And then I will guess that gptsync isn't being called to create an updated MBR so that the computer is then bootable. I'm finding that Apple's CSM appears to expect three things exactly, for a partition to show up in the startup disk selection menu, revealed with option-key @ powerup/restart: 1. code in the first 440 bytes of the disk 2. hybrid MBR or full MBR (no GPT); i.e. not a protective MBR 3. the partition for booting marked as bootable in the MBR. On a Macbook Pro 8,2 I just tried changing the hybrid MBR to protective MBR, and making that single partition entry, MBR hex EE, bootable. The result was that neither Mac OS nor Fedora boot volumes were displayed in the option key startup disk menu. Restoring the hybrid MBR with linux boot partition set as bootable in the MBR. (It may be Apple's EFI startup disk boot menu only looks for the boot flag being set on a partition other than MBR hex EE, I haven't tried setting some arbitrary non-bootable partition with the boot flag. I suspect it would be "good enough" for EFI to proceed with initiating the CSM, which then behaves just like BIOS - blindly reads the first 440 bytes, and at that point control is handed to Grub regardless of what boot flag is set. BUT I haven't tested this.) The GPT "Legacy BIOS Boot" flag is apparently ignored by Apple's EFI startup disk boot menu, as such a disk with only protective MBR, but with the boot partition's attribute set to "Legacy BIOS Boot" in GPT does not apparently alter any behavior. Sad, because this would be a great way to avoid hybrid MBR, and at least in my imagination is expressly why that attribute exists. Conclusion: Presently, whether installing Fedora 16 beta either with "Use Free Space" or "Use All Space" installation types (dual boot Mac OS + Fedora, or single boot Fedora only), the resulting installation is not immediately bootable. It does not appear as an option in the Apple startup disk boot menu (option key). After creating the hybrid MBR, it appears as "Windows" (technically that "Windows" option is for Grub in this context, not a command to boot from a specific partition) I found some related issues and put them in this bug report: http://bugzilla.redhat.com/show_bug.cgi?id=744496
Failed to complete a thought... "Restoring the hybrid MBR with linux boot partition set as bootable in the MBR." Doing this restored the dual boot ability from the Apple startup disk menu selector. So the things I think need to be fixed, other than the LiveCD installing boot loader failure that occurs when there is a previous system (Mac OS in that case) since that already has its own bug ID: a.) linux boot partitions need to be set to the correct GUID, presently they're getting an EFI Partition GUID instead of a linux system GUID, which means on Apple computers with a pre-existing Mac OS with users intending to create a dual boot computer, end up with *two* EFI Partitions on the same disk. (Mentioned in the above bug ID but is probably unrelated to that problem; and also doesn't affect bootability of linux or Mac OS.) b.) Something needs to create an appropriate hybrid MBR post-install. c.) Something needs to set, in that MBR, one of the partition's boot flag, post-install. It may not matter which as long as it's not the EFI Partition, I can vouch for setting the linux boot (mounting on /boot) as bootable in the MBR. That works. But I suspect any of the three partitions in the MBR could be flagged bootable. Also, in all of my testing I am not using rEFIt, or gptsync. Only gdisk 0.7.2. And I only choose the boot disk from the built-in startup disk boot menu, accessed by holding the option key down at startup.
Additional booting tests: 1. I do not think it's appropriate to assume the user has, or should have, rEFIt. The correct behavior should produce a bootable disk from the Apple startup disk menu (option key at startup). This will also work with rEFIt. 2. On a MBP 4,1 with Lion and Fedora 16beta (total of 6 partitions) I found I can get two additional successful configurations to the one previously described: a.) Instead of linux boot partition marked bootable, mark linux lvm bootable (yet it is not, there is no boot partition within that LVM). b.) Instead of the linux boot partition and linux lvm partition separately listed in the MBR (with the remaining partitions in the protected MBR); place the linux boot partition also in the protected MBR, with the linux lvm (as the 2nd MBR partition) marked bootable. And this is reproducible on a Macbook Pro 8,2 as well so it appears to be pretty consistent. All of this is different for EFI booting. So far I'm assuming CSM mode based booting.
This might need a separate bug report but I'll stick it in here for now. Consistently I'm finding the partition type GUID is wrong in a number of cases: The first ext4 partition listed in GPT (whether it's the 2nd partition entry or the 5th) is thus far always the GUID for "EFI System Partition" GUID C12A7328-F81F-11D2-BA4B-00A0C93EC93B. This is definitely incorrect, it should be GUID 0FC63DAF-8483-4772-8E79-3D69D8477DE4 "Linux filesystem". The net result of this bug is that there are two EFI System Partitions on a dual boot system, one of which is the real EFI System partition, and the other is the partition mounting as /boot. Probably not a good idea, should be fixed. Subsequent partitions either ext4, btrfs, or xfs have partition type GUID EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 "Microsoft Windows basic data". This was done for a long time under MBR, using the same partition type hex code as Windows but linux filesystems have their own GUID which is 0FC63DAF-8483-4772-8E79-3D69D8477DE4. So it's a minor point, but ought to be fixed. "BIOS Boot" has the correct partition type GUID. "Linux LVM" partitions also have the correct partition type GUID. Last, all of my comments apply to F16 beta, so the version for this bug should be changed to 16. Now that I've inundated everyone with multiple comments, I'll remove the needinfo flag and await comments/questions on next steps.
http://lists.gnu.org/archive/html/bug-parted/2011-06/msg00045.html If anaconda is using parted to create/modify partitions, I think this is what's occurring. Anaconda is incorrectly setting the 'boot' flag for /boot partitions, which then causes the partition type GUID to be set to "EFI System" partition.
Chris, I think we're getting confused by volume and crossover between this report and https://bugzilla.redhat.com/show_bug.cgi?id=744496 . Can you please separate out each individual issue you've found and file a new bug report, with a comprehensive description and recommended fix in a *single* description post, for each issue? I think that'll make it much easier for the anaconda team to fix the problems you've identified. Please link all the bugs from both this bug and 744496. Thanks!
Linux boot GUID problem moved to Bug 746895. Lack of MBR with boot flagged partition problem moved to Bug 746901. This bug 503149 can be considered a duplicate of Bug 746901.
is it a dupe of that bug _as this bug is initially reported_ - i.e. "Suggest that a feature is added to Anaconda to 1. allow the disk bootloader installer to install GRUB to a root partition, as well as 2. use the gptsync utility to handle MBR/GPT hybrid tables." ?
Now I understand this a bit better, yes, it is effectively a duplicate of that bug. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers *** This bug has been marked as a duplicate of bug 746901 ***