Hi,

I want to update kernel cause it says i have to in WHM, right now i have 2.4.20-18.7

I dont want to use up2date -f cause its not recommanded

Instead I want to download the rpms and install it via rpm -ivh

But I have no idea how to do that

Could someone please help me out?

Thanks

Use
uname -a
then figure out what version you have - eg i686/i386
goto redhat.com and surf though the mirrors and look for the main kernel rpm to download.

Hi,

Okay here is what i found,

its a i686

and

http://www.redhat.com/apps/download/result...ch:fields=group

how do i know which one?

I see that only some of them are for i686 but, which one in those ones is for me?


Thanks

5. kernel 2.4.20 - 24.9 i686 | 31438k | Dec 1 2003 | Red Hat, Inc. [ download | details ]
The Linux kernel (the core of the Linux operating system)


Look at the date, december 1st, pretty much the latest kernel they have so thats what you want. I am assuming you DO NOT have a xeon, if you do there is a totaly different process.

But as long as its a normal single proc machine
http://www.redhat.com/swr/i686/kernel-2.4.....9.i686_dl.html
should work great for you

*edit*
direct link:
ftp://updates.redhat.com/9/en/os/i686//ke...0-24.9.i686.rpm

thanks!

so im going to do a wget and the rpm -ivh

am I on the right track?

even if wrong i did it. lol


# rpm -ivh kernel-2.4.20-24.9.i686.rpm
Preparing... ########################################### [100%]
1:kernel ########################################### [100%]
stdin: is not a tty
stdin: is not a tty
stdin: is not a tty
# reboot

Broadcast message from root (pts/0) (Tue Dec 16 13:39:53 2003):

The system is going down for reboot NOW!

correct then

lilo -v -v

double check that your lilo.conf has the correct info and is setup to boot to the new kernel, then reboot and pray my lilo.conf was updated automatically but always good to check and it will also check for any problems when you run that.

You might still be running the old kernel, my lillo.conf did not update until i ran the lilo -v -v

Whatever the case should not have any bad effects, just update the file with lilo -v -v and reboot again.

lol, yeah, before i did lilo -v -v, it was still using the old one, i just rebooted again. so its gona use the new one now? when you say check that your lilo.conf has the correct info , is that done by lilo -v -v ?

thanks

No I mean to manually check that it has the

2.4-20-24.9 as the default and that it has the section in the lilo.conf

the lilo -v -v SHOULD update it so probably will work, but its a good habit to check what the script did.

okay still using the old one...

so you mean pico the file? where is it located?

yours should look something like this, notice the default=

_____________________________________________
prompt
timeout=50
default=2.4.20-24.9
boot=/dev/hda
map=/boot/map
install=/boot/boot.b
message=/boot/message
linear

image=/boot/vmlinuz-2.4.20-24.9
label=2.4.20-24.9
initrd=/boot/initrd-2.4.20-24.9.img
read-only
append="root=/dev/hda3"

image=/boot/vmlinuz-2.4.20-20.9
label=Old
initrd=/boot/initrd-2.4.20-20.9.img
read-only
append="root=LABEL=/"
_____________________________________________


then once you run lilo -v -v should return this at the end:


Writing boot sector.

found it, its not changed do i change it just like that?

/etc/lilo.conf

yes use pico please ask if you have questions, should look something like mine. If you mess this file up you can cause yourself alot of problems

prompt
timeout=50
default=linux
boot=/dev/hda
map=/boot/map
install=/boot/boot.b
message=/boot/message
linear

image=/boot/vmlinuz-2.4.20-18.7
label=linux
root=/dev/hda3
read-only
initrd=/boot/initrd-2.4.20-18.7.img

need to add this

image=/boot/vmlinuz-2.4.20-24.9
label=linux
initrd=/boot/initrd-2.4.20-24.9.img
read-only
append="root=/dev/hda3"

MAKE SURE THE APPEND LINE IS WHAT YOURS WAS BEFORE. The disk is probably at /dev/hda3 but might be different on your server


now change your old kernel to
lablel=linux-old


if you have trouble just hav the tech boot to linux-old

sorry, i dont want to risk;

so you want me to have it like this:?

prompt
timeout=50
default=linux
boot=/dev/hda
map=/boot/map
install=/boot/boot.b
message=/boot/message
linear

image=/boot/vmlinuz-2.4.20-24.9
label=linux
initrd=/boot/initrd-2.4.20-24.9.img
read-only
append="root=/dev/hda3" iwasnt sure about this

image=/boot/vmlinuz-2.4.20-18.7
label=linux-old like this?
root=/dev/hda3
read-only
initrd=/boot/initrd-2.4.20-18.7.img

image=/boot/vmlinuz-2.4.20-18.7
label=linux-old like this?
root=/dev/hda3
read-only
initrd=/boot/initrd-2.4.20-18.7.img

is this all that you have in the old file?

normally there is some sort of append line, if there is not in the old file then remove it from config and replace with the root=

image=/boot/vmlinuz-2.4.20-24.9
label=linux
initrd=/boot/initrd-2.4.20-24.9.img
read-only
root=/dev/hda3

it really should be the same, but might as well keep it all standardized within your config.

*edit* and yes the linux-old is correct

yeah that was all of it.

=====
OLD
=======

prompt
timeout=50
default=linux
boot=/dev/hda
map=/boot/map
install=/boot/boot.b
message=/boot/message
linear

image=/boot/vmlinuz-2.4.20-18.7
label=linux
root=/dev/hda3
read-only
initrd=/boot/initrd-2.4.20-18.7.img


=======
I am changing it to:
===========


prompt
timeout=50
default=linux
boot=/dev/hda
map=/boot/map
install=/boot/boot.b
message=/boot/message
linear

image=/boot/vmlinuz-2.4.20-24.9
label=linux
root=/dev/hda3
read-only
initrd=/boot/initrd-2.4.20-24.9.img



=============
am i correct?

sorry for being stupid lol

good but leave

image=/boot/vmlinuz-2.4.20-18.7
label=linux-old
root=/dev/hda3
read-only
initrd=/boot/initrd-2.4.20-18.7.img

in the file, if there are problems they can boot to it (observe the change in linux-old)

okay. here it goes for the reboot

okay weired....

It started, thanks god, but then it still works with the old one!

and also see this

# rpm -q kernel
kernel-2.4.20-18.7
kernel-2.4.20-24.9


and

# lilo -v -v
LILO version 21.4-4, Copyright © 1992-1998 Werner Almesberger
'lba32' extensions Copyright © 1999,2000 John Coffman

Reading boot sector from /dev/hda
Merging with /boot/boot.b
Secondary loader: 11 sectors.
Mapping message file /boot/message
Message: 46 sectors.
Boot image: /boot/vmlinuz-2.4.20-24.9
Setup length is 10 sectors.
Mapped 2217 sectors.
Mapping RAM disk /boot/initrd-2.4.20-24.9.img
RAM disk: 248 sectors.
Added linux *
Boot image: /boot/vmlinuz-2.4.20-18.7
Setup length is 10 sectors.
Mapped 2098 sectors.
Mapping RAM disk /boot/initrd-2.4.20-18.7.img
RAM disk: 245 sectors.
Added linux-old
/boot/boot.0300 exists - no backup copy made.
Map file size: 30208 bytes.
Writing boot sector.



what do you think?

Speaking of updating Kernels, would it be wise to update to RH 9 before upgrading the Kernel or does it not matter?

eth00, i could use a bit more of your help please. thank you so much

Check the logs and see if there is anything in /var/log/messages, the lilo.conf does show

image=/boot/vmlinuz-2.4.20-24.9
label=linux
root=/dev/hda3
read-only
initrd=/boot/initrd-2.4.20-24.9.img

as the only label=linux right? It should wokr if you did that and ran lilo -v -v



lippy- It does not really matter, aside from the fact the files mentioned above are for rh9. In january the option to upgrade to enterprise will be given, along with another option for fbsd so at this point rh7.x is still viable. If your thinking of changing over to one of those in Jan I would say its not worth it, if however your planning on sticking with rh7.x for awhile longer I would say just get the upgrade done with.

sweeeet

thanks alot man, much appericiated.

I take it that its all working good now, if so glad I could help

Thanks eth00 for the response.

# rpm -q kernel
kernel-2.4.20-18.7
kernel-2.4.20-24.9




ermmm you had RH 7.3 kernel and you updated to a RH 9.0 kernel?

I am running rh9 and it worked fine, I think the other guy was as well. If not and rpm let it install fine then apparently it works. Because you can always boot from the backup kernel its not that unsafe or anything and most of the time rpm will catch depedency issues which there would be allot of. The newer rs boxes come with rh9 which is what probably happened to this person.

Its the same for rh7.x though, just look on the site for the latest kernel.

sure but he had "kernel-2.4.20-18.7" which is a RH 7.3 kernel. (.7)

and then he installed "kernel-2.4.20-24.9" which is a RH 9.0 kernel (.9)

I didnt know that you can run 9.0 Kernel on 7.3 OS.

:eek: so what are you saying? its gona crash?

If its running fine no, if you ever have any stability issues just edit the lilo.conf to have the linux as the older kernel.

If its boots up and everything runs though your fine Any problems would be with it booting up and services starting, which you have sucessfully done.

A kernel is a kernel. They're not made for any particular Distro. For example, you could have an old RH 5.2 install that is running the latest and greatest kernel.

However, RedHat releases distro-specific RPMs that are built for certain requirements, such as gcc versions, and dependencies.

If it's running, all is well.

So now there are two newer kernels than the one discussed here:

kernel-2.4.20-24.9.i686.rpm 01-Dec-2003 12:39 13.4M
kernel-2.4.20-27.9.i686.rpm 18-Dec-2003 17:44 13.4M
kernel-2.4.20-28.9.i686.rpm 24-Dec-2003 14:25 13.4M

Does a server with 24.9 need to have 27.9 installed first before going to 28.9 or can a direct jump be made to 28.9 ?

you can make a direct-jump.

Does this mean it's happy?

lilo -v -v

LILO version 21.4-4, Copyright © 1992-1998 Werner Almesberger
'lba32' extensions Copyright © 1999,2000 John Coffman

Reading boot sector from /dev/hda
Merging with /boot/boot.b
Secondary loader: 11 sectors.
Mapping message file /boot/message
Message: 46 sectors.
Boot image: /boot/vmlinuz-2.4.20-28.9
Setup length is 10 sectors.
Mapped 2217 sectors.
Mapping RAM disk /boot/initrd-2.4.20-28.9.img
RAM disk: 293 sectors.
Added 2.4.20-28.9 *
Boot image: /boot/vmlinuz-2.4.20-24.9
Setup length is 10 sectors.
Mapped 2217 sectors.
Mapping RAM disk /boot/initrd-2.4.20-24.9.img
RAM disk: 287 sectors.
Added 2.4.20-24.9
/boot/boot.0300 exists - no backup copy made.
Map file size: 30720 bytes.
Writing boot sector.

looks happy.

Graduation!!!

root@myserver [/home/admin]# uname -r
2.4.20-28.9

Thanks for riding along!

I guess I spoke too soon. Back to grade school!

[Wed Jan 7 23:34:32 2004] [crit] (98)Address already in use: make_sock: could not bind to port 443
[Wed Jan 7 23:35:03 2004] [error] mod_ssl: Cannot open SSLSessionCache DBM file `/usr/local/apache/logs/ssl_scache' for status retrival (System error follows)
[Wed Jan 7 23:35:03 2004] [error] System: No such file or directory (errno: 2)
[Wed Jan 7 23:40:00 2004] [error] mod_ssl: Cannot open SSLSessionCache DBM file `/usr/local/apache/logs/ssl_scache' for status retrival (System error follows)

I don't think that's a kernel problem. That error means apache can't bind to TCP:443. What else has already bound to it?

I'm not sure. A restart of httpd has cleared the error. It had triggered the SSLSessionCache error into the error_log every 5 minutes since the system reboot.

Control panels are nice, but you had best be prepared to get down in the grease pit and use a wrench once in a while!

The make_sock is something else. Digging in:

Search the forum for keywords: make_sock address already

http://forum.ev1servers.net/showthread.php...address+already

This sits in my /tmp directory since I've had the server:

lrwxrwxrwx 1 root root 25 Dec 22 23:42 mysql.sock -> /var/lib/mysql/mysql.sock=

A grep of the error_log

[Mon Dec 22 22:43:28 2003] [crit] (98)Address already in use: make_sock: could not bind to port 443
[Wed Dec 24 10:56:11 2003] [crit] (98)Address already in use: make_sock: could not bind to port 443
[Sat Dec 27 09:24:29 2003] [crit] (98)Address already in use: make_sock: could not bind to port 443
[Tue Jan 6 02:21:53 2004] [crit] (98)Address already in use: make_sock: could not bind to port 443
[Wed Jan 7 23:34:32 2004] [crit] (98)Address already in use: make_sock: could not bind to port 443

Just an add to this error situation and this may be the wrong thread for this so move it if necessary. I note that there are similar unanswered errors on the board.

It appears that each time a reboot is issued from cpanel:

[Fri Jan 9 17:13:50 2004] [notice] caught SIGTERM, shutting down
[Fri Jan 9 17:15:25 2004] [notice] Apache configured -- resuming normal operations
[Fri Jan 9 17:15:25 2004] [notice] suEXEC mechanism enabled (wrapper: /usr/local/apache/bin/suexec)
[Fri Jan 9 17:15:25 2004] [notice] Accept mutex: sysvsem (Default: sysvsem)
[Fri Jan 9 17:15:25 2004] [crit] (98)Address already in use: make_sock: could not bind to port 443

The above error occurs.

It is then followed by the two error lines below, which occur every five minutes until httpd is restarted.

[Wed Jan 7 23:35:03 2004] [error] mod_ssl: Cannot open SSLSessionCache DBM file `/usr/local/apache/logs/ssl_scache' for status retrival (System error follows)
[Wed Jan 7 23:35:03 2004] [error] System: No such file or directory (errno: 2)

Then the error_log remains clear.

It's pretty bad when you come back almost a couple of months later to search for an error and you find your own post!

This stuff is in the ssl_engine_log

[29/Feb/2004 11:10:01 04825] [error] Cannot open SSLSessionCache DBM file `/usr/local/apache/logs/ssl_scache' for status retrival (S
ystem error follows)
[29/Feb/2004 11:10:01 04825] [error] System: No such file or directory (errno: 2)
[29/Feb/2004 11:15:00 04470] [error] Cannot open SSLSessionCache DBM file `/usr/local/apache/logs/ssl_scache' for status retrival (S
ystem error follows)
[29/Feb/2004 11:15:00 04470] [error] System: No such file or directory (errno: 2)
[29/Feb/2004 11:17:49 04269] [info] Init: 1st restart round (already detached)
[29/Feb/2004 11:17:49 04269] [info] Init: Seeding PRNG with 1160 bytes of entropy
[29/Feb/2004 11:17:49 04269] [info] Init: Configuring temporary RSA private keys (512/1024 bits)
[29/Feb/2004 11:17:49 04269] [info] Init: Configuring temporary DH parameters (512/1024 bits)
[29/Feb/2004 11:17:49 04269] [info] Init: Initializing (virtual) servers for SSL
[29/Feb/2004 12:18:09 04269] [info] Init: 2nd restart round (already detached)
[29/Feb/2004 12:18:09 04269] [info] Init: Seeding PRNG with 1160 bytes of entropy
[29/Feb/2004 12:18:09 04269] [info] Init: Configuring temporary RSA private keys (512/1024 bits)
[29/Feb/2004 12:18:09 04269] [info] Init: Configuring temporary DH parameters (512/1024 bits)
[29/Feb/2004 12:18:09 04269] [info] Init: Initializing (virtual) servers for SSL

This is evidently what has been causing all the SIGUSR1 trips in the error_log

[Sun Feb 29 12:18:09 2004] [notice] SIGUSR1 received. Doing graceful restart
[Sun Feb 29 12:18:09 2004] [notice] Apache/1.3.29 (Unix) mod_auth_passthrough/1.8 mod_log_bytes/1.2 mod_bwlimited/1.4 PHP/4.3.3 FrontPage/5.0.2.2634 mod_ssl/2.8.16 OpenSSL/0.9.7a configured -- resuming normal operations
[Sun Feb 29 12:18:09 2004] [notice] suEXEC mechanism enabled (wrapper: /usr/local/apache/bin/suexec)
[Sun Feb 29 12:18:09 2004] [notice] Accept mutex: sysvsem (Default: sysvsem)

I have no clue. They went away all by themselves and now they have started up again the same way.

-rw-r--r-- 1 root root 5 Feb 29 12:18 httpd.pid
-rw-r--r-- 1 root root 96471 Feb 29 12:18 ssl_engine_log
-rw------- 1 nobody root 0 Feb 29 12:18 ssl_mutex.4260
-rw------- 1 nobody root 0 Feb 29 12:18 ssl_scache.dir
-rw------- 1 nobody root 0 Feb 29 12:18 ssl_scache.pag

all the people comfortable with 2.4.20-xx kernel iterations, remember that since december there has been reported two critical vulnerabilities in function mremap, which could cause a root privilege compromise (with local exploits) on the box.

The latest kernel released is on http://kernel.org and it's version 2.4.25

nothing like the smell of fresh cooked, customized kernel in the morning.

there are not RPMs available from RedHat because of the End Of Life in december, so if you're really paranoid like me, your best option is configure, compile and install your own kernel.

People unfamiliar with process should read the new Kernel HOW-TO first

regards

I'm using the latest Red Hat Enterprise kernel 2.4.21-9.0.1.ELsmp