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

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)

iQEVAwUBUKKOqPQM1KNWz8QaAQKvawf+LBEzNHrBsh+oXySo2o8sSBIxC3ugqNKa
GjRwfK8RD7rd/Xmgf/IMj+5BySvlwNU/QenLjCgM2aSwQ6BLDVA5pYpIT4/cyIQq
eDLG6PG6a9jf19vIAvfQSWIo9jpUrcRusDpQtf9w+9jfRTS+c5WWFMAyfhtIIbC2
RAV4XOMx1Ta4mDmLvPCdT1lwp1yG0Yt8VGZ0CimtTM09YaT7cMt/0pjZ+9eCqIrw
QlFNB8IZ17nkyRGL6g9hpXYoh9JTCuZTV9UpUW+JXckoCHAWxqix5n1kEPKo/asH
6A6MufXM1nAYy/aV3h3XV4cvilNSvnI3yOimmnHrskyxq1rgeJ+m9g==
=tXXT
-----END PGP SIGNATURE-----