User-Agent: Opera/9.80 (Windows NT 5.1) Presto/2.12.388 Version/12.16 Build Identifier: I have two drives with multiple versions of Fedora. One drive has Fedora 16 and fedora 18. The other drive has another copy of Fedora 16 and Fedora 19. Each copy of fedora 16 is labeled with different labels. I'm still using fedora 16 for my main server, hence the duplicate backup on a second drive. Both copies are separately updated. All non-o/s data is stored on a third drive. Fedora 18 is not yet ready to take over the operation, and Fedora 19 fails to run gnome on my system. Also Fedora 19 KDE is unstable, but I boot the system with grub2 under Fedora 19, and I keep grub.cfg current on the Fedora 19 drive for the main boot process. grub2-mkconfig searches all drives and partitions to produce a defective grub.conf. The two copies of the Fedora 16 menuentry sections are not properly distinguished. The second group are infused with the LABELS from the first one. I have partitions labeled fc16b and fc16r on the Fedora 19 boot drive, and partitions labeled 320b1 and 320r2 on the Fedora 16 & 18 drive. grub2-mkconfig replaces 320b1 and 320r2 with fc16b and fc16r respectively, requiring me to hand edit the grub.cfg every time. If I do not change these labels in grub.cfg, the system will boot to the wrong drive even when I have selected the appropriate drive entry. This difficulty has been present in Fedora 16, 17, 18, and 19. Reproducible: Always Steps to Reproduce: 1. Create two copies of fedora 16 (19) on two different drives each in their own partitions with distinct partition labels, on the same computer. 2. On the boot drive run grub2-mkconfig to create a fresh grub.cfg file. 3. Boot on each menuentry separately 4. Run df and note the boot and root devices 5. run ls -al /dev/disk/by-label Actual Results: I kept finding that the labels for the partitions on the non-boot drive were not used in grub.cfg. Both sets of labels matched the labels on the boot drive. Note. Fedora 18, which is on the non-boot drive boots just fine off the non-boot drive. grub2-mkconfig and 30_os-prober "get confused", because somebody probably assumed that there would never be multiple independently maintained copies of Fedora on different drives in the same system. Expected Results: each menu entry boots to its own labels correctly. I should be able to select any the four Fedora installations in the grub2 menu and have it boot correctly without having to edit grub.cfg. System: Intel Celeron 2.93 Ghz, 2 GB memory, one 160GB data drive, one 230GB drive for Fedora 16 & 18, and 1 2TB drive for Fedora 16 (spare) and 19, backups, and more data. behind hardware router in LAN environment - local web server & development.
Output of os-prober ?
Created attachment 796612 [details] output of 30_os-prober with etc/default/grub embedded
Created attachment 796613 [details] The entire buggy grub. This provides the context of 30_os-prober if needed
Created attachment 796614 [details] screen-shot of output during grub2-mkconfig This is the output on the screen when grub2-mkconfig is running (including 30_os-prober).
What is the output from just running "os-prober"?
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. 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. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 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, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. 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.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 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. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.