Un démarrage avec ramdisk alors que installé sur disque dure : pourquoi ? [Résolu]

[Hibou57]

Je regardais tranquillement la liste des fichiers d'une installation Débian, et je vois dans le /boot, avec l'image du noyau, l'image d'un ram disk.

Mais à quoi peut bien servir un demarrage avec un ram disque alors que le système est installé sur un disque dure ? Quel intérêt y at-il à ne pas monter le système de fichier du disque dur directement ? Surtout que pour charger l'image du ram-disk, il faut bien accéder au disque dur de toutes-manières.

Et ça se configure comment ? Rdev ?

[chaval]

Salut !

alors, oui et non...

Tu utilises un système précompilé.
Etant donné que le noyau doit ete le plus générique possible, beaucoup de modules sont chargés "a la volée".
Le ramdisk permet entre autres de stoker une image de ces modules, qui seront disponibles avant meme d'acceder à tes partitions entant que telles (cer bien souvent, le noyau n'a pas la prise en charge de tes systèmes de fichiers en natif)
C'est donc grub (ou lilo) qui permettent au noyau de trouver ce fichier avant meme de monter les partitions.

Désolé pour les puristes d'avoir fait pas mal de raccourcis..

[Hibou57]

Envoyé par chaval

Le ramdisk permet entre autres de stoker une image de ces modules, qui seront disponibles avant meme d'acceder à tes partitions entant que telles

Mais si GRUB peut accéder à la partition de Linux, alors le noyau de Linux en est probablement capable également, et sans charger de modules supplémentaires.

On pourrait peut-être imaginer le cas d'une installation où le noyau serait stoqué sur une partition, et le système de fichier à monter comme racine sur une autre partition, et que cette autre partition ne soit pas accessible sans charger certains modules.

Mais ce cas est certainement rare, pour deux raisons. La première est que les supports non pris en charge par le noyau sans chargement de modules supplémentaires sont assez rare (IDE et SCSI sont pris en charge le plus souvent nativement). La deuxième raison est que stoqué le noyaux sur une partition différente de celle contenant l'image du noyau n'est probablement pas courant.

Rassembler ces deux conditions est sûrement rare, et cette installation ne devrait donc pas être une installation par défaut, mais une installation à reserver à des cas particulier.

Le RAM disque est comprehensible lors d'une procédure d'installation, mais le voir persister sur une installation faite, et en plus, sur une installation sur du matériel banal et standard, ressemble à du gaspillage.

[Celelibi]

Le problème n'est pas de lire le disque, mais de lire le système de fichiers.
Étant donné la quantité de système de fichiers différents qui peuvent être utilisés comme partition racine, il est n'est pas possible de les intégrer tous en dur dans le noyau (sinon tu te retrouve avec un noyau vraiment énorme).
Mais si le driver du fs racine n'est pas chargé au démarrage, il est impossible de lire le disque pour aller chercher les drivers (sous forme de module noyau sous linux).
On tourne en rond.

La solution c'est d'utiliser un ramdisk qui est une image de la RAM contenant le noyau et quelques modules essentiels.
Au démarrage, au lieu de charger le noyau (qui charge ensuite les modules nécessaire qu'il lit sur le disque), le ramdisk va être chargé en mémoire, ce qui va charger le noyau et les modules présents dans ce ramdisk.

Le ramdisk permet donc d'avoir un noyau générique qui marchera sur une grande majorité de machines sans que celui-ci ne soit énorme.
Le ramdisk devra cependant être recréé pour chaque machine où ce noyau devra être installé. Mais la création d'un ramdisk est plus simple et plus facilement automatisable que la compilation d'un noyau.

Cela dit, rien ne t'empêche de compiler ton propre noyau en mettant en dur ce qui t'es indispensable et ainsi te passer de ramdisk. Ton système devrait démarrer un chouilla plus vite.

[chaval]

Envoyé par Hibou57

On pourrait peut-être imaginer le cas d'une installation où le noyau serait stoqué sur une partition, et le système de fichier à monter comme racine sur une autre partition, et que cette autre partition ne soit pas accessible sans charger certains modules.

Mais ce cas est certainement rare, pour deux raisons. La première est que les supports non pris en charge par le noyau sans chargement de modules supplémentaires sont assez rare (IDE et SCSI sont pris en charge le plus souvent nativement). La deuxième raison est que stoqué le noyaux sur une partition différente de celle contenant l'image du noyau n'est probablement pas courant.

Rien n'est inclus "nativement" dans le noyau. C'est à la discresstion de la personne qui le compile....

D'ailleurs, sur ma debian, (noyau par défaut) le support de l'ext3 est en module

[Hibou57]

Aluuuuuuuuuuut CeliBibi

Ca fait longtemps qu'on t'avais pas vu ici

Envoyé par Celelibi

Mais si le driver du fs racine n'est pas chargé au démarrage, il est impossible de lire le disque pour aller chercher les drivers (sous forme de module noyau sous linux).

Oui, mais GRUB, pour charger le RAM-disk, il faut bien qu'il accède au FS, puisque dans mon cas au moins, le RAM-disk est sur le FS. Et GRUB affiche d'ailleurs le nom du FS qu'il trouve au "démarrage" d'une partition.

Ca me fait penser à une chose que je crois avoir remarqué sur la plupart des installations de Linux : elles restent presque toujours plus ou moins dans l'état du stade d'installation. Je pense d'ailleurs à me documenter sur les divers moyen de finaliser une installation (nettoyer certains fichiers inutiles dans le /usr/doc - comme les history, éliminer les ram-disk inutile, décompresser l'image du noyau, etc).

Mais en même temps, rester dans l'étât le système était pendant sa phase d'installation, peut garantir un fonctionnement plus fiable (c'est vrai que cette Débian fonctionne même mieux que mon ouvre-boite)

Envoyé par Chaval

D'ailleurs, sur ma debian, (noyau par défaut) le support de l'ext3 est en module

C'est peut-être parce que l'utilisation de ext3 n'est pas automatiquement le meilleure choix pour une installation. Si tu l'as installé sur une petite machine, ça pourrais expliquer la chose (à mon avis, le ext3 n'est pas fait pour les petit disque, du genre 500M par exemple)

[chaval]

Si tu veux éliminer les ramdisks, il faut, comme on te l'a dis, compiler ton noyau

D'un autre coté, pour l'ext3, c'est quand meme depuis quelques années le choix par défaut des outils de partitionnement lors de l'installation de linux.
si c'est un choix par défaut, ca aurait pu etre compilé en dur dans le noyau non ?


Bon, après, ton ramdisk, c'est pas quelque chose de si méchant que ca, non ?

[Hibou57]

Envoyé par chaval

Bon, après, ton ramdisk, c'est pas quelque chose de si méchant que ca, non ?

Non, mais il ne faut pas attendre qu'une chose soit méchante pour s'y interesser. C'est aussi que je prévois toujours de me repencher sur les petites configurations, et que dans ce cas là, un RAM-disk de 4M est problématique.

[Celelibi]

Envoyé par Hibou57

Aluuuuuuuuuuut CeliBibi

Un jour tu arriveras à ne pas écorcher mon pseudo...

Envoyé par Hibou57

Oui, mais GRUB, pour charger le RAM-disk, il faut bien qu'il accède au FS, puisque dans mon cas au moins, le RAM-disk est sur le FS. Et GRUB affiche d'ailleurs le nom du FS qu'il trouve au "démarrage" d'une partition.

Je m'y attendais à celle-là.
Pour ce que j'en sais, lilo stocke dans le "stage 2" la liste des blocs où se trouvent le noyau à charger. Donc aucune réelle lecture du système de fichier.
Grub, lui, tente de lire comme il peut le système de fichier pour trouver le(s) noyau(x) bootable. Bien entendu il ne possède qu'une gestion minimaliste des systèmes de fichier.
Dans les deux cas, il y a bien une lecture du système de fichier, mais celle-ci est vraiment minimale ; il y a juste de quoi lire les données à charger.

Tu pourrais me dire que le noyau n'a qu'à, lui aussi, intégrer une gestion des fs à la grub le temps de charger le vrai module qui gère pleinement le système de fichier.
Ça pourrait se faire, mais le noyau serait plus gros et le code du système VFS serait plus complexe (Virtual File System, il permet une abstraction des systèmes de fichiers dans le code du noyau). De plus ça limiterait Linux à booter sur certains systèmes de fichiers et pas d'autres et donc cette méthode ne pourrait pas être utilisée dans tous les cas. Tout ceci multiplie les cas à gérer, alors qu'en informatique on aime bien ne pas avoir de cas particuliers.

Si ces arguments ne sont pas convaincants, dis-toi que c'est simplement un choix.

[Hibou57]

Envoyé par Celelibi

Un jour tu arriveras à ne pas écorcher mon pseudo...

Nananananèèère

Pour ce que j'en sais, lilo stocke dans le "stage 2" la liste des blocs où se trouvent le noyau à charger. Donc aucune réelle lecture du système de fichier.

Voilà ce qu'il en est pour GRUB :

Code Console :

1
2
3
4
5
6
7
8
9
10
11
12
 
# Liste des fichiers dans /usr/lib/grub/i386-pc
 
-rw-r--r-- 1 root root   7584 Mar 30  2007 e2fs_stage1_5
-rw-r--r-- 1 root root   7424 Mar 30  2007 fat_stage1_5
-rw-r--r-- 1 root root   8192 Mar 30  2007 jfs_stage1_5
-rw-r--r-- 1 root root   6848 Mar 30  2007 minix_stage1_5
-rw-r--r-- 1 root root   9280 Mar 30  2007 reiserfs_stage1_5
-rw-r--r-- 1 root root    512 Mar 30  2007 stage1
-rw-r--r-- 1 root root 108360 Mar 30  2007 stage2
-rw-r--r-- 1 root root 108360 Mar 30  2007 stage2_eltorito
-rw-r--r-- 1 root root   8904 Mar 30  2007 xfs_stage1_5

On voit que les stages de LILO semblent exister avec GRUB également. Je donne pas le résultat d'un cat d'exemple, mais j'ai put voir que ce ne sont pas des executables, et donc pas de vraies librairies. Ce sont des fichiers binaires.

On voit aussi que GRUB ne supporte pas directement tout les types de fichiers, et que c'est sûrement configurable.

Comme il y a des fichiers stagexxxx1_5 pour plusieurs systèmes de fichiers inexistants sur cette machine, ça ne peut pas être des fichiers stage comme ceux que tu décrit pour LILO. Mais en tous cas, le principe a l'air d'être le même.

Je n'ai pas testé si ce sont des executables ou si ce sont des données, parce que je n'ai pas d'utilitaires pour faire un dump assembleur.

Si ces arguments ne sont pas convaincants, dis-toi que c'est simplement un choix.

Si, si, ... convaincu. C'était même interessant

Comme ça je comprends bien les cas dans lesquels je peux le laisser et les cas dans lesquels ça peut être changé.

Mici bacoup

[Celelibi]

Envoyé par Hibou57

Comme il y a des fichiers stagexxxx1_5 pour plusieurs systèmes de fichiers inexistants sur cette machine, ça ne peut pas être des fichiers stage comme ceux que tu décrit pour LILO. Mais en tous cas, le principe a l'air d'être le même.

Une fois installé, le stage 1 est logé dans la MBR sur disque (le tout premier bloc du disque physique, tu sais, le truc terminé par 55AA ), le stage2, lui est stocké dans le premier secteur de la partition à amorcer. Ce premier secteur est en dehors du système de fichier (il est carrément avant le super bloc qui lui-même précède tout le système de fichier).

Je pense que quand on exécute la commande lilo et qu'elle lit le fichier /etc/lilo.conf, elle écrit dans le(s) blocs d'amorçage son code du stage 2 avec des données indiquant quels sont les blocs à lire pour charger le noyau.

Pour grub le sais pas trop. Si quelqu'un trouve de la doc technique sur le fonctionnement de lilo ou grub je suis preneur.

Je n'ai pas testé si ce sont des executables ou si ce sont des données, parce que je n'ai pas d'utilitaires pour faire un dump assembleur.

La commande file te donne rien ? (par "rien" je veux dire qu'il dit juste "data").