massive kernel compile failure

[Mel Burslan]

Well, I am almost midway into my new system installation and time has come to change kernel parms to what dba's want for their oracle instance.

Instead of doing the chages one by one using SAM, I wanted to do update the system file and do a manual compile of kernel but it failed miserably. As I am not a kernel expert by no means, I am not sure where to look for these failures. It seemed like it did not like the symbolic (formula) assignments to some parms but this is my educated guess.

related files and parms are attached. any suggestion/help is greatly appreciated..

[RAC_1]

Do not vi the system file.

Do as follows.

kmtune -s nproc=xxxx -S ./system

then check and post.

Anil

[Steven E. Protter]

Full procedure in this thread.

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=105739

SEP

[Sundar_7]

Mel,

Looks like you have some typo errors in the system file.

From 11.0 it is not recommended to edit system file directly

# cd /stand/build
# /usr/lbin/sysadm/system_prep -s system
# kmtune -s maxdsize=value -S system
# mk_kernel -s system
# kmupdate
# cp /stand/system /stand/system.prev
# shutdown -r -y 0

-- Sundar.

[Mel Burslan]

Anil, Sundar,

Thanks for the suggestion but this is almost the same thing that I was trying to avoid, i.e., modfying parm's one by one.

I know HP is driving people away from doing things the old school way, i.e., vi and a compiler or from the command line (see trusted system conversions and support functions as an example) and driving towards utilities like SAM, but all in all, this is unix and in the background, there is a kernel being compiled by a c compiler, and I have done this in a smaller scale before, without any problems.

Steven,

I followed the procedure but I am not sure if editing the system file and introducing parm values as formulas work as expected. I have done this thing with few kernel parms changed and they were all being constants. This time I want quite a lot of them to be changed and some need to be formulas.

Any further suggestions ??

[Mel Burslan]

Well, I have tried using kmtune command to modify the parm's and run into the same errors after running mk_kernel as follows :

# mk_kernel -s system
Generating module: krm...
Generating module: gvid_info...
Generating module: drmfgl...
Generating module: gvid_him_fglrx...
Generating module: drmfglrx...
Generating module: gvid_him_cons...
Compiling conf.c...
(Bundled) cc: "/usr/conf/space.h.d/system_space.h", line 300: error 1588: "nproc" undefined.
(Bundled) cc: "/usr/conf/space.h.d/system_space.h", line 300: error 1521: Incorrect initialization.
(Bundled) cc: "/usr/conf/space.h.d/system_space.h", line 300: error 1521: Incorrect initialization.
(Bundled) cc: "/usr/conf/space.h.d/system_space.h", line 627: error 1521: Incorrect initialization.
(Bundled) cc: "/usr/conf/space.h.d/system_space.h", line 632: error 1584: Inconsistent type declaration: "nproc".
(Bundled) cc: "/usr/conf/space.h.d/sysv_msg_space.h", line 54: error 1521: Incorrect initialization.
(Bundled) cc: "/usr/conf/space.h.d/sysv_msg_space.h", line 54: error 1521: Incorrect initialization.
(Bundled) cc: "/usr/conf/space.h.d/sysv_msg_space.h", line 54: error 1521: Incorrect initialization.
(Bundled) cc: "/usr/conf/space.h.d/sysv_msg_space.h", line 80: error 1521: Incorrect initialization.
(Bundled) cc: "/usr/conf/space.h.d/sysv_msg_space.h", line 80: error 1521: Incorrect initialization.
(Bundled) cc: "/usr/conf/space.h.d/sysv_msg_space.h", line 104: error 1521: Incorrect initialization.
(Bundled) cc: "/usr/conf/space.h.d/sysv_msg_space.h", line 104: error 1521: Incorrect initialization.
(Bundled) cc: "/usr/conf/space.h.d/sysv_msg_space.h", line 119: error 1502: Array size must be a constant expression.
(Bundled) cc: "/usr/conf/space.h.d/sysv_msg_space.h", line 120: error 1502: Array size must be a constant expression.
(Bundled) cc: "/usr/conf/space.h.d/sysv_msg_space.h", line 121: error 1502: Array size must be a constant expression.
(Bundled) cc: "/usr/conf/space.h.d/sysv_msg_space.h", line 123: error 1521: Incorrect initialization.
(Bundled) cc: "/usr/conf/space.h.d/sysv_msg_space.h", line 126: error 1521: Incorrect initialization.
(Bundled) cc: "/usr/conf/space.h.d/sysv_msg_space.h", line 128: error 1521: Incorrect initialization.
(Bundled) cc: "/usr/conf/space.h.d/sysv_sem_space.h", line 78: error 1588: "semmni" undefined.
(Bundled) cc: "/usr/conf/space.h.d/sysv_sem_space.h", line 78: error 1521: Incorrect initialization.
(Bundled) cc: "/usr/conf/space.h.d/sysv_sem_space.h", line 78: error 1521: Incorrect initialization.
(Bundled) cc: "/usr/conf/space.h.d/sysv_sem_space.h", line 86: error 1521: Incorrect initialization.
(Bundled) cc: "/usr/conf/space.h.d/sysv_sem_space.h", line 86: error 1521: Incorrect initialization.
(Bundled) cc: "/usr/conf/space.h.d/sysv_sem_space.h", line 131: error 1502: Array size must be a constant expression.
(Bundled) cc: "/usr/conf/space.h.d/sysv_sem_space.h", line 145: error 1502: Array size must be a constant expression.
(Bundled) cc: "/usr/conf/space.h.d/sysv_sem_space.h", line 150: error 1521: Incorrect initialization.
(Bundled) cc: "/usr/conf/space.h.d/sysv_sem_space.h", line 151: error 1521: Incorrect initialization.
*** Error exit code 1

Stop.
config: make did an exit(1)


any ideas ??

[Jeff Carlin · Accepted solution]

You had a problem with maxdsiz_64... should be maxdsiz_64bit. I did take your values and create a SAM kernel tuning file. You can use this file to make many changes all at once in SAM. This should help you out.

Place the attached file in the /usr/sam/lib/kc/tuned
directory.

Change the owner to root:sys
Change the mod to 640

Start SAM and enter the "kernel configuration" menu, then select "configurable parameters". Under "actions", select "apply tunedparameter set". Scroll down and you should see the file I sent you called "Oracle tuning file 07/27/2004". Select this. Follow the prompts and then "process new kernel" to build the kernel and reboot the server.

Sam tuning files are very easy to create and make kernel tuning much eaiser. The format is simple. The first line of the file is the title that will appear in the SAM menu. You can add comments after that (first character must be the "#" sign. Kernel changes are expressed in three columns. The first being the kernel value to change. The second column being the minimum value and the third column being the highest value. Formulas are okay. If the current kernel value to be changed is below the minimum it will be raised to the first column value. Conversely , if the current value is above the thrid column it will be lowered. If you omit the third column, then the kernel value will be set the exactly the value specified in the tuning file (second column). The "--" is a placeholder for that column. If specified on the second column and and actual value in the third column, it means that you dont care what the minumum value is, just make sure final kernel value is not above what is specified in the third column.

In the file I created for you, I set all your value to minimums. This is typical for most tuning files. When applied, it will make sure the kernel values are at least set to the specified minimums.

[Mel Burslan]

I did not know about this, hence this was not what I was looking for. But it worked like charm.

Thanks.

[Bill Hassell]

You can modify every parameter if you want to, using SAM or using vi. Avoiding SAM means that all the built-in checks are now your responsibility. For instance, maxdsiz_64 will *always* fail if you edit the system file and add that value for a 32bit kernel. SAM knows what the current kernel is running and won't list any of the max..._64 parameters because they don't exist. HP isn't driving sysadmins away from vi and comand line procedures. Instead, tools like SAM are designed for the typical sysadmin that creates and/or changes a kernel once a month or 2-3 times a year. You can't expect to remember all the rules (and there are hundreds) for the system file if you aren't building kernels every week. And some rules are created with certain patches.

Similarly with Trusted Systems, authentication and PAM...security enhancements and changes are being created very rapidly but because "unix" was never designed for security some 25-30 years ago, a lot of patchwork is needed to integrate new methodologies such as LDAP, Kerberos, NIS, single sign-on, etc. So there are several tools and lots of rules needed to setup security policies. It is very possible to write a 50 line shell script to perform some data extraction that can be done with a one-liner in awk, but no one would prefer the shell method unless they didn't learn about awk (or perl, etc).

So, yes, compiling a kernel is nothing more than compiling a kernel...oh, well, there's that pesky mk_kernel that reads the system file to create the actual c code. So making a 32bit kernel for an opsystem that can run on simple workstation with one disk, or for a 64bit opsystem that can run on a system with 64 processors, 128Gb RAM and 50Tb of disks (same compiler, same procedures) is full of details (rules, etc) that make the procedure a lot more complex than HelloWorld.

SAM keeps up with all the details so think of SAM as awk for kernels. And in a production environment, no sysadmin can afford to keep trying over and over to build a kernel. HP-UX uptimes are measured in months and years.

As far as using a formula versus a constant, a formula is not required at all. mk_kernel converts the forula values to constants before feeding the source code to the compiler. Using a formula is just like using awk...it tries to guess how your is configured and predict what you will be running. The most common parameters where the formula doesn't work well are nproc, nfile and ninode. There are numerous examples where the number of users has no meaningful relationship to the number of processes, open files, etc. So a formula based on the maxusers and number of processors, amount of memory, etc is only a guess. The relationship between nproc and nfile can be nfile=nproc*5 all the way to nfile=nproc*500. No formula can adequately address this range because it depends on the programs that are running (hint: Universe databases can open thousands of files per user).

And while the DBA's gave their recommendations, you need to verify that the Oracle recommendation applies to your hardware and kernel (ie, max...64). And one last, but very important plug for SAM: Virtually all the documentation you need to know about kernel parameters is found in SAM's context help. SAM is always updated when kernel values change and this includes the help files. This is why loading patch bundles (rather than select-a-patch) is always recommended.