Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 840272 - grub2 should not install entries for hidden partituions
grub2 should not install entries for hidden partituions
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: grub2 (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Peter Jones
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-07-15 05:09 EDT by Stéphane Téletchéa
Modified: 2015-02-17 09:21 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-02-17 09:21:10 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Stéphane Téletchéa 2012-07-15 05:09:54 EDT
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
Comment 1 Mads Kiilerich 2012-07-31 15:29:04 EDT
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?
Comment 2 Stéphane Téletchéa 2012-07-31 16:11:23 EDT
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
Comment 3 Mads Kiilerich 2012-08-03 08:41:49 EDT
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.
Comment 4 Hedayat Vatankhah 2012-08-04 10:18:13 EDT
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?
Comment 5 Mads Kiilerich 2012-08-04 19:16:56 EDT
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.)
Comment 6 Hedayat Vatankhah 2012-08-05 07:47:35 EDT
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.
Comment 7 Stéphane Téletchéa 2012-08-06 09:36:31 EDT
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...
Comment 8 Hedayat Vatankhah 2012-08-06 11:49:52 EDT
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.
Comment 9 Fedora End Of Life 2013-07-03 22:38:56 EDT
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.
Comment 10 Stéphane Téletchéa 2013-07-04 08:52:32 EDT
I have updated the status, this stands true for Fedora 19 too...
Comment 11 Fedora End Of Life 2015-01-09 12:15:39 EST
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.
Comment 12 Fedora End Of Life 2015-02-17 09:21:10 EST
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.

Note You need to log in before you can comment on or make changes to this bug.