Bug 748160

Summary:	3.1.0-0.rc10.git0.1.fc16.x86_64 fails to autostart raid0 array when booting
Product:	[Fedora] Fedora	Reporter:	Peter Trenholme <PTrenholme>
Component:	kernel	Assignee:	Kernel Maintainer List <kernel-maint>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	16	CC:	gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-10-27 00:11:20 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Peter Trenholme 2011-10-22 16:45:17 UTC

Description of problem:
I have my F-16 beta on a raid 0 array. When the latest update installed rc10, boot failed (because the UUID of the raid array was not found) and dropped me into the dracut# prompt. I tried to start the array from mdadm, but was unable to do so,

Rebooting with rc9 worked as expected. (I'm posting this from the F-16 installation using rc9 now.)

Version-Release number of selected component (if applicable):
3.1.0-0.rc10.git0.1.fc16.x86_64

How reproducible:
Every time

Steps to Reproduce:
1. Install kernel 3.1.0-0.rc10.git0.1.fc16.x86_64
2. Reboot
3.
  
Actual results:
Cannot find UUID=... from the kernel root=UUID=... line

Expected results:
Normal boot

Additional info:
1) I'm using GRUB 2 to boot, with the raid module loaded.
2) I have another test installation on a virtual drive (of F-17 aka rawhide) using GRUB 2 to boot. That virtual system also fails to boot from the RC10 kernel, but has no problem with booting from the RC9 kernel. The F-17 virtual system does NOT use a RAID array.

Comment 1 Peter Trenholme 2011-10-22 16:56:32 UTC

Re my point (2) in the additional info section: The image file used by the  virtual F-17 system that fails to boot with the RC10 kernel is on the RAID 0 drive that the F-16 system (which also fails to boot with RC10) uses. So the problem could still be related to a regression in RAID processing by RC10. (Not that the virtual system fails to boot using RC10 even when started from a F-16 system using RC9 or a F-15 using 2.6.40, so the problem seems (to me) to be in the way the kernel is accessing data on a RAID 0 array, not the GRUB 2 usage.

Comment 2 Peter Trenholme 2011-10-22 17:00:14 UTC

Typo - My parenthetical comment should have started with "Note" not "Not."

vis: (Note that the virtual system fails to boot using RC10 even when started from a F-16 system using RC9 or a F-15 using 2.6.40, so the problem seems (to me) to be in the way the kernel is accessing data on a RAID 0 array, not the GRUB 2 usage.)

Comment 3 Chuck Ebbert 2011-10-25 02:50:17 UTC

(In reply to comment #3)
> 2) I have another test installation on a virtual drive (of F-17 aka rawhide)
> using GRUB 2 to boot. That virtual system also fails to boot from the RC10
> kernel, but has no problem with booting from the RC9 kernel. The F-17 virtual
> system does NOT use a RAID array.

This is a completely separate problem and is almost certainly due to not having an initrd line in the GRUB config for that kernel. You will need grubby 8.3-1 in order to get the newer kernels to install in F-17.

Comment 4 Peter Trenholme 2011-10-27 00:11:20 UTC

Please close this: I just discovered that the UUID in the RAID 0 super block was NOT the value specified in /etc/mdadm.conf, and that (possibly because of this) the UUID reported by UDEV was, as far as I can see, not a UUID of any partition on my system. (Perhaps UDEV generates a UUID when it can't find one?)

Anyhow, when I updated the UUID of the array, re-ran grub-mkconfig, and rebooted, the problem no longer occurred.

Oh, re. Mr Ebbert's comment: Thank you, that resolved that problem.