Le fonctionnement des live

Classé dans : informatique | 0 commentaire(s)

07
04 | 11

Vous ne vous êtes jamais demandé comment fonctionnait un live-cd ?
Qu'est-ce qui se cachait derrière ce système qui parvient à tourner sur un CD où il ne peut pas écrire, et à stocker ses changements en mémoire vive ?

Au risque de vous décevoir, c'est très simple !

Si vous n'avez pas encore connaissance du fonctionnement général du boot d'un système avec initramfs, je vous conseille la lecture de cet article.
Ce n'est pas indispensable, mais aidera pour la suite.

Le principe est le même sur toutes les distributions, ça ne s'arrête pas à Arch. Seuls les détails de mise en forme varient.

Au début, tout se passe comme d'habitude. Tout comme votre disque dur, le CD contient un chargeur de démarrage, un noyau et un initramfs (directement dans l'iso).
Le chargeur copie le noyau et son initramfs en mémoire vive, et passe la main au noyau.
Celui-ci, comme d'habitude, trouve son initramfs, l'extrait et exécute le fichier /init qui se trouve dedans.

C'est là que le scénario diffère du boot sur disque dur : le script /init (ou exécutable binaire, mais c'est plus pratique de faire un script avec le shell pour le lancer juste à coté) ne fait pas la même chose.


Dans le cas d'un boot sur disque dur, /init charge les modules pour trouver la partition (passée en argument au noyau avec root=), la monte dans /new_root et switch_root (chroot) dedans en y lançant /sbin/init.


Dans le cas d'un live, on va, de même, trouver la partition voulue (par son label, couramment), puis monter l'archive squashfs qui contient tous les fichiers de la racine (la partition racine, si vous voulez) dans /ro_branch.

Montage de l'iso : mount /dev/disk/by-label/mon-live /iso
Montage du squashfs : mount -o loop /iso/racine.sqfs /ro_branch

Ce n'est pas fini : on ne peut pas déjà booter sur la racine en lecture seule !
Rien que le fait de lancer X nécessite de créer des petits fichiers (sockets, verrous) dans le système de fichiers.

On monte donc un système de fichiers tmpfs (en RAM) dans /rw_branch : mount -t tmpfs none /rw_branch

Et maintenant ?
On va utiliser une petite merveille développée spécialement pour cet usage : un « unioning filesystem ». Par exemple UnionFS ou AUFS.
Comment ça marche ? L'idée est de fusionner plusieurs dossiers (appelés branches) en un seul (la destination).
En lecture, il n'y a qu'à gérer les priorités : l'ordre dans lequel on a monté nos dossiers sur le dossier de destination détermine lequel passe en premier si un fichier est présent dans plusieurs branches.

En écriture (si on modifie/crée un fichier dans notre fameux dossier “assemblé”, où doit-il aller ?), on a résolu le problème simplement : on a désigné au départ l'un des dossiers comme LA branche lecture-écriture de l'union.

On va donc d'abord monter /rw_branch comme branche rw (read-write, lecture-écriture) de /new_root : mount -t aufs -o dirs=/rw_branch=rw none /new_root

Ensuite, on rajoute /ro_branch où est montée l'image squashfs du CD comme branche ro (read-only, lecture seule) de /new_root :
mount -t aufs -o remount,append:/ro_branch=ro none /new_root

Et maintenant, on peut switch_root (c'est à dire chroot) dans /new_root pour y lancer /sbin/init !


Le système est comme sur un disque dur.
La seule différence, c'est que les fichiers modifiés iront dans le tmpfs, pas dans l'iso (impossible : lecture seule !)

J'en entends déjà me dire “et quand on supprime des fichiers ?”
Eh bien, AUFS crée un fichier .wh.nomdufichier dans sa branche rw (ici /rw_branch) pour se souvenir que ce fichier ne doit pas apparaître dans l'union. (évidemment, on ne peut pas le supprimer du CD…)

Si vous êtes intéressé par AUFS, sachez que ses fonctions sont bien plus étendues que ça…Voyez son site. :)

Article publié sous licence GFDL.

Ecrire un commentaire




Quelle est la troisième lettre du mot egdblx ? :