Bug 624126

Summary: Fedora 14 Alpha Install will not boot into desktop
Product: [Fedora] Fedora Reporter: Clyde E. Kunkel <clydekunkel7734>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: low    
Version: 14CC: anton, dougsland, gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda, vanmeeuwen+fedora
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-07-14 18:12:52 UTC Type: ---
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
dmesg of failed boot none

Description Clyde E. Kunkel 2010-08-13 18:24:20 UTC
Created attachment 438738 [details]
dmesg of failed boot

Description of problem:

This is probably not anaconda, but I don't know what it is.  Maybe kernel, maybe systemd, maybe mdadm

Version-Release number of selected component (if applicable):
kernel 2.6.35-0.57.rc6.git1.fc14.x86_64, anaconda 14.15

How reproducible:
Boot process fails different ways each time.

Steps to Reproduce:
1. Install F14A rc4 to an LV over raid 10
2. boot system
3.
  
Actual results:
various failures, attaching a dmesg that shows the various failures

Expected results:
Normal boot to gnome desktop.

Additional info:
The last attempt with selinux=0 and single passed (of about 5 tries) yielded the dmesg file attached, but it also hosed the raid 10 PV the LV was on.  Had to boot into centos on a totally separate PV/LV and use mdadm --assemble /dev/md127 --uuid=etc,etc --force --run

After the array resynced, it appears ok.  Currently booted into a rawhide LV on the raid 10 array.

Comment 1 Clyde E. Kunkel 2010-08-14 16:50:39 UTC
Removing from blocker bz since this is a real corner case.  Failure occurs due to a bad software array, md126.  Once this array was completely deleted and the composing partitions' reformated, Fedora 14 alpha booted normally.

HOWEVER, this does show the need to make some piece of software more robust.  The fact that there was a bad array should not have preventing booting with appropriate messages.  See line 1038 thru 1047 and on for specifics.  I can't tell if the problem is in the kernel or mdadm.

Severity should be reduced, but I can't do that.

Sorry for all of the noise.  

Sincerely,

Champion for robust software