Si, à condition de ne pas avoir besoin des modules qui sont dedans pour monter la racine et donc d’avoir compilé tout le nécessaire “en dur”.
D’accord, je sors.
Salut PascalHambourg, salut à tous 
Si, à condition de ne pas avoir besoin des modules qui sont dedans pour monter la racine et donc d’avoir compilé tout le nécessaire “en dur”.
D’accord, je sors.[/quote]
Oui bien sur +1, si on met tout en dur on à même pas besoin d’initrd au fond 
[quote=“Marvin_R”]De quel est le répertoire de compilation ? /lib/modules ? /lib/modules/2.6.31.6 ?
A quoi servent les 2 lignes de commandes ci dessus ? Je ne comprend pas trop leur utilité.[/quote]
Et bien dans /usr/src
Ce n’est pas là que tu as compiler la première fois?
La première ligne de commande sert à nettoyer toute trace de configuration antérieure, elle est recommandée par les développeurs même sur une archive fraîchement déballée.
La seconde c’est pour récupérer le fichier de configuration du noyau en cours d’utilisation,
qui se trouve dans /boot
Ce serait intéressant pour toi de voir ce qui se trouve dans ce répertoire:
@+
Il me semble qu’un initrd reste nécessaire dans certains cas particuliers où on a besoin de programmes userland pour accéder au volume racine : LVM, volume chiffré… Ces programmes userland n’étant pas liés à une version particulière du noyau contrairement aux modules, l’initrd d’une autre version de noyau devrait fonctionner.
Salut à tous
Il me semble qu’un initrd reste nécessaire dans certains cas particuliers où on a besoin de programmes userland pour accéder au volume racine : LVM, volume chiffré… Ces programmes userland n’étant pas liés à une version particulière du noyau contrairement aux modules, l’initrd d’une autre version de noyau devrait fonctionner.[/quote]
Oui un initrd c’est nécessaire, pour faire démarrer un kernel sans, il faut être franchement doué et avoir vraiment tout compris.
Dans LFS il n’est pas inclus l’utilisation d’un initrd.img, ni aucun outil compilé pour le réaliser d’ailleurs.Tout doit être mis en dur.
C’est pour ça que j’ai galéré 
Je ne suis pas de cet avis, au contraire. J’ai toujours compilé mes noyaux sans initrd (depuis la série 2.2 dans Debian potato), car j’ai trouvé cela bien plus simple. Il m’a fallu beaucoup de temps pour comprendre à peu près le fonctionnement d’un initrd (le changement de format initrd -> initramfs n’a pas aidé). Bien sûr je n’ai pas de racine qui nécessite une intervention en userland. Pas besoin de “tout mettre en dur” mais seulement les pilotes de périphériques et le système de fichier nécessaires pour monter la racine. La plus grosse erreur que j’ai faite est d’oublier d’activer le pilote clavier PS/2 lors du passage de la série 2.4 à 2.6. Ça bootait, mais pas de clavier !
Je ne suis pas de cet avis, au contraire. J’ai toujours compilé mes noyaux sans initrd (depuis la série 2.2 dans Debian potato), car j’ai trouvé cela bien plus simple. Il m’a fallu beaucoup de temps pour comprendre à peu près le fonctionnement d’un initrd (le changement de format initrd -> initramfs n’a pas aidé). Bien sûr je n’ai pas de racine qui nécessite une intervention en userland. Pas besoin de “tout mettre en dur” mais seulement les pilotes de périphériques et le système de fichier nécessaires pour monter la racine. La plus grosse erreur que j’ai faite est d’oublier d’activer le pilote clavier PS/2 lors du passage de la série 2.4 à 2.6. Ça bootait, mais pas de clavier ![/quote]
Re,
ce qui me donne bien envie de retenter le coup la prochaine fois sans initrd
initrd, il sert à quoi concretement car je crois que j’ai une vague idée de son utilité.
Comment virer initrd ?
general initrd support … (initaial RAM disk)
passer des heures à compiler et remettre le initrd , je ne vois vraiment pas l’intérêt.
(sauf disposer d’un parc de machines différentes … et les raisons cité par Pascal, que j’ai d’ailleurs même pas compris … trop compliqué pour moi 
)
enfin, avantages sans:
boot rapide
taille du kernel (avec les machines récentes c’est négligeable)
rapidité de chargement des modules (les modules sont dans le kernel donc pas de temps de chargement)
choix de la bonne architecture (un Amd athlon tourne en i386 mais appliquer les spécificité c’est encore mieux)
désactiver les option inutiles (modules du matériel inexistant)
avantages avec:
compatibilité avec énormément de machines
L’initrd a comme fonctionner de trouver le système racine, de charger les moidules nécessaires à sa lecture, de monter la partition et de lancer init.
Il suffit de mettre en dur ce qui est nécessaire au montage de la partition et de l’indiquer correctement dans le grub/lilo. En général c’est le support du disque dur correspondant + le module ext3 + la page de code éventuelle (à vérifier?) +
[quote=“dchost99”]avantages sans (initrd) :
boot rapide
taille du kernel (avec les machines récentes c’est négligeable)
rapidité de chargement des modules (les modules sont dans le kernel donc pas de temps de chargement)
choix de la bonne architecture (un Amd athlon tourne en i386 mais appliquer les spécificité c’est encore mieux)
désactiver les option inutiles (modules du matériel inexistant)[/quote]
Ce sont les avantages de l’optimisation des options de compilation du noyau, et non de l’absence d’initrd. L’utilisation d’un initrd n’empêche pas d’optimiser le noyau pour une architecture, de mettre en dur les modules nécessaires au montage de la racine et de désactiver les options inutiles.
Ça c’était avant, au temps où l’initrd était vraiment un initrd (initial ramdisk). Maintenant l’initrd est plutôt un initramfs (initial ram filesystem) et non seulement son format mais aussi sa philosophie a changé : il est devenu le système de fichiers racine, dont la finalité n’est pas forcément de monter un autre système de fichiers racine définitif même si c’est encore le cas le plus fréquent. A noter que l’initrd/initramfs peut être intégré directement dans l’image du noyau.
[quote=“PascalHambourg”][quote=“dchost99”]avantages sans (initrd) :
Ce sont les avantages de l’optimisation des options de compilation du noyau, et non de l’absence d’initrd.
Ça c’était avant, au temps où l’initrd était vraiment un initrd (initial ramdisk). Maintenant l’initrd est plutôt un initramfs (initial ram filesystem) et non seulement son format mais aussi sa philosophie a changé : il est devenu le système de fichiers racine, dont la finalité n’est pas forcément de monter un autre système de fichiers racine définitif même si c’est encore le cas le plus fréquent. A noter que l’initrd/initramfs peut être intégré directement dans l’image du noyau.[/quote][/quote]
Pas compris la nuance Pascal (j’aimerais comprendre :smt003 ):
si je comprend bien au départ, c’était de charger les modules (ext2,3 , sata, ata, chipset ide : intégré à l’image initrd.bz) pour avoir l’accès au disque racine avec le rootfs et ensuite un pivot root …
La il est devenu “le système de fichier”? (en mode crypté? parce que on intègre les pilotes des FS? le rootfs reste physique sur ext2,ext3… avec une sorte de unionfs avec la ram?)
intégré au kernel ? wow, la j’ai du mal , je crois que j’ai raté la partie initramfs.
fais nous un “initramfs pour les nuls” dans Astuce 
Oui et non, la seule différence est que le ramfs permet d’avoir un système de fichier potentiellement de la taille de la RAM (alors que l’initrd était limité à une taille fixe). Mais la plupart des initrd (à commencer par ceux de Debian se termine par un run-init qui fait un pivot_root sur le répertoire donné en argument. À noter que ce run-init est d’un fonctionnement complexe (je me suis arraché quelques cheveux avant d’arriver à le faire fonctionner comme je voulais pour ClefAgreg).