Just updated another machine to 5.3, everything fine, but grub.conf wasn't updated to the 128 kernel. It got a new modified date and the kernel is there, but the content wasn't changed. /etc/sysconfig/kernel contains the correct UPDATEDEFAULT=yes No errors in logs or during the update. No problem to boot with this kernel once added. This is the first time I ever see this happen. Any clues?
Kai
On Mon, 2009-04-06 at 18:35 +0200, Kai Schaetzl wrote:
Just updated another machine to 5.3, everything fine, but grub.conf wasn't updated to the 128 kernel. It got a new modified date and the kernel is there, but the content wasn't changed. /etc/sysconfig/kernel contains the correct UPDATEDEFAULT=yes No errors in logs or during the update. No problem to boot with this kernel once added. This is the first time I ever see this happen. Any clues?
Kai
This happened to me the other day when that kernel came out. "init" would not reload on the kernel update and yum stalled.
I had reboot into the old kernel rpm -e the 128 kernel and yum update kernel again and all was fine. I do have to say this machine was memory limited and swapping on update bad.
johnStanley
Quoting JohnS jses27@gmail.com:
On Mon, 2009-04-06 at 18:35 +0200, Kai Schaetzl wrote:
Just updated another machine to 5.3, everything fine, but grub.conf wasn't updated to the 128 kernel. It got a new modified date and the kernel is there, but the content wasn't changed. /etc/sysconfig/kernel contains the correct UPDATEDEFAULT=yes No errors in logs or during the update. No problem to boot with this kernel once added. This is the first time I ever see this happen. Any clues?
Kai
/etc/grub.conf should be a symlink to /boot/grub/grub.conf. If for some reason it is not, correct it, or look directly in /boot/grub/grub.conf and see if the kernel was added there.
Barry Brimer wrote on Tue, 07 Apr 2009 10:29:31 -0500:
/etc/grub.conf should be a symlink to /boot/grub/grub.conf. If for some reason it is not, correct it, or look directly in /boot/grub/grub.conf and see if the kernel was added there.
Sorry, I was talking about /boot/grub/grub.conf. I wasn't aware that one could assume I was talking about /etc/grub.conf.
Kai
On Tue, 2009-04-07 at 21:31 +0200, Kai Schaetzl wrote:
Barry Brimer wrote on Tue, 07 Apr 2009 10:29:31 -0500:
/etc/grub.conf should be a symlink to /boot/grub/grub.conf. If for some reason it is not, correct it, or look directly in /boot/grub/grub.conf and see if the kernel was added there.
Sorry, I was talking about /boot/grub/grub.conf. I wasn't aware that one could assume I was talking about /etc/grub.conf.
Well, JIC, make sure yoyr /boot/grub entries look like this.
ls -l /boot/grub/[gm]* lrwxrwxrwx 1 root root 8 May 9 2008 /boot/grub/grub.conf -> menu.lst -rw-r--r-- 1 root root 1108 Apr 2 21:33 /boot/grub/menu.lst
I'm not sure why it's set this way, probably some historical reason.
I only mention because I don't even know which the update process affects. If they aren't linked, I guess that might cause a problem.
Kai
William L. Maltby wrote:
On Tue, 2009-04-07 at 21:31 +0200, Kai Schaetzl wrote:
Barry Brimer wrote on Tue, 07 Apr 2009 10:29:31 -0500:
/etc/grub.conf should be a symlink to /boot/grub/grub.conf. If for some reason it is not, correct it, or look directly in /boot/grub/grub.conf and see if the kernel was added there.
Sorry, I was talking about /boot/grub/grub.conf. I wasn't aware that one could assume I was talking about /etc/grub.conf.
Well, JIC, make sure yoyr /boot/grub entries look like this.
ls -l /boot/grub/[gm]* lrwxrwxrwx 1 root root 8 May 9 2008 /boot/grub/grub.conf -> menu.lst -rw-r--r-- 1 root root 1108 Apr 2 21:33 /boot/grub/menu.lst
I'm not sure why it's set this way, probably some historical reason.
I only mention because I don't even know which the update process affects. If they aren't linked, I guess that might cause a problem.
I have long been amazed at that relationship. Mine is not the same as yours. (CentOS 5.3 totally updated)
[root@mavis download]# ls -l /boot/grub/[gm]* /etc/grub.conf -rw------- 1 root root 2378 Apr 2 15:07 /boot/grub/grub.conf lrwxrwxrwx 1 root root 11 Aug 7 2008 /boot/grub/menu.lst -> ./grub.conf lrwxrwxrwx 1 root root 22 Aug 7 2008 /etc/grub.conf -> ../boot/grub/grub.conf [root@mavis download]#
So, while menu.lst is the real file and grub.conf is a symlink to it on your system, the opposite is true on mine. I have no idea how that happened. I do know that when I do a manual edit, I don't go through a "who's on first" routine. I just edit one of them and move on to the next windmill.
On Tue, 2009-04-07 at 16:16 -0500, Robert wrote:
William L. Maltby wrote:
On Tue, 2009-04-07 at 21:31 +0200, Kai Schaetzl wrote:
<snip>
Well, JIC, make sure yoyr /boot/grub entries look like this.
ls -l /boot/grub/[gm]* lrwxrwxrwx 1 root root 8 May 9 2008 /boot/grub/grub.conf -> menu.lst -rw-r--r-- 1 root root 1108 Apr 2 21:33 /boot/grub/menu.lst
I'm not sure why it's set this way, probably some historical reason.
I only mention because I don't even know which the update process affects. If they aren't linked, I guess that might cause a problem.
I have long been amazed at that relationship. Mine is not the same as yours. (CentOS 5.3 totally updated)
Ditto here.
[root@mavis download]# ls -l /boot/grub/[gm]* /etc/grub.conf -rw------- 1 root root 2378 Apr 2 15:07 /boot/grub/grub.conf lrwxrwxrwx 1 root root 11 Aug 7 2008 /boot/grub/menu.lst -> ./grub.conf lrwxrwxrwx 1 root root 22 Aug 7 2008 /etc/grub.conf -> ../boot/grub/grub.conf [root@mavis download]#So, while menu.lst is the real file and grub.conf is a symlink to it on your system, the opposite is true on mine. I have no idea how that happened. I do know that when I do a manual edit, I don't go through a "who's on first" routine. I just edit one of them and move on to the next windmill.
Two things. Probably doesn't make any difference, but we never should assume.
AFAIK, my 5.3 is completely "box stock" in this area, and probably 98% of others too. I have no /etc/grub*.
$ ls -l /etc/grub* ls: /etc/grub*: No such file or directory
I also checked my 4.6 Centos. It has the /boot/grub[mg]* relationship reversed (menu.lst->grub.conf). I presume that's OK for 4.x as it is also "as delivered" AFAIK.
It *does* have an /etc/grub.conf->../boot/grub/grub.conf
So I'm guessing your is left over from an update from 4.x->5.x? But again, I don't have any information that this would affect anything.
I thought they would be worth mentioning only because mine has upgraded trouble-free (one exception back when sqllite(?) needed to be upgraded before the normal one) from 5.0->5.3. I did do the glibc thing first, which should not have an effect on this I guess.
Since *lots* of other folks have also upgraded w/NP, one makes a first assumption that something must be slightly different on your node.
<snip sig stuff>
HTH
William L. Maltby wrote on Tue, 07 Apr 2009 17:52:04 -0400:
AFAIK, my 5.3 is completely "box stock" in this area, and probably 98% of others too. I have no /etc/grub*.
$ ls -l /etc/grub* ls: /etc/grub*: No such file or directory
I also checked my 4.6 Centos. It has the /boot/grub[mg]* relationship reversed (menu.lst->grub.conf). I presume that's OK for 4.x as it is also "as delivered" AFAIK.
Bill, there's definitely something wrong on *your* system. ;-) It should be exactly as Robert has found it on his machine.
Kai
On Wed, 2009-04-08 at 01:43 +0200, Kai Schaetzl wrote:
William L. Maltby wrote on Tue, 07 Apr 2009 17:52:04 -0400:
AFAIK, my 5.3 is completely "box stock" in this area, and probably 98% of others too. I have no /etc/grub*.
$ ls -l /etc/grub* ls: /etc/grub*: No such file or directory
I also checked my 4.6 Centos. It has the /boot/grub[mg]* relationship reversed (menu.lst->grub.conf). I presume that's OK for 4.x as it is also "as delivered" AFAIK.
Bill, there's definitely something wrong on *your* system. ;-) It should be exactly as Robert has found it on his machine.
Well, at least you didn't spoil a perfectly good Friday for me. A symlink is something I can do.
Hmmm... Maybe the *64 systems are different? I'm on a 686. A rpm -q --filesbypkg grub doesn't show anything in /etc. And an rpm -v --verify grub looks ok too.
How much can I trust this stuff? The --verify shows /boot/grub but nothing in the directory itself - no /boot/grub/menu.lst or /boot/grub/grub.conf. And a --whatprovides on those two files claims no package owns them.
I guess they are not delivered as part of the package, but constructed during install.
Kai
Thanks,
William L. Maltby wrote on Wed, 08 Apr 2009 06:01:43 -0400:
Hmmm... Maybe the *64 systems are different?
No, they are the same in this respect. I'm not seeing any difference. There is a difference between systems (no matter which arch) when the /etc/grub.conf symlink got created. On all my systems it seems to be identical in date with the grub files in /boot/grub which seems to be the date of installation. But on the system I have this problem it's some months later.
Kai
Quoting Robert kerplop@sbcglobal.net:
William L. Maltby wrote:
On Tue, 2009-04-07 at 21:31 +0200, Kai Schaetzl wrote:
Barry Brimer wrote on Tue, 07 Apr 2009 10:29:31 -0500:
/etc/grub.conf should be a symlink to /boot/grub/grub.conf. If for some
reason
it is not, correct it, or look directly in /boot/grub/grub.conf and see
if the
kernel was added there.
Sorry, I was talking about /boot/grub/grub.conf. I wasn't aware that one
could
assume I was talking about /etc/grub.conf.
Well, JIC, make sure yoyr /boot/grub entries look like this.
ls -l /boot/grub/[gm]* lrwxrwxrwx 1 root root 8 May 9 2008 /boot/grub/grub.conf -> menu.lst -rw-r--r-- 1 root root 1108 Apr 2 21:33 /boot/grub/menu.lst
I'm not sure why it's set this way, probably some historical reason.
I only mention because I don't even know which the update process affects. If they aren't linked, I guess that might cause a problem.
I have long been amazed at that relationship. Mine is not the same as yours. (CentOS 5.3 totally updated)
[root@mavis download]# ls -l /boot/grub/[gm]* /etc/grub.conf -rw------- 1 root root 2378 Apr 2 15:07 /boot/grub/grub.conf lrwxrwxrwx 1 root root 11 Aug 7 2008 /boot/grub/menu.lst -> ./grub.conf lrwxrwxrwx 1 root root 22 Aug 7 2008 /etc/grub.conf -> ../boot/grub/grub.conf [root@mavis download]#So, while menu.lst is the real file and grub.conf is a symlink to it on your system, the opposite is true on mine. I have no idea how that happened. I do know that when I do a manual edit, I don't go through a "who's on first" routine. I just edit one of them and move on to the next windmill.
According to /sbin/new-kernel-pkg .. the file that actually gets updated on x86 and x86_64 systems is /boot/grub/grub.conf
Barry Brimer wrote on Tue, 07 Apr 2009 17:30:44 -0500:
According to /sbin/new-kernel-pkg .. the file that actually gets updated on x86 and x86_64 systems is /boot/grub/grub.conf
And as I already mentioned in my first posting this file *got* touched. The last modified date got changed, but not the file itself. Comparing it with a file on another machine doesn't reveaL any obvious differences. Specifically, the default entry that should get used as a template is exactly the same, even with the tabs, only the root path is different. Comparing the /boot directories I recognize now that I have 3 kernels left on a machine where it worked, but 4 on the machine where grub.conf didn't get updated. This is obviously not set in /etc/sysconfig/kernel. Is this a yum setting? I remember there is configuration how many kernels to keep, but I can't find it.
Kai
On Wed, 2009-04-08 at 01:43 +0200, Kai Schaetzl wrote:
Barry Brimer wrote on Tue, 07 Apr 2009 17:30:44 -0500:
According to /sbin/new-kernel-pkg .. the file that actually gets updated on x86 and x86_64 systems is /boot/grub/grub.conf
And as I already mentioned in my first posting this file *got* touched. The last modified date got changed, but not the file itself. Comparing it with a file on another machine doesn't reveaL any obvious differences. Specifically, the default entry that should get used as a template is exactly the same, even with the tabs, only the root path is different. Comparing the /boot directories I recognize now that I have 3 kernels left on a machine where it worked, but 4 on the machine where grub.conf didn't get updated. This is obviously not set in /etc/sysconfig/kernel. Is this a yum setting? I remember there is configuration how many kernels to keep, but I can't find it.
/etc/yum.conf
The installonlypkgs and installonly_limit keywords. The first, according to man yum.conf, defaults to kernel, kernel-smp, kernel-bigmem, kernel-enterprise, kernel-debug, kernel-unsupported and the latter to 3.
Kai
William L. Maltby wrote on Wed, 08 Apr 2009 05:39:27 -0400:
The installonlypkgs and installonly_limit keywords. The first, according to man yum.conf, defaults to kernel, kernel-smp, kernel-bigmem, kernel-enterprise, kernel-debug, kernel-unsupported and the latter to 3.
It seems to default to kernel* as I have clearly seen xen kernels announced for removal. All the yum.conf files are the same on my machines. I lied about what I wrote about the kernels that got kept. It's always 5 on the amchiens that have existed for some time. This fits with the installonly_limit = 5 in all yum.conf files. On the one machine with the problem it's 4 kernels, I think it hasn't reached more yet. Anyway, it remains a mystery why grub.conf didn't get updated here. I will check again with next kernel ...
Kai
on 4-7-2009 2:16 PM Robert spake the following:
William L. Maltby wrote:
On Tue, 2009-04-07 at 21:31 +0200, Kai Schaetzl wrote:
Barry Brimer wrote on Tue, 07 Apr 2009 10:29:31 -0500:
/etc/grub.conf should be a symlink to /boot/grub/grub.conf. If for some reason it is not, correct it, or look directly in /boot/grub/grub.conf and see if the kernel was added there.
Sorry, I was talking about /boot/grub/grub.conf. I wasn't aware that one could assume I was talking about /etc/grub.conf.
Well, JIC, make sure yoyr /boot/grub entries look like this.
ls -l /boot/grub/[gm]* lrwxrwxrwx 1 root root 8 May 9 2008 /boot/grub/grub.conf -> menu.lst -rw-r--r-- 1 root root 1108 Apr 2 21:33 /boot/grub/menu.lst
I'm not sure why it's set this way, probably some historical reason.
I only mention because I don't even know which the update process affects. If they aren't linked, I guess that might cause a problem.
I have long been amazed at that relationship. Mine is not the same as yours. (CentOS 5.3 totally updated)
[root@mavis download]# ls -l /boot/grub/[gm]* /etc/grub.conf -rw------- 1 root root 2378 Apr 2 15:07 /boot/grub/grub.conf lrwxrwxrwx 1 root root 11 Aug 7 2008 /boot/grub/menu.lst -> ./grub.conf lrwxrwxrwx 1 root root 22 Aug 7 2008 /etc/grub.conf -> ../boot/grub/grub.conf [root@mavis download]#So, while menu.lst is the real file and grub.conf is a symlink to it on your system, the opposite is true on mine. I have no idea how that happened. I do know that when I do a manual edit, I don't go through a "who's on first" routine. I just edit one of them and move on to the next windmill.
That has been there since RedHat switched from lilo to grub. Either there was some hard coded stuff they didn't want to mess with, or the anaconda team and the grub conversion team didn't communicate very well. That had to be back at least to RedHat 7.0, if not in the 6's.
-
Barry Brimer -
JohnS -
Kai Schaetzl -
Robert -
Scott Silva -
William L. Maltby