Even if your work doesn’t require you to reboot your Linux machine several times a day, waiting for a system to reboot can be a real drag. Enter kexec. Essentially, kexec is a fast reboot feature that lets you reboot to a new Linux kernel — without having to go through a bootloader. Faster reboot is a benefit even when uptime isn’t mission-critical — and a lifesaver for kernel and system software developers who need to reboot their machines several times a day. Kexec is currently available on the x86 32-bit platform only.
Reboot Linux Faster Using kexec
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I think the real use here is for kernel upgrades on enterprise systems. Sometimes rebooting just for a new kernel patch is a pain, and espcially if a week after another one comes out. This could really help…
Driver and other system developers also need this feature.
This is very useful, but I’m looking for a faster way of rebooting from cold. LinuxBIOS (http://www.linuxbios.org/) is useful in this regard, you can directly boot the kernel, skipping the firmware part entirely, on EVERY boot, not just boots after the first boot.
Erik
I see this being used on install cds. Can you imagine not even having to reboot after the install? Just have the setup program do a pivot-root and kexec the hard drive kernel then eject the install cd. No need for reboot even after the install is finished. Now thats cool.
Many distributions used to do that, I remeber in particular Caldera Linux used to.
Kernel boot time is very small (around 5~10% ?) compared to loading the rest of the daemons, apps, X server, etc… when a desktop or server machine boots.
The author is mainly worried by firmware upload times, but that’s a special case. On my main machine I have a wi-fi card that needs a firmware upload during boot; it takes 0.5s to complete, vs. > 60 seconds for the rest of the boot process.
I think the real use here is for kernel upgrades on enterprise systems. Sometimes rebooting just for a new kernel patch is a pain, and espcially if a week after another one comes out. This could really help…
In “enterprise systems”, individual machine failures are inconsequential. So the relevance of a few extra seconds downtime – be it scheduled or not – is dramatically close to zero.
The only real interest for a feature like this is to compulsive kernel upgraders and developers. No-one else reboots often enough for it to be important.
SystemServices. Does anyone know if this concept/idea/project that Seth Nickell came up with is actually being developed? I hope it is!
“This is very useful, but I’m looking for a faster way of rebooting from cold. LinuxBIOS (http://www.linuxbios.org/) is useful in this regard, you can directly boot the kernel, skipping the firmware part entirely, on EVERY boot, not just boots after the first boot.”
Yes. I’ve also thought about that, and its other similar implementations (are on freshmeat.net; search for BIOS). However not all motherboards are supported as of yet and migrating to another BIOS is a way to fuck up the motherboard; you better know what you’re doing!
Say you have a faculty with 30 Linux computers. They all have the same hardware. If it works on 1, it works on all of them, which drops doubt, saves time, etc. If you can permit yourself one test machine including the possible dangers, and you succesfully get the thing off the ground, you’re all set. Or say, Google’s cluster. That makes more sense to me than say that one home computer or one important server…
Given i run a heterogenous environment (regarding hardware) i decided to drop this alltogether thus not suggesting it to co-volunteers.
Regarding Kexec lets say you have a server which must be 24/7. But you really need to reboot it, for example because of a security hazard in the kernel. You test the kernel in ie. Bochs, and if it works okay, you use Kexec to save a bit of time during the update.
>The author is mainly worried by firmware upload times, but that’s a special case. On my main machine I have a wi-fi card that needs a firmware upload during boot; it takes 0.5s to complete, vs. > 60 seconds for the rest of the boot process.
Actually the BIOS is meant with firmware.
quoting the site : “The system will reboot immediately. Unlike the normal reboot process, kexec does not perform a clean shutdown of the system before rebooting. It is left to you to kill all applications and unmount file systems before attempting a kexec reboot.”
therefore not suitable to most other purposes.
How about executing Kexec after all that? In sysvinit, /etc/rc6.d/S89kexec seems fine to me at first glance (right before reboot in my default Debian Sarge setup).