This has me puzzled. When it boots up, it shows the grub version as 1.98 which is grub2.

I looked at /boot/grub/grub.cfg and the 3 kernels are there:
vmlinuz-2.6.35-7.slh.1-aptosid-amd64
vmlinuz-2.6.36-1.slh.2-aptosid-amd64
vmlinuz-2.6.36-1.slh.7-aptosid-amd64
but the latest .7 kernel doesn't show up in the boot menu and I keep getting rebooted into the .2 kernel.

Anyone ever see this behavior? I did the upgrade-from-grub-legacy already just to make sure the old grub has been scrubbed...the only thing remaining is menu.lst which points at much older 2.6.34 kernels that I don't have installed.

### BEGIN /etc/grub.d/40_custom ###
# This file provides an easy way to add custom menu entries. Simply type the
# menu entries you want to add after this comment. Be careful not to change
# the 'exec tail' line above.
### END /etc/grub.d/40_custom ###

might be a problem, I have to leave for work at the moment and really just took a quick look, i could be dead wrong and don't have the time at the moment

_________________debian sid | apt-get into it

kenyee

Post subject:Posted: 10.12.2010, 00:24

Joined: 2010-09-29
Posts: 98

Status: Offline

That's what I thought initially as well, but when I ran upgrade-from-legacy-grub, it asked me where I wanted to write grub and I chose the drives in the raid array (/dev/sda, /dev/sdb) as well as /dev/md0 (which is the RAID1 partition for the raid drive) but not /dev/vg0 (which is the LVM partition inside the RAID container). I even wrote grub to the MBR multiple times and verified that 1.98 (grub2) was being loaded.

It's just w/ the latest kernel update (.7) that I've had this issue. It upgraded the grub.cfg properly w/ .2 and for a while before that.

I've run RAID1 since having my drives die on me every few years. I figure if one drive goes, at least I have a shot at replacing it before the other one goes so I don't lose any data