Salut à tous,
Lors du boot, la machine utilise un kernel (le vmlinuz) et un ramdisk (initrd).
Je ne comprends pas trop qu’est-ce qui est utilisé à quel moment et pourquoi.
Je trouve des explications sur le net, mais qui traite à chaque fois de façon séparé vmlinuz et initrd.
Les deux sont bien utilisés lors du boot ?
Ou c’est soit l’un soit l’autre ?
Merci pour les éclaircissements
Lors du boute, la lecture sur le disque/CDROM/??? se fait par l’intermédiaire des routines du BIOS. Avant, cela chargeait le noyau (vmlinuz), puis le lançait (décompression, détection du matériel, de la racine, montage, etc). Lorsque le noyau prend le contraire, les routines de lecture du BIOS sont oubliées, le noyau doit se débrouiller seul, si il ne peut pas monter la racine, tu as un kernel panic. L’initrd permet de donner un peu de souplesse: outre le noyau, le boute charge également le fichier initrd.img, le noyau après s’être initialisé, déplie ce fichier dans un disque RAM et appelle /linuxrc (ancienne méthode) ou /sbin/init (nouvelle méthode), ce systèmle de fichier sommaire permet de faire les recherches nécessaires et de charger les modules nécessaires pour monter la racine, ensuite soit (ancienne méthode) il quitte et le noyau monte la racine et boute normalement, soit (nouvelle méthode) il fait un pivot_root et lance /sbin/init de la racine définitive.
Les initrd peuvent être fait de manière quasi automatique.
s/contraire/controle/
C’est tout bête, quand ton chargeur de démarrage démarre le programme vmlinuz, dans les distro récentes, la plupart des pilotes de stockage sont en modules.
Or comment charger un module qui est sur le disque dur, sans pouvoir y accéder ? (les systèmes de fichier sont aussi en module dans les noyaux debian 
)
Il faut donc charger les modules dans un pack spécial que le noyau sait lire.
Sinon, pourquoi pas tout mettre en dur, tout simplement parceque pas mal de pilotes sous linux sont carrément incompatible entre eux, que ça prendrais une taille monstre en mémoire, et que pas mal de pilotes ne fonctionnent plus dutout en dur comme avant… (Exemple le driver, pourtant surutilisé, du chipset de ma carte mère, ICH8…)
OK.
Donc si je comprend bien, une fois les tests du BIOS terminé, le bootloader va décompresser le fichier vmlinuz qui contient un noyau Linux.
Celui-ci, compilé de façon modulaire, ne sait pas lire les systèmes de fichers ext3, XFS…ou est stocké mon système.
Donc il utilise un RAM disk pour charger les modules du kernel qui, eux, vont permettre d’aller lire les systèmes de fichiers.
Ensuite, il y a un genre de chroot qui est fait depuis le vmlinuz vers le système installé sur disque.
C’est ça ?
Merci
Oui, parfois l’initrd est plus subtil, dans l’installateur debian, il comporte tout le système d’installation. J’ai fait une clef USB où l’initrd est tout un système de fichiers complet donc quoi qu’il arrive, le système est chargé et marche, etc.
quote="ed"
Sinon, pourquoi pas tout mettre en dur, tout simplement parceque pas mal de pilotes sous linux sont carrément incompatible entre eux, que ça prendrais une taille monstre en mémoire, et que pas mal de pilotes ne fonctionnent plus dutout en dur comme avant… (Exemple le driver, pourtant surutilisé, du chipset de ma carte mère, ICH8…)[/quote]
Mes machines à la maison bootent sans initrd et mon noyau est au contraire dégraissé de tous les modules de controleurs ou de cartes pci que je n’utiliserais jamais, etc… Sans tout mettre en dur, en mettant en dur le controleur IDE et le systême de fichier de la racine, c’est bon.
Pour ton ich8, si c’est parcequ’il faut passer des options au module, tu peux compiler en dur et passer les arguments au module par le bootprompt, peut être, non ?
quote="Platinium"
Ensuite, il y a un genre de chroot qui est fait depuis le vmlinuz vers le système installé sur disque.
C’est ça ?
(…)[/quote]Oui, exactement, sauf que ça n’est pas tout à fait un chroot, mais un appel system de type pivot_root, qui est d"un usage spécifique à cette partie là du boot:
linux-kheops.com/doc/man/man … oot.2.html
Comme dit fran, pour un systême dit “RIM”, tu te passes de rebasculer la racine sur un support physique avec pivot_root, et tu continues sur l’OS intègralement déployé dans l’initrd.
Ok, merci pour ces infos.
Question subsidiaire: le noyau contenu dans vmlinuz, c’est un noyau dédié à l’amorce du système ? Ou c’est le noyau que j’ai préparé avec mon make menuconfig et compilé ensuite ?
Idem, pour ce qui est de mon RAMdisk, c’est certains modules spécifiques ? Ou c’est les modules qui ont été générés lors de la compil du noyau ?
quote="Platinium"
Question subsidiaire: le noyau contenu dans vmlinuz, c’est un noyau dédié à l’amorce du système ? Ou c’est le noyau que j’ai préparé avec mon make menuconfig et compilé ensuite ?[/quote]Comprend pas trop la question. [quote=“Platinium”]Idem, pour ce qui est de mon RAMdisk, c’est certains modules spécifiques ? Ou c’est les modules qui ont été générés lors de la compil du noyau ?[/quote] C’est une sélection de modules que tu peux affiner: voir le contenu de /etc/initramfs-tools, et surtout initramfs.conf.
Ce que je voulais dire c’est: lorsque je configure et que je compile un noyau, c’est cela qui est contenu dans le fichier vmlinuz lancé au démarrage ?
(je ne me rappelle plus quel est le fichier qui est produit à l’issue de la compilation des soruces du kernel)
Ou c’est un autre noyau linux dédié à l’amorce du système qui est contenu dans vmlinuz ?
Merci
tape make help dans les src du noyau
Je profite que le sujet des modules ai été abordé pour vous demander comment savoir si lors de la configuration du noyau une option que l’on souhaite (un pilote, un système de fichier local, un système de fichier réseau…) doit être coché en module ou en dur?
d’après ce qui a été dit j’ai l’impression qu’il vaut mieux éviter de mettre en dur mais dans ce cas, quels sont les options qui doivent être obligatoirement en dur (système de fichier de la partition / ?)ou qu’on ne peut pas mettre en module?
ps : dslé je pose la question ici car j’ai vu que le sujet a été abordé et qu’il serait peut être pas utile d’ouvrir un poste juste pour ça
merci
Il n’y a pas grand chose qu’on se doit de mettre en dur. Tout est paramétrable dans les options du noyau même et surtout la racine.
Avec initrd, les modules disponibles pour booter sont en ram, dans l"initrd, donc peu importe qu’on les ait mis en dur ou dans le noyau, les modules sont à priori dispos. Les choses à mettre en dur dans le noyau sont juste les composants qui permettent d’accèder à l’initrd.
Sans initrd, on peut se passer en dur de ce qui sert à lire un initrd, mais il faut >au moins< mettre en dur tout ce qui permet d’aller chercher les modules qui manquent pour la suite quelque part, c’est à dire, si c’est pour aller lire /lib/modules, qu’il faut le module qui gère l’IDE, les modules ATA génériques, et le module correspondant au type de filesystem dans lequel se trouve /lib/modules.
Aprés, il y a des trucs qui peuvent mériter d’être en dur ou pas, mais ce sont les seules contraintes AMA qui >obligent< à compiler quoi que ce soit en dur.
Je vous remercie pour vos lumières, j’imagine que l’on peut éditer le fichier de configuration du noyau généré pour remettre en modules les options mises en dur, dites moi si je me trompe
voilà j’arrête d’écarter le sujet initial
[quote=“ReNzO_08”]Je vous remercie pour vos lumières, j’imagine que l’on peut éditer le fichier de configuration du noyau généré pour remettre en modules les options mises en dur, dites moi si je me trompe
(…)[/quote]Tu te trompes: le fichier config que tu trouves dans /boot ne fait qu’indiquer comment est compilé le noyau.
Tu peux l’utiliser comme base en modifiant la config dans ce fichier pour une >nouvelle< compil, mais si tu veux un noyau avec une config différente, il faut le recompiler à chaque modif.
Ok merci pour tout ces éclaircissements
encore désolé pour le squattage Platinium 