Forum Linux.noyau initrd et kernel

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
1
25
fév.
2019

Bonjour à tous,

voila je me suis documenté un peu, et d'apres ce que j'ai compris mais n'hésitez pas à me corriger, le bootloader lance le programme initrd puis ensuite le noyau en lui donnant en paramètre ou se trouve initrd dans la ram. Et donc le noyau a chaque fois qu'il doit acceder à un fichier dans le disque dur il fait un saut en memoire vers le processus initrd, et c'est initrd qui lui donne les octets contenus dans le fichier.

est ce ca ou je n'ai rien compris ?

Merci d'avance pour votre aide.

  • # Pas tout à fait

    Posté par  (site web personnel) . Évalué à 5.

    Non, le chargeur de démarrage lance le noyau. Celui-ci va mettre en place plein de choses, utiliser cet initramfs (qui est juste une archive CPIO, optionnellement compressée) pour lancer init depuis celui-ci. Cet initva faire le nécessaire pour mettre en place le reste du système et passer la main au vrai système init (souvent systemd, de nos jours).

    Debian Consultant @ DEBAMAX

  • # initrd et kernel

    Posté par  . Évalué à 4.

    Je ne crois pas non, c'est plutôt l'inverse.

    Le bootloader lance le kernel et lui indique l'emplacement de la partition racine / et de l'image initrd. Cette image initrd contient des modules pour le noyau et autres par exemple un mini-système de rescue.

    Si l'initrd ne convient pas par exemple si il ne contient pas le module du système de fichier employé pour la partition racine, le kernel ne peut pas monter / et plante. A l'opposé un kernel avec les options nécessaires compilées en dur et non sous forme de modules pourra démarrer sans initrd juste avec l'indication de la partition racine.

    • [^] # Re: initrd et kernel

      Posté par  . Évalué à 2. Dernière modification le 26 février 2019 à 10:22.

      je ne comprend pas trop l'utilité de initrd.

      dans les 512 premiers octets du disque dur on a le partitionnement, donc on sait ou commence et se termine la partition active.

      dans la partition on a les métadonnées qui possède la taille des blocs, les bitmap des blocs et inodes, les inodes. Donc du moment qu'on connait le systeme de fichier utilisé (ext2, ext3 …) on peut tres bien recréer facilement le systeme de fichier utilisé. donc pour moi initrd n'a aucun interet

      Merci pour vos réponses

      • [^] # Re: initrd et kernel

        Posté par  (site web personnel) . Évalué à 2.

        C'est le problème de la poule et de l’œuf : pour démarrer, on a besoin de modules, pour accéder aux modules, on a besoin de lire un système de fichier, donc d’accéder aux disques, et les pilotes disques sont parfois … en module.

        Un exemple : dans le monde pro, on utilise assez souvent des volumes RAID, avec une carte matérielle et donc des pilotes spécifiques. L'initrd permet d'embarquer ces pilotes et donc de pouvoir lire les systèmes de fichiers.

        • [^] # Re: initrd et kernel

          Posté par  . Évalué à 2.

          Voilà tout dépend si l'option correspondant au système de fichier est compilé en dur dans le noyau ou en module. La plupart du temps c'est en module et lors du processus d'installation il y a création d'un initrd correspondant aux options choisies et au matériel détecté.

          En reprenant l'exemple d'une partition principale avec un système de fichier ext2 il est facile de le vérifier sur un système actif avec lsmod s'il y a le module ext2 et sur un système inactif comme depuis un livecd par exemple dans les modules présents dans /lib/modules . Si il y a bien n module ext2 c'est donc qu'il faudra un initrd même minimal avec juste ext2. Si il n'y a pas de module ext2 et que le noyau a booté quand même c'est qu'il est compilé en dur.

          Si on veut booter sans initrd ( est-ce que le jeu en vaut la chandelle ? ) il suffit de recompiler le noyau avec les mêmes options sauf pour le système de fichier utilisé. Les autres modules ne sont pas critiques et pourront être lancés par un modprobe après démarrage comme la carte graphique, usb, carte réseau etc ..

          En recompilant le noyau et en passant beaucoup de choses en dur, en virant tout les modules inutiles et juste réglé le type de cpu, j'avais plus de mémoire libre en démarrant à peu près 30mo pour le kernel lancé avec init=/bin/bash au lieu de 60mo pour le noyau de la distribution et en démarrage normal il me semble que le système était un poil plus réactif, plus à cause du réglage du cpu que des fonctionnalités inutiles gelées en mémoire.

          Je posais la question de savoir si le jeu en valait la chandelle car la compilation du noyau et des modules prend un certain temps suivant la puissance de la machine, et les possibilités d'erreur sont nombreuses, pour certains périphériques usb (webcam) qui pourtant fonctionnait bien avec le noyau générique je n'ai jamais trouvé la bonne option.

          C'est les mêmes gains qui peuvent être substantiels et les mêmes déboires (mauvaises options choisies ou perte de temps) pour les distributions basées sur les sources, en recompilant tout le système + les logiciels.

          • [^] # Re: initrd et kernel

            Posté par  . Évalué à 2.

            Avec Fedora je viens d'essayer on peut se passer d'intrd si le rootfs est en ext4.

            En effet le support de l'ext4 n'est pas un module mais est en dur dans le noyau Linux de Fedora.

      • [^] # Re: initrd et kernel

        Posté par  (site web personnel) . Évalué à 3.

        Un initramfs ça permet de faire notamment : du RAID, du LVM, du LUKS (même si l'arrivée de la gestion cryptodisks dans GRUB change un peu le dernier point). Et tout plein d'autres choses (comme embarquer un serveur SSH minimaliste pour attendre une connexion et la saisie d'une phrase de passe pour déverrouiller le reste du système).

        Un initramfs ça signifie aussi pouvoir utiliser le noyau proposé par sa distribution tout en étant capable de générer des éléments personnalisés dépendant de la configuration déployée sur une machine donnée, plutôt que de s'amuser à compiler un noyau aux petits oignons avec le minimum de modules.

        Pour information, la liste des paquets dans Debian 9 qui fournissent des fichiers dans la hiérarchie initramfs-tools, ce qui dépasse largement les mdadm, lvm2, cryptsetup correspondant aux fonctionnalités citées en introduction :

        kibi@armor:~$ apt-file search /usr/share/initramfs-tools/|awk -F: '{print $1}'|sort -u
amd64-microcode
aoetools
bcache-tools
bilibop-lockfs
bilibop-rules
bootcd
brltty
btrfs-progs
busybox
busybox-static
cloud-initramfs-dyn-netconf
cloud-initramfs-growroot
cloud-initramfs-rescuevol
cryptsetup
debian-edu-config
dmraid
dmsetup
dropbear-initramfs
fsprotect
fuse
glx-alternative-nvidia
initramfs-tools-core
intel-microcode
iscsiuio
klibc-utils
kmod
kxc
live-boot-initramfs-tools
ltsp-client-core
lvm2
mandos-client
mdadm
multipath-tools-boot
nbd-client
ntfs-3g
open-infrastructure-system-boot
open-iscsi
open-vm-tools-dkms
plymouth
r8168-dkms
sg3-utils-udev
tuxonice-userui
udev
uswsusp
v86d
yubikey-luks
zfs-initramfs
zfsutils-linux

        Debian Consultant @ DEBAMAX

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.