Kernel changes with off-hour scheduled reboot

[Joe Profaizer]

I made some kernel parameter changes (via SAM) and elected not to move the kernal into place and reboot immediately.
I received the message that I must execute /usr/sbin/kmupdate and then reboot my system for the changes to take effect. I want to schedule an automatic reboot about 7pm tonight. What would be the best method to automate the kernel parameter changes and the reboot tonight at 7pm, respectively?

Thank you,

..Joe

[Joe Profaizer]

Forgot to mention this is HP-UX 11.0 on an L2000

[Rainer von Bongartz · Accepted solution]

1.) set new kernel parameters
kmtune -s params=values
2.) create new kernel
mk_kernel
3.) schedule kernel update
kmupdate
4.) reboot at desired time
reboot -t time

Regards
Rainer

[Sridhar Bhaskarla]

Everything as said by Rainer except for the
last point.

You can schedule the shutdown with at command.
Do a shutdown -r y instead of reboot. kmupdate command will create a flag file called .update_ux in /stand. Based on this, kmbuild script in /sbin/init.d will move the kernel in place during the shutdown and clear .update_ux file. Reboot will make this script to run during the startup and causes an additional reboot of the system.

-Sri

[Joe Profaizer]

So "shutdown -r -y 28800" will shutdown and reboot my system in 8 hours? Can you only specify seconds for the time? (8*60)*60.

..Joe

[Sridhar Bhaskarla]

I would use at than shutdown/reboot with the time option. Because, if by any chance I do mistake, it is going to reboot immediately. So, it's better if you use at.

For ex

echo "/etc/shutdown -r y" |at now + 210 minutes

This will reboot the box after 3.5 hours from now.

-Sri

[linuxfan]

Hi Joe,

I know the solution offered will work for you now and since it is a L-class machine the reboots should be fast as well but if you were doing the same on a K-class, then the amount of downtime you need would easily double because when you run kmupdate, it creats a file called .update_ux and when the machine reboots one of the startup file (kmbuild) is looking for this file and if it finds it then moves the kernel along with the system file and dlkm directory to the correct location and then reboots the machine.

Like i said, for a production machine if time is a concern then it might be a better idea to just run kmupdate and then /sbin/init.d/kmbuild (if your run this in multi-user mode, it just moves the files for you and doesn't reboot but when run during system start, reboots the machine again) and then reboot just once which reduces your downtime.

I would like to hear what others think of this approach.

-Regards
Ramesh

[Darrell Allen]

Hi all,

Here's my procedure (and 2 cents worth) for building a kernel with SAM and rebooting later.

Use SAM to modify kernel parameters and build new kernel

After all mods are made use
"Actions"
"Process New Kernel"
"Do Not Move Kernel Into Place; Do Not Shutdown / Reboot Now"

note the message concerning location of the new kernel and system file, and running kmupdate

exit out of SAM

Tell the system you've built a new kernel (/stand/build/vmunix_test) and want to use it at the next boot
/usr/sbin/kmupdate

Move the new kernel parameters file (/stand/build/system.SAM) into place
cd /stand
cp -p /stand/system /stand/system.prev
cp -p /stand/build/system.SAM /stand/system

Everything is now set to utilize the new kernel at the next reboot.
Do not make other kernel modifications until after booting the new kernel. You need to test the new kernel and the only true test is to boot and run off it.
Reboot at your convenience (but I wouldn't wait an extended period).

To schedule the reboot:
echo "/usr/sbin/shutdown -r -y 300 >>some_logfile 2>&1" | at 1900

Of course, I hope you check that the system came up okay before your users try it!

Darrell