This is a CentOS 6.4 with all updates inside Virtualbox OSE (quite old version). All information below refers to the VM, I don't think there is any issue on the host.
/boot is a separate ext2 fs on /dev/sda1 (hd0,0)
What I did:
- cp /boot/grub/menu.lst /boot/grub/menu.lst.old
- vi /boot/grub/menu.lst
After rebooting the grub menu does not reflect the changes I made (some changes to kernel command line). Boot fails because to old command can no longer work.
If on grub command line I call
- cat (hd0,0)/grub/menu.lst the new contents will be shown as expected
- cat (hd0,0)/grub/menu.lst.old the old contents will be shown as expected
If I interactivly repeat my changes in grub command editing the boot succeeds.
I have repeated this many times. Have copied menu.lst around (so that the blocklist changes) but it is always the same problem. Grub "sees" the new version in its cat command, but not in its menu.
The machine has only one disk, the single disk has only one ext2 partition (rest is LVM2), the single ext2 partition contains only 1 file called menu.lst. So any confusion regarding disks, partitions or paths should be excluded.
(For some weird reason grub shows the same disk 5 times: hd0, hd8, hd9, hd10, and hd11 But they all have the same contents and the root is correctly set as (hd0,0) so I don't think this should be causing the problem)
So it appears that the old menu.lst has been copied to some hidden place and grub uses it from that hidden place for its menu. Editing the file has not modified the "hidden place". But for the first the file has a comment
# Note that you do not have to rerun grub after making changes to this file
for the second I'm quite sure I have done such updates many times back in the days when Ubuntu still used legacy grub and for the third it's my understanding that grub can read ext2 filesystems (can grub's cat command supports this) so there should be no reason for the "hidden place".