Tuesday, February 02, 2010

kboot & kexec

http://kboot.sourceforge.net/

kboot is a proof-of-concept implementation of a Linux boot loader based on kexec. kboot uses a boot loader like LILO or GRUB to load a regular Linux kernel as its first stage. Then, the full capabilities of the kernel can be used to locate and to access the kernel to be booted.
kboot integrates the various components needed for a fully featured boot loader, and demonstrates their use. While the main focus is on basic technical functionality, kboot can serve as a starting point for customized boot environments offering additional features.

kboot is currently only tested on the ia32 (i386) platform. Some of its features include:

  • supports most file systems and device drivers the Linux kernel supports
  • transparent navigation in the file system of the booted system, including auto-mounting guided by /etc/fstab
  • network configuration is either manual or with DHCP, including name resolution via /etc/hosts and DNS
  • access to file systems via NFS
  • access to files via HTTP, FTP, and TFTP
  • inbound and outbound SSH (to and from the boot loader)
Besides that, it's easy to add more features. The most important missing features are:
  • no pretty user interface yet
  • no integration of RAID, LVM, etc.
  • needs to support more platforms, in particular amd64
  • file name completion only works for commands and kernels
  • does not boot legacy operating systems yet

kexec from wikipedia

kexec (kernel execution) is a mechanism of the Linux kernel that allows "live" booting of a new kernel over the currently running one. kexec skips the bootloader stage (hardware initialization phase by the firmware or BIOS) and directly loads the new kernel into memory, which starts executing immediately. This avoids the long times associated with a full reboot, and is useful on systems with high availability requirements, where minimizing downtime is of essence.

While feasible, there are two major challenges in implementing a mechanism such as kexec: first, the new kernel will overwrite the memory of the currently running one, while it is still executing. Second, the new kernel will usually expect all physical devices to be in a well-defined state, as they are after system reboot, when the BIOS (or firmware) resets them to a "sane" state. Bypassing a real reboot means devices may be in an unknown state, and the new kernel will have to recover from that.

  1. Reboot Linux faster using kexec

Blog Archive