Bug 863892 - f18b tc2 anaconda need to inform the user that he needs to reboot in bios mode or change dialog to 'reclaim disk' (delete msdos partition table and create a gpt one)
f18b tc2 anaconda need to inform the user that he needs to reboot in bios mod...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
18
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Brian Lane
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-07 20:49 EDT by Reartes Guillermo
Modified: 2014-01-07 11:31 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-11-22 22:04:48 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 Reartes Guillermo 2012-10-07 20:49:17 EDT
Description of problem:

This was tested on a DELL E4310 (Laptop)

* The disk has XP installed, there is free (unpartitioned) space in
the disk

* XP uses MSDOS/MBR partition scheme :-)

I booted the laptop in UEFI mode, so F18 anaconda is running in UEFI

* When selecting the disk, anaconda detects that there is free space 
and displays the dialog that 'there is plenty of space to install 
fedora' dialog.

But there are some consequences:

* BOTH the 'AUTOMATIC PARTITIONING' and the 'automatic partition
suggestion' (feature in manual partitioning) will not work.

They will complain (CORRECTLY) the following: "you have not created a 
boot-loader stage1 target device sda6 must have one of the following  
disk-label types: GPT"

Anaconda should have displayed the 'reclaim disk' dialog scenario 
(which would be some form of improved 'reclaim space' dialog, which
can ALSO delete a msdos disk-label and replace it wih a gpt one)

The correct course of action -in this case- is to either:

*1 Reboot in BIOS mode and use such free space. 
   > anaconda should be able to ask the user to do so (in a clear way).

*2 Delete the current (MSDOS) partition table entirely and replace it with a
   GPT one and then either use custom partitionig or manual.
   > anaconda should be able to tell the user that the current partition
     table, -while having free space- is not usable under the current 
     FIRMWARE. If one boots anaconda in UEFI it is assumed -correctly-
     that future intended boots are going to be in UEFI) (the same would
     be for bios).
   > anaconda should then be able to request the user to do that manually
     and in case of automatic partitioning, a special warning that the
     current disk-label will be changed (which might imply a change in 
     used FIRMWARE on some HW).

I will not propose this as a blocker for F18, mostly because this can be 
commented in 'common bugs' or similar documentation somewhere. 

However, it believe that some improvement is needed for F19 cycle to be able
to cope with situations like this and be able to resolve everything from
within anaconda itself (and without any reboot, if possible).

When one boots anaconda in UEFI and the target disk (with might contain
data) is MSDOS partitioned, the provided information by anaconda 
is -currently- insufficient. 

There is a valid error message, but incomplete because an additional
message should inform the user to either boot in BIOS mode or wipe 
the partition table (and erase all data).

Version-Release number of selected component (if applicable):
F18b TC2

How reproducible:
always

Steps to Reproduce:
1. install the other os xp (disk in in MBR
2. boot F18 anaconda in UEFI mode
3. anaconda will recognize the disk as 'with free space' but it will
not be able to use it.
  
Actual results:
the user cannot install
 
Expected results:
anaconda should explain the situation with more detail and (IF POSSIBLE) 
do not consider the disk as 'with free space'.

Additional info:
Comment 1 Fedora Update System 2012-10-31 22:51:56 EDT
anaconda-18.22-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/anaconda-18.22-1.fc18
Comment 2 Fedora Update System 2012-11-01 14:27:45 EDT
Package anaconda-18.22-1.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing anaconda-18.22-1.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-17432/anaconda-18.22-1.fc18
then log in and leave karma (feedback).
Comment 3 Fedora Update System 2012-11-02 00:06:28 EDT
anaconda-18.23-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/anaconda-18.23-1.fc18
Comment 4 Fedora Update System 2012-11-02 21:05:56 EDT
anaconda-18.24-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/anaconda-18.24-1.fc18
Comment 5 Fedora Update System 2012-11-05 20:41:05 EST
anaconda-18.25-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/anaconda-18.25-1.fc18
Comment 6 Fedora Update System 2012-11-06 21:13:09 EST
anaconda-18.26-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/anaconda-18.26-1.fc18
Comment 7 Adam Williamson 2012-11-22 22:04:48 EST
This bug looks to have been fixed for many anaconda builds now but missed being closed. If you find you are still experiencing it with Fedora 18 Beta (RC1) or later, please re-open the bug.

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