Bug 868559

Summary: root partition (/) size validation is weak (the user can start the installation process with just a 1mb / partition leading to a complete freeze of the installer environment)
Product: [Fedora] Fedora Reporter: Reartes Guillermo <rtguille>
Component: anacondaAssignee: David Lehman <dlehman>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 18CC: awilliam, g.kaviyarasu, jonathan, vanmeeuwen+fedora
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: anaconda-18.37.1-1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-05-10 03:46:28 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
screenshot that shows that STORAGE: INSTALLATION DESTINATION is not "alarmed"
none
storage.log none

Description Reartes Guillermo 2012-10-20 20:11:13 UTC 
Description of problem:

Currently, in manual partitioning, anaconda let's the user start the installation process by just creating 1mb / partition. This leads to 
a freeze of the whole installation environment. By 'complete' i mean
that not even switching to another vt works, either xorg or the
kernel are frozen.

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

How reproducible:
always

Steps to Reproduce:
1. go to storage, select one disk, remove all partitions
2. create a 0mb / partition, it will be rounded to 1mb :-)
3. press finish partitioning and return to the main hub
4. start installation.
5. the environment will freeze, switching to another VT will not work,
complete freeze.

  
Actual results:
frozen installation environment (complete) (anaconda/xorg/kernel)

Expected results:
an error message, since the intended action does not make sense. the / partition is so small than not even the kernel would fit in it. :-)

Additional info:
when doing this with multiple selected disk, the 1mb partition might be created on the second or other disk.
Comment 1 Reartes Guillermo 2012-12-07 22:29:31 UTC 
tested with: 20121205_f18-smoke4 (netinstall)

1. Go to STORAGE: INSTALLATION DESTINATION, select one disk.
2. Select 'I don't need...' for AUTOMATIC PARTITIONING.
3. Remove all partitions shown in manual partitioning.
4. Create a 0mb / partition, it will be rounded to 1mb :-)
5. Press 'Finish Partitioning' and return to the main hub.

It is no longer possible to start installing. That is OK!.
"Error checking storage configuration" message is shown, which is ok.

I tried 2 different guest without this issue.

So, it appears that the bug-report can be closed.
Comment 2 Reartes Guillermo 2013-01-04 13:22:17 UTC 
Created attachment 672404 [details]
screenshot that shows that STORAGE: INSTALLATION DESTINATION is not "alarmed"

With F18 TC4 (18.37.8) anaconda no longer appears to reject the storage configuration, because STORAGE: INSTALLATION DESTINATION is not alarmed.

Good:
* It is still not possible to start installing
* A yellow banner in the main hub print an error that suggest an incorrect partitioning choice done by the user.

Bad: 
* STORAGE: INSTALLATION DESTINATION is not alarmed. (no exclamation mark)
Comment 3 Reartes Guillermo 2013-01-04 13:23:56 UTC 
Created attachment 672405 [details]
storage.log
Comment 4 David Lehman 2013-01-04 14:38:58 UTC 
(In reply to comment #2) 
> Good:
> * It is still not possible to start installing
> * A yellow banner in the main hub print an error that suggest an incorrect
> partitioning choice done by the user.
> 
> Bad: 
> * STORAGE: INSTALLATION DESTINATION is not alarmed. (no exclamation mark)

This is intentional. It could be considered a storage error or a software selection error. Treating it as one or both becomes very complicated, so we decided to use only an error notification on the main hub.
Comment 5 Adam Williamson 2013-05-10 03:46:28 UTC 
This is clearly resolved now, closing.