legacy grub: updated menu.lst is not used

Question

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:

1. cp /boot/grub/menu.lst /boot/grub/menu.lst.old
2. 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

1. cat (hd0,0)/grub/menu.lst the new contents will be shown as expected
2. 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".

Answer 1

Ah, I posted my question on the wrong site, I intended to post on serverfault. Superuser sounded like Unix su to me. Just too long debugging too late at night...

Anyway I found the solution:

RHEL and thus CentOS don't use menu.lst at all, they use grub.conf instead. (The filename to be used can be specified during grub installation.)

However, there is a symbolic link menu.lst --> grub.conf

So if the admin is not aware of the different name calling vi on menu.lst will magically do the right thing.

However, now I remember when I called vi I saw too many places to change, quit vi again and called

sed -i s/foo/bar/g menu.lst

to do my changes. I even called

diff menu.lst.old menu.lst

to verify that everything was fine and it did indeed look correct.

However, sed -i had not edited the target of the symbolic link (as vi does), but replace the symbolic link with a new file with the new contents. grub.conf remained unmodified, so it was indeed the "hidden place" I suspected

Calling

sed -i s/foo/bar/g grub.conf

solves it all.