Pourquoi réimplémenter le support des filesystems dans les bootloaders (tel que Grub) alors qu'ils sont déjà disponibles dans le noyau Linux ? C'est en partant de cette problématique que les développeurs de kboots ont développé un bootloader basé sur... le noyau Linux lui-même.
Le fonctionnement idéal de kboots est qu'une fois le stage1 chargé, il lance le noyau trafiqué avec son propre initramfs contenant une mini distribution basée sur µlibc et busybox. Dès lors, le menu de sélection peut s'afficher (qui tourne en userspace). Jusqu'ici, rien d'extraordinaire, mais voyons plutôt le potentiel de ce genre de bootloader :
- Support natif de tous les filesystems (et il n'y a alors plus le support b0rken d'XFS comme dans Grub) de base,
- Accès à toutes les fonctionnalités du noyau Linux et de la mini-distribution integrée. Par exemple, vous pouvez faire tourner
un
sshd(ok, c'est un dropbear) dans le bootloader ce qui est pratique si vous vous êtes complétement foiré dans la configuration de votre noyau hebergé dans une salle aux USA. - Vous pouvez booter n'importe quel device supporté par Linux : Firewire, USB, Flash, etc.
- Et même par le réseau : FTP, HTTP, TFTP, etc.
Je pense qu'il y a un vrai potentiel à kibboutz^Wkboots. Après essai (et la compilation pendant une heure de tout ce qu'il fallait dans une petite VM), ca marche bien mais :
- C'est tout de même lent : il faut attendre le temps de boot d'un noyau Linux classique, donc au moins 30 secondes, puis le vrai noyau est lançé via kexec donc encore 30 secondes d'attente
- C'est testé sur x86 only :(
- Il n'y a pas encore le support de système autre que Linux
- Le stage1 n'est pas encore implémenté ! Donc en gros, il faut lancer kboot via votre bootloader favori. Pas glop mais ca marche très bien.
Même si certains médisants du bureau ne prennent pas au sérieux cette solution, je trouve ça très prometteur et j'envisage d'utiliser kboots sur des serveurs lointains...