-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I just checked and the version of dracut you mention is in fastbugs
which I likely don't update from (I don't believe this is the default,
although I have used this before and never regretted it).  Maybe an
expert knows if the "bug" that got fixed likely would explain my problem.

On 11/13/2012 12:17 PM, Robert Blair wrote:
> Hmmmm - I will need to check but that system should be up to date.  Did
> you pull dracut from some special repository?  Maybe I got hit by a race
> condition (the kernel got updated but dracut was yet to arrive).  If so
> you would think that this is a dependency issue.
> 
> On 11/10/2012 08:54 PM, Bill Maidment wrote:
>> Try updating dracut. I have dracut-004-284.el6_3.1.noarch
> 
> 
> 
>> Regards
>> Bill Maidment
>> Maidment Enterprises Pty Ltd
> 
> 
>> -----Original message-----
>>> From:Robert Blair <[log in to unmask] <mailto:[log in to unmask]>>
>>> Sent: Sunday 11th November 2012 1:11
>>> To: Scientific Linux <[log in to unmask] <mailto:[log in to unmask]>>
>>> Subject: recent kernel and root raid1
>>>
>>> I have a system that failed to boot after the most recent kernel update.
>>>  It took a while, but I eventually traced it to the initramfs not having
>>> raid1 included.  I had to manually do a "mkinitrd --preload raid1" for
>>> the new kernel to get the system back up.  Oddly, the previous kernel's
>>> ram image was also similarly broken (and the time stamp indicated that
>>> it had been updated at about the same time as the new one) so I couldn't
>>> even revert to it but had to boot from a usb drive to do the repair.
>>> Has something changed in the post install or in mkinitrd that would
>>> explain this?  Am I the only one who has had this problem (am I the only
>>> one using a raid 1 root disk with no volume management)?
>>>
>>> For the record the system is SL 6.3 x86_64, the mkinitrd comes from
>>> dracut-004-283.el6.noarch and the kernels in question are
>>> vmlinuz-2.6.32-279.11.1.el6.x86_64
>>> vmlinuz-2.6.32-279.14.1.el6.x86_64
>>>
>>> Oddly I see that dracut is "a new, event-driven initramfs infrastructure
>>> based around udev".  How does that work on a system with a raid 1 root
>>> drive?  In my case the boot fails because the root file system
>>> (identified by a UUID on /dev/md0) can't be found.  It seems like udev
>>> is not going to be very functional until mkinitrd has already been used
>>> and the update of the previous kernel is likely related to how this is
>>> being done.  Maybe someone has some insight into this?
>>>
>>> Thanks,
>>> Bob Blair
>>>
>>>
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iQEVAwUBUKKQd/QM1KNWz8QaAQJsAQgAixLZa0XZ1JXEKG4nO6286wiCvmu/afsg
oQjhSbFHptp0aORjv4/bKQ2P/zTcR/vYyqPB0r1CG5CELReX1/PyHy+yXaeLckKB
WgDjFZej2/hVDLASWFiq7XIvdFxXDfkh0auZAe9BkunxfQ1B5bjlgB8FIPi6hQQ7
dMDTBiGkdx0WD04flQUKmH/PZFWWiXjI6iskpqQXCAsevm58f9Jj1BLVjJtTUWMO
X16bDvGdOeZsiEGRZKi6qPoOwWNwmd2A0++jaY78AF/kIeNTVGaWW8aa6s5CZURy
Kty4Py0rr9gn6UoC4LXBo5ZC6qfcoJDdP4yWF8wH9qTOaH28YKZ0rQ==
=sKln
-----END PGP SIGNATURE-----