By default, grub2 lists ans adds an entry for every partition it founds. However a lot of computer come with an hidden partition for restoring windows (and others?). If the user selects it without paying enough attention, its windows, linux, and data will be wiped out ... This is really dangerous to present "hidden" partitions to users, and should be reserved to experts not to every average joe. Solution: skip hidden partitions, a beginning of the solution can be seen here: http://www.linuxquestions.org/questions/linux-software-2/grub2-skipping-one-partition-from-os-detection-741100/#post4686645
In what way is the recovery partition hidden? Isn't it just that it isn't the default partition ... and that the BIOS perhaps has an option for booting into it without using the boot loader? Being able to boot into the recovery partition is in general a nice and necessary feature. (If the recovery partition wipes the drive without asking for confirmation then it is really a firmware bug ...) If there are some partition types that never should be added to the bootloader (perhaps because they can be booted from some BIOS option) then I think it would be better to blacklist them in os-prober (which is the tool grub rely on for this purpose). If that is the case then I think the output of "fdisk -l" and "blkid" would be helpful. But the simplest way to disable these entries is by setting /etc/default/grub GRUB_DISABLE_OS_PROBER=true Isn't that the solution you are asking for?
Well, on most laptops this "hidden" partition is available from a combination of keys displayed in the manual or during BIOS. For instance on my system: [root@presquelabo ~]# fdisk -l Disk /dev/sda: 250.1 GB, 250059350016 bytes 255 heads, 63 sectors/track, 30401 cylinders, total 488397168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x23c52053 Device Boot Start End Blocks Id System /dev/sda1 2048 16386047 8192000 1c Hidden W95 FAT32 (LBA) /dev/sda2 * 16386048 436471807 210042880 7 HPFS/NTFS/exFAT /dev/sda3 436471808 442923007 3225600 82 Linux swap / Solaris /dev/sda4 442923008 488397167 22737080 5 Extended /dev/sda5 442925056 488396799 22735872 83 Linux The partition with the "hidden" status should not be available in grub default menu, but you are right, this belongs more to os-prober than grub itseld, do I need to report it separately on "os-prober"? Of course, everyone should take care while booting on this, and hopefully there is a confirmation demand *before* the recovery tool is launched, but since the partition has the "hidden" status, it should be skipped without confirmation or at best presented in an "advanced" menu, otherwise the users not really aware of this "feature" could "damage" their computer with this entry. For the record, bklid reports: [root@presquelabo ~]# blkid /dev/sda1: LABEL="RECOVERY" UUID="1489-5F00" TYPE="vfat" /dev/sda2: LABEL="VistaOS" UUID="56FA82DAFA82B631" TYPE="ntfs" /dev/sda3: UUID="06588dc7-6ccf-4221-8a1d-a4e51dd57d1b" TYPE="swap" /dev/sda5: LABEL="_Fedora-17-x86_6" UUID="2fb9c838-98a2-42f8-ab5c-e8b1f6e44c02" TYPE="ext4" I'm not sure if the "RECOVERY" label is trustworthy but the "hidden" status is, being an ancient QA employee at Mandriva and doing bug triage and reports for years (hello AdamW btw, if you read the report also :-). Please tell me if more input is needed. Stef
Agreed, it could make sense not to show partitions with 'hidden' types. (I have a de "Dell Utility" partition which I am fine with having in the boot menu.) But I'm also sure that there are someone out there that like to have their 'hidden' partitions in the boot menu ... os-prober do AFAICS not use partition types. You can try to add 'set -x' to line 5 of /usr/libexec/os-probes/mounted/30utility and run os-prober and see what is going on and propose a method that would work better for you. (You haven't told what kind of boot entry it creates (or shown os-prober output). It is possible that the entry is created by 20microsoft instead.) Reassigning to os-prober.
Yes, os-prober does not look at partition types. It looks inside the partitions. Usually, for recovery partitions it can find an appropriate title in the partition's Windows configuration (e.g. in my laptop, the grub entry is titled: "Windows Recovery Environment"), which should be OK I think. Personally, I'm against hiding recovery partitions from grub menu because on some systems (like my laptop), this will be usually the only way to boot into the recovery partition (Originally, the recovery system will be enabled by pressing a special key when system is booted. However, it doesn't work anymore after installing grub into MBR since the code which loads the recovery environment lives in MBR. So, IMHO the entry for hidden partitions must be detected by os-prober by default. However, moving the entry to the advanced menu is a good suggestion. But I'm not sure how it can be done, and if it can be fixed in os-prober. Probably it should be fixed in Grub2's os-prober detection code (/etc/grub.d/30_os-prober). What do you think?
Hedayat, just to understand your case: what partition type is your recovery partition and what os-prober output do you get on your laptop? It is possible that it would make sense if grub placed recovery partitions in the advanced section (or made it super easy to password protect them). But how should grub know which partitions that are recovery partitions? How can it recognize them in os-prober output? (I guess grub2 soon will have to include its own code for detection instead of using os-prober; it seems like there is a need for an API between these two components that are so complex that it no longer is feasible to keep and maintain them separately.)
os-prober output: # os-prober /dev/sda1:Windows Recovery Environment (loader):Windows:chain /dev/sda2:Windows Vista (loader):Windows1:chain /dev/mapper/VolGroupLaptop-lvfedora16:Parsidora release 16 (Parsidora):Fedora:linux And partition type according to fdisk: /dev/sda1, Id=27, System=Hidden NTFS WinRE Two workarounds for grub I can think of: 1. if it detects unusual words in title such as Recovery and Environment 2. looking at the partition type, any unusual(non-FAT and non-NTFS, and newer FAT filesystem (exFat?!) ) partition type for Windows could be considered as a recovery partition. Merging os-prober with grub2 might be good anyway, but in this case it might be unnecessary. Currently, os-prober ignores partition types completely, so code related to partition types can reside in grub2.
My os-prober: [root@presquelabo ~]# os-prober No volume groups found /dev/sda1:Windows Recovery Environment (loader):Windows:chain /dev/sda2:Windows Vista (loader):Windows1:chain For hiding the partition, or at least not showing it in a "normal" entry rather in an "advanced" mode since GRUB 2 permits it, the "hidden" vfat status can be used securely, instead of parsing what could be a "Recovery" label...
This should be handled in grub2, os-prober has no way to tell grub2 where it should put the menu entries. os-prober's job is to detect OSes, which it does. So I suggest changing the component back to grub2.
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. 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 '17'. 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 17'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 17 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 to Fedora 17's end of life. 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.
I have updated the status, this stands true for Fedora 19 too...
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.