-----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 <[email protected] <mailto:[email protected]>> >> Sent: Sunday 11th November 2012 1:11 >> To: Scientific Linux <[email protected] >> <mailto:[email protected]>> >> 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-----
<<attachment: reb.vcf>>
