Bug 969327

Summary: race condition in kickstart partitioning
Product: [Fedora] Fedora Reporter: Kamil Páral <kparal>
Component: anacondaAssignee: Brian Lane <bcl>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 19CC: ajsfedora, anaconda-maint-list, awilliam, dshea, g.kaviyarasu, jonathan, mkolman, robatino, sbueno, vanmeeuwen+fedora, vbocek
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: AcceptedBlocker
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-06-13 19:45:53 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:    
Bug Blocks: 834090    
Attachments:
Description Flags
anaconda.log from FAIL try
none
storage.log from FAIL try
none
syslog from FAIL try
none
program.log from FAIL try
none
anaconda.log from SUCCESS try
none
storage.log from SUCCESS try
none
syslog from SUCCESS try
none
program.log from SUCCESS try
none
Kickstart file none

Description Kamil Páral 2013-05-31 08:20:31 UTC
Description of problem:
This is a split from bug 967527.

If you use "clearpart --all" in your kickstart, anaconda very often says "No disks selected" instead of configuring partitioning correctly. It doesn't happen always or for every one, but it happens quite often overall.

Version-Release number of selected component (if applicable):
anaconda 19.30 (F19 Beta)

How reproducible:
quite often (3 out of 4 attempts for some people, but not at all for other people)

Comment 1 Vojtěch Boček 2013-05-31 09:08:21 UTC
Created attachment 755200 [details]
anaconda.log from FAIL try

Attaching kickstart file and logs from both successful and failed tries. Interestingly, I was not able to reproduce the successful behavior with "cdrom" command present in kickstart file, so I had to remove it.

Comment 2 Vojtěch Boček 2013-05-31 09:08:51 UTC
Created attachment 755201 [details]
storage.log from FAIL try

Comment 3 Vojtěch Boček 2013-05-31 09:09:17 UTC
Created attachment 755202 [details]
syslog from FAIL try

Comment 4 Vojtěch Boček 2013-05-31 09:09:59 UTC
Created attachment 755203 [details]
program.log from FAIL try

Comment 5 Vojtěch Boček 2013-05-31 09:10:30 UTC
Created attachment 755204 [details]
anaconda.log from SUCCESS try

Comment 6 Vojtěch Boček 2013-05-31 09:10:57 UTC
Created attachment 755205 [details]
storage.log from SUCCESS try

Comment 7 Vojtěch Boček 2013-05-31 09:11:24 UTC
Created attachment 755206 [details]
syslog from SUCCESS try

Comment 8 Vojtěch Boček 2013-05-31 09:12:14 UTC
Created attachment 755207 [details]
program.log from SUCCESS try

Comment 9 Vojtěch Boček 2013-05-31 09:12:45 UTC
Created attachment 755208 [details]
Kickstart file

Comment 10 Kamil Páral 2013-05-31 09:14:53 UTC
Proposing as a blocker:
"The installer must be able to complete a scripted installation which duplicates the default interactive installation as closely as possible. "
"Any installation method or process designed to run unattended must do so. There should be no prompts requiring user intervention. "
http://fedoraproject.org/wiki/Fedora_19_Beta_Release_Criteria

Comment 11 Vojtěch Boček 2013-05-31 09:16:35 UTC
I also tried to put "clearpart" cmd before "autopart", but it didn't help.

Comment 12 Adam Williamson 2013-05-31 16:42:18 UTC
I'm probably +1 blocker on this one.

Comment 13 Adam Williamson 2013-06-03 16:16:42 UTC
Discussed at 2013-06-03 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-06-03/f19final-blocker-review-2.2013-06-03-16.00.log.txt . Accepted as a blocker per https://fedoraproject.org/wiki/Fedora_19_Beta_Release_Criteria#Unattended_installation : "Any installation method or process designed to run unattended must do so. There should be no prompts requiring user intervention."

Comment 14 Brian Lane 2013-06-04 18:33:20 UTC
Were you also hitting bug 967531? The attached kickstart doesn't have url or cdrom in it.

Comment 15 Vojtěch Boček 2013-06-04 19:19:18 UTC
(In reply to Brian C. Lane from comment #14)
> Were you also hitting bug 967531? The attached kickstart doesn't have url or
> cdrom in it.

Yes. Actually, I couldn't reproduce the correct behavior (paritions are selected without errors) without "cdrom" line in kickstart (hence the line "#cdrom") in at least 15 tries, but it still might be just a bad luck - race conditions are race conditions :/

Comment 16 Brian Lane 2013-06-04 23:44:59 UTC
Can you reproduce this with text mode? (just add text to the kickstart).

I'm suspicious of the big stack of 'setting <object> to ...', it's almost as if the hub communication is getting stuck. Or maybe that's just a logging artifact, but there's no good way to tell. text mode doesn't use the hubQ as much as gui does so maybe that will reveal something.

Comment 17 ajs 2013-06-05 22:54:20 UTC
Using TC1 I get a clean install in text mode and trigger the race condition in graphical mode.  So far only one test of each.

On my setup I encountered the race condition 100% of the time with the Beta netinstall ISO (~8 tries) and 0% with the Alpha netinstall ISO (~5 tries).

Comment 18 Kamil Páral 2013-06-07 10:42:29 UTC
I used the provided kickstart, but uncommented "#cdrom" line. With F19 TC1 DVD:

I made two attempts with graphical mode, once it passed, once it failed ("Failed to save configuration").

Then I made 4 attempts with text mode, all passed.

Comment 19 Chris Lumens 2013-06-13 19:45:53 UTC
I am pretty sure this is the same as bug 966761.  The descriptions are awfully similar here, and if we later get some other information we can always de-dupe.

*** This bug has been marked as a duplicate of bug 966761 ***