1833796 Members
4543 Online
110063 Solutions
New Discussion

Kernel Modification

 
SOLVED
Go to solution
Geno Church_1
Valued Contributor

Kernel Modification

Folks,

I need some help here. I need to modify the kernel parameter nstrtel. This parameter is responsible for the number of allowable telnet sessions. Currently it is set to 60 and I want to increase it to 120. I don't want to use SAM for this because I need to put together a script to push this out to several systems. Could someone post a step by step command line instruction on how to modify the kernel and move the new kernel in place I would greatly appreciate it and will definitly award points! ;)

Thanks in advance,
Geno
13 REPLIES 13
Steven E. Protter
Exalted Contributor
Solution

Re: Kernel Modification

kmtune -q query

kmtune -s sets it

so:

kmtune -s npty=120
kmtune -s nstrpty=120

cd /stand/build
/usr/lbin/sysadm/system_pre -s system
mk_kernel -s system
kmupdate

mv /stand/vmunix.prev vmunix.prev.1
mv /stand/vmunix vmunix.prev
mv vmunix /stand/vmunix

SEP
Steven E Protter
Owner of ISN Corporation
http://isnamerica.com
http://hpuxconsulting.com
Sponsor: http://hpux.ws
Twitter: http://twitter.com/hpuxlinux
Founder http://newdatacloud.com
Geno Church_1
Valued Contributor

Re: Kernel Modification

Would I run the kmtune commands before the system_prep command or after?
Michael Schulte zur Sur
Honored Contributor

Re: Kernel Modification

Hi,

I would say, SEP posted it in the sequence, you would use it too, except for that missing p.

greetings,

Michael
RolandH
Honored Contributor

Re: Kernel Modification

Check also that you have enough pty devices

# ls /dev/pts/t* | wc -w

If the value is lower as 120
then you must increase the number of device files.
In this case this will not be done if you reboot after kernel modification.

# # insf -d tels -s 120


Regards
Roland
Sometimes you lose and sometimes the others win
Geno Church_1
Valued Contributor

Re: Kernel Modification

SEP,

Thanks for the inof...BTW...I'm a little concerned about the kmtune placement...I was under the assumption the kmtune is ran after system prep.

Thanks again.

Geno
Michael Schulte zur Sur
Honored Contributor

Re: Kernel Modification

Hi,

the kmtune placement seems to be right.
However I have a problem with the last mv.
I got only a vmunix_test in /stand/build.

SEP, could you verify that?

Michael
Steven E. Protter
Exalted Contributor

Re: Kernel Modification

Yes, two mistakes.

Someone was talking to my while i posted.

system_prep not system_pre

and yes, Michael, when i actually bothered to run the commmands i got vmunix_test

Please modify my procedure accodringly and award this post 0 points.

SEP
Steven E Protter
Owner of ISN Corporation
http://isnamerica.com
http://hpuxconsulting.com
Sponsor: http://hpux.ws
Twitter: http://twitter.com/hpuxlinux
Founder http://newdatacloud.com
Michael Schulte zur Sur
Honored Contributor

Re: Kernel Modification

SEP,

in anticipation of that I moved vmunix_test to /stand. Then however upon reboot I got in /etc/rc.log an error that it could not find /stand/build/vmunix_test.

Have I missed anything?

greetings,

Michael
Geno Church_1
Valued Contributor

Re: Kernel Modification

Ok folks,

I have tried this procedure and it hasn't worked...If I do a kmtune -q nstrtel it still shows the pending value to be what I set it to and the current value is still the same....The procedure doesn't call for moving the /stand/system to /stand/system.prev..does this need to be done....If so, does a new /stand/system get created?

Geno
RolandH
Honored Contributor

Re: Kernel Modification

Ok - point for point.
This is the procedure for 11.00 & 11.11

1.# cd /stand/build
# rm â r * (Be careful with this! You need to be in /stand/build/)

2) Backup the current system file:
# cp /stand/system /stand/system.prev

3) Is the system file up to date?
If you are not sure that the current system file (/stand/system) corresponds to
the current kernel (/stand/vmunix), then use the system_prep script to extract a
system file from the current kernel:
# /usr/lbin/sysadm/system_prep [-s /stand/system]
Compare the new system file to the original one. The diff command should not
produce any results:
# diff /stand/system /stand/system.prev

4) Modify the system file
Use kmtune(1M) to modify kernel tunables. Use kmsystem(1M) to add/remove driver.
These commands do nothing more than modifying /stand/system. Due to various
dependencies, the system file should not be edited by hand. E.g.:
# kmtune â s dbc_max_pct=35 (changes tunable in system files)
# kmsystem â c y diag2 (adds driver diag2 to system file)
# kmsystem â c n diag2 (removes driver diag2 from system file)
The â kmâ commands are explained below in greater detail.

5) Generate the kernel
After you modified the system file, you can generate the new kernel using the
mk_kernel script. The name of the new kernel will be /stand/build/vmunix_test,
unless explicitly specified through the -o option. The -s option specifies the system file
to use, /stand/system is the default:
# mk_kernel

6) Schedule kernel update
kmupdate is used to initiate the move of the new kernel (/stand/build/vmunix_test)
and the corresponding files to their appropriate places at the next shutdown or startup.
The current kernel will be copied to /stand/vmunix.prev, then.
# kmupdate

7) Restart the system
The new kernel will be activated by restarting the system:
# cd /
# shutdown â r 0
NOTE:
Do not use the reboot command. Otherwise the movement of the kernel files will be
skipped and the system boots from the original kernel again. If you really need to reboot
instead of shutdown, then execute the rc script manually before rebooting:
# /sbin/init.d/kmbuild stop

I have attached a document where all these procedures are explained (for 10.x and 11.22/23 systems, too)

Do not assign points to this. SEP has explained the b
Sometimes you lose and sometimes the others win
RolandH
Honored Contributor

Re: Kernel Modification

Hopefully in a better readable output now.

Ok - point for point.
This is the procedure for 11.00 & 11.11

1.# cd /stand/build
# rm -r * (Be careful with this! You need to be in /stand/build/)

2) Backup the current system file:
# cp /stand/system /stand/system.prev

3) Is the system file up to date?
If you are not sure that the current system file (/stand/system) corresponds to
the current kernel (/stand/vmunix), then use the system_prep script to extract a
system file from the current kernel:
# /usr/lbin/sysadm/system_prep [-s /stand/system]
Compare the new system file to the original one. The diff command should not
produce any results:
# diff /stand/system /stand/system.prev

4) Modify the system file
Use kmtune(1M) to modify kernel tunables. Use kmsystem(1M) to add/remove driver.
These commands do nothing more than modifying /stand/system. Due to various
dependencies, the system file should not be edited by hand. E.g.:
# kmtune -s dbc_max_pct=35 (changes tunable in system files)
# kmsystem -c y diag2 (adds driver diag2 to system file)
# kmsystem -c n diag2 (removes driver diag2 from system file)


5) Generate the kernel
After you modified the system file, you can generate the new kernel using the
mk_kernel script. The name of the new kernel will be /stand/build/vmunix_test,
unless explicitly specified through the -o option. The -s option specifies the system file
to use, /stand/system is the default:
# mk_kernel

6) Schedule kernel update
kmupdate is used to initiate the move of the new kernel (/stand/build/vmunix_test)
and the corresponding files to their appropriate places at the next shutdown or startup.
The current kernel will be copied to /stand/vmunix.prev, then.
# kmupdate

7) Restart the system
The new kernel will be activated by restarting the system:
# cd /
# shutdown -r 0
NOTE:
Do not use the reboot command. Otherwise the movement of the kernel files will be
skipped and the system boots from the original kernel again. If you really need to reboot
instead of shutdown, then execute the rc script manually before rebooting:
# /sbin/init.d/kmbuild stop

I have attached a document where all these procedures are explained (for 10.x and 11.22/23 systems, too)

Do not assign points to this. SEP has explained the basics before.

Roland
Sometimes you lose and sometimes the others win
Laurent Menase
Honored Contributor

Re: Kernel Modification

one precision about the sequence:
mk_kernel -s system
kmupdate

mv /stand/vmunix.prev vmunix.prev.1
mv /stand/vmunix vmunix.prev
mv vmunix /stand/vmunix

Don't do that!
1) kmupdate backup /stand/vmunix to /stand/vmunix.prev
2) if you really want to keep vmunix.prev,
don't forget to move /stand/dlkm.vmunix.prev
to /stand/dlkm.vmunix.prev.1, else your kernel will not be bootable.
3) kmudpate make that the next shutdown will mv /stand/build/vmunix_test to /stand/vmunix, and /stand/build/dlkm_vmunix_test to /stand/dlkm after backing the original ones to prev
Geno Church_1
Valued Contributor

Re: Kernel Modification

I think I have it now...I went through the procedure and it now works.....

6972 cd /stand/build

6973 /usr/lbin/sysadm/system_prep -v -s system

6975 kmtune -s nstrtel=120 -S /stand/build/system

6976 kmtune -s npty=120 -S /stand/build/system

6977 kmtune -s nstrpty=120 -S /stand/build/system

6978 mk_kernel -s system

6979 mv /stand/system /stand/system.old

6980 mv /stand/build/system /stand/system

6981 /usr/sbin/kmupdate /stand/build/vmunix_test

6982 cd /

6983 shutdown -ry 0



Once system is back upâ ¦.verify your changesâ ¦..



6984 kmtune -q nstrtel à Should now be 120

6986 ls /dev/pts/t* |wc -l <-Should still be 60

6987 insf -d tels -s 120 Ã Will set the ttys to 120

6988 ls /dev/pts/t* |wc -l à Should now be 120



Thanks for all th