-----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 <[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) iQEVAwUBUKKQd/QM1KNWz8QaAQJsAQgAixLZa0XZ1JXEKG4nO6286wiCvmu/afsg oQjhSbFHptp0aORjv4/bKQ2P/zTcR/vYyqPB0r1CG5CELReX1/PyHy+yXaeLckKB WgDjFZej2/hVDLASWFiq7XIvdFxXDfkh0auZAe9BkunxfQ1B5bjlgB8FIPi6hQQ7 dMDTBiGkdx0WD04flQUKmH/PZFWWiXjI6iskpqQXCAsevm58f9Jj1BLVjJtTUWMO X16bDvGdOeZsiEGRZKi6qPoOwWNwmd2A0++jaY78AF/kIeNTVGaWW8aa6s5CZURy Kty4Py0rr9gn6UoC4LXBo5ZC6qfcoJDdP4yWF8wH9qTOaH28YKZ0rQ== =sKln -----END PGP SIGNATURE-----
<<attachment: reb.vcf>>
