Bug 1144604

Summary:	installer tries to apply custom kickstart layout again when user visits storage spoke
Product:	Red Hat Enterprise Linux 7	Reporter:	David Lehman <dlehman>
Component:	anaconda	Assignee:	David Lehman <dlehman>
Status:	CLOSED ERRATA	QA Contact:	Release Test Team <release-test-team>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.0	CC:	mbanas
Target Milestone:	rc
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	anaconda-19.31.100-1	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:	1144560	Environment:
Last Closed:	2015-03-05 14:03:17 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:
Bug Depends On:	1144560
Bug Blocks:

Description David Lehman 2014-09-19 20:58:45 UTC

+++ This bug was initially created as a clone of Bug #1144560 +++

Description of problem:
if you do an actual kickstart installation with a ks.cfg that contains a custom storage layout, then try to enter the storage spoke to go view/adjust your layout in the custom spoke, it will try to allocate everything again between the storage and custom spokes, which causes an error, which causes us to reset everything and lose your custom layout.

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

How reproducible:
always

Steps to Reproduce:
1. do a kickstart install with a non-working base repo and custom storage
2. visit the storage spoke, proceed to custom spoke
3.

Actual results:
everything has been reset to on-disk

Expected results:
my custom layout is visible in custom spoke

Additional info:

--- Additional comment from David Lehman on 2014-09-19 14:25:48 EDT ---

Already fixed on master.

Comment 1 David Lehman 2014-09-19 21:00:46 UTC

It turns out this is only hittable if something about the ks.cfg prevents anaconda from leaving the first hub, which is often the case for me since I often specify a stage1 that has no repodata or packages in the tree.

Comment 5 errata-xmlrpc 2015-03-05 14:03:17 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-0312.html