Bug 748160 - 3.1.0-0.rc10.git0.1.fc16.x86_64 fails to autostart raid0 array when booting
Summary: 3.1.0-0.rc10.git0.1.fc16.x86_64 fails to autostart raid0 array when booting
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 16
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-10-22 16:45 UTC by Peter Trenholme
Modified: 2011-10-27 00:11 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-10-27 00:11:20 UTC
Type: ---


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.