Bug 874562

Summary: Anaconda doesn't tell what is wrong on partitioning
Product: [Fedora] Fedora Reporter: Pavel Holica <pholica>
Component: anacondaAssignee: Anaconda Maintenance Team <anaconda-maint-list>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 18CC: anaconda-maint-list, g.kaviyarasu, jonathan, mbanas, robatino, sbueno, vanmeeuwen+fedora
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-11-08 11:15:10 EST Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 752661    
Description Flags
Error checking storage configuration screenshot
storage.log none

Description Pavel Holica 2012-11-08 08:06:25 EST
Created attachment 640794 [details]
Error checking storage configuration screenshot

Description of problem:
When incorrect partitioning is specified, anaconda allows to click on "Finish partitioning" and doesn't complain about anything. Then, in hub, there is only information "Error checking storage configuration" which doesn't tell what is wrong and can be confusing.

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

How reproducible:

Steps to Reproduce:
1. Get to partitioning and do manual configuration
2. Set / to be "vfat" for example
3. click on "Finish partitioning"
Actual results:
see attachment

Expected results:
Anaconda should tell (like on Fedora 17 did) what is wrong with the partitioning layout.

Additional info:
Comment 1 Pavel Holica 2012-11-08 08:22:51 EST
Created attachment 640806 [details]
Comment 2 Pavel Holica 2012-11-08 08:23:14 EST
Created attachment 640807 [details]
Comment 3 Pavel Holica 2012-11-08 08:23:37 EST
Created attachment 640808 [details]
Comment 4 Chris Lumens 2012-11-08 11:15:10 EST
Yeah, this is just a difference in the new installer design.  You'll need to revisit the storage spoke and then it should be fairly obvious what the problem is.

We are trying to prevent people from getting locked into spokes, and to allow people to do other stuff while checks are running.  That's why you are sent back to the hub while storage sanity check runs, and why you have to go back into the spoke to see the detailed errors later.