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)
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.
Created attachment 755201 [details] storage.log from FAIL try
Created attachment 755202 [details] syslog from FAIL try
Created attachment 755203 [details] program.log from FAIL try
Created attachment 755204 [details] anaconda.log from SUCCESS try
Created attachment 755205 [details] storage.log from SUCCESS try
Created attachment 755206 [details] syslog from SUCCESS try
Created attachment 755207 [details] program.log from SUCCESS try
Created attachment 755208 [details] Kickstart file
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
I also tried to put "clearpart" cmd before "autopart", but it didn't help.
I'm probably +1 blocker on this one.
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."
Were you also hitting bug 967531? The attached kickstart doesn't have url or cdrom in it.
(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 :/
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.
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).
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.
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 ***