Michael Schwendt writes:
My theory is that if the MBR is unmodified when the problem is encountered, something may have moved GRUB's stage* files in a way it couldn't find them anymore in their previous location. Then it would load and execute unexpected garbage. Since the boot record doesn't contain the extfs support, it doesn't understand filesystems before it loads its missing parts.
The only thing I can think of would be prelink, however there's no /boot listed in prelink.conf, and I can't think of any reason why it would be. AFAIK, ext3 does not do any kind of background maintenance or defragging, where it moves stuff around.
Furthermore, if something else on the system was randomly trashing grub, then you'd expect boot failures to occur randomly, at any time. One thing I'm confident about is that grub gets borked only immediately after a kernel update. It never borks on me out of the blue, at other times.
AFAIK installing a kernel should involve merely updating /boot/grub/grub.conf. I can't think of any reason why GRUB's stage files have to be involved. The script that updates it, /sbin/new-kernel-pkg invokes /sbin/grubby, apparently, to do that.
Without looking at grubby's source, a strings on the binary shows a reference to /boot/grub/stage1. So, grubby might be doing to grub itself, in addition to twiddling grub.conf, and occasionally gets it wrong.
Anyone know any reason why grubby would need to touch any grub files beyond its purported mission of looking after grub.conf?
Attachment:
pgpWUZ1nFpCRJ.pgp
Description: PGP signature
-- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
