Aidez-moi s.v.p.
boncoeur
-
boncoeur -
boncoeur -
Pouvez-vous m'aider à répondre ces questions !
1) De quelle façon pouvons-nous vérifier si notre noyau Redhat support ou non le NTFS ?
2) Dans quel cas le RAMDisk initrd ne serait pas nécessaire ?
3)Si nous désativons le chargement de initrd au démarrage, est ce qu'on peut démarrer le système ? Est ce qu'il sera en mot Single ?
4) Pour quel niveau d'exécution /sbin/init n'est pas exécuté ?
Merci beaucoup pour vos réponses
1) De quelle façon pouvons-nous vérifier si notre noyau Redhat support ou non le NTFS ?
2) Dans quel cas le RAMDisk initrd ne serait pas nécessaire ?
3)Si nous désativons le chargement de initrd au démarrage, est ce qu'on peut démarrer le système ? Est ce qu'il sera en mot Single ?
4) Pour quel niveau d'exécution /sbin/init n'est pas exécuté ?
Merci beaucoup pour vos réponses
4 réponses
1.) Linux supporte ntfs en lecture (pas en ecriture sans driver special, chercher google avec "captive linux" un driver special). Redhat ne supporte pas ntfs par default car il ne fournissent pas le module "ntfs.o" precompile (d'ailleur comme Fedora). Il faut reconfigurer et recompiler le noyau pour avoir ce module.
2.) Dans la config noyau (avant compilation du noyau) tu dois mettre ext3 directement dans le noyau et pas en module et il ne faut pas avoir de disque scsi (et peut-etre meme sata) comme 1er disque de boot (par contre 1er disque ide et 2nd disque scsi/sata irait tres bien). Dans ces conditions tu n'as pas besoin d'initrd et dans /etc/lilo.conf ou /etc/grub.conf il faut prevoire une entree de boot ou il n'y a pas de reference a "initrd".
Si tu as un disque scsi/sata comme 1er disque tu peux apres compilation du noyau et apres installation de modules creer l'initrd avec (en root apres "su -"):
ici <version_noyau_compile> c'est la version exacte (avec tout le baratin) de ton noyau compile et /boot/initrd-new sera le fichier de l'initrd (je propose le "-new" pour ne pas ecraser l'ancien fichier). Il se peut que les options sont un peu differentes chez toi, verifies avec "man mkinitrd" comment il faut faire exactement.
Apres dans lilo.conf ou grub.conf on met une reference a "initrd-new" pour ce noyau.
3. Si c'est uniquement le ext3 le pb (car seulement compile en module) je crois on peut meme demarrer apres avoir enleve la ligne avec "initrd" dans lilo.conf/grub.conf. En principe ca marche car il pourra faire un mount en ext2 pour le 1er mount en read-only et apres il chargera le module depuis le disque et apres il refera le vrai mount en ext3.
Donc ca marche mais je crois c'est tres risque en cas de pepin, car de monter une partition ext3 (avec journal) qui n'est pas en etat "clean" (propre) en mode ext2 (qui ne peut reparer avec le journal) peut boussiler le formattage de la partition.
Donc compiler le noyau avec ext3 en directe et pas en module est la bonne solution.
4. Cette commande permet de changer le runlevel. Si tu poses la question pour le pb d'initrd (le noyau fait justement un message d'erreur ambigue "no init" found) c'est autre chose (ca veut dire "no initrd found") et avec les reponses precedentes cette question n'est plus pertinente.
2.) Dans la config noyau (avant compilation du noyau) tu dois mettre ext3 directement dans le noyau et pas en module et il ne faut pas avoir de disque scsi (et peut-etre meme sata) comme 1er disque de boot (par contre 1er disque ide et 2nd disque scsi/sata irait tres bien). Dans ces conditions tu n'as pas besoin d'initrd et dans /etc/lilo.conf ou /etc/grub.conf il faut prevoire une entree de boot ou il n'y a pas de reference a "initrd".
Si tu as un disque scsi/sata comme 1er disque tu peux apres compilation du noyau et apres installation de modules creer l'initrd avec (en root apres "su -"):
mkinitrd /boot/initrd-new <version_noyau_compile>
ici <version_noyau_compile> c'est la version exacte (avec tout le baratin) de ton noyau compile et /boot/initrd-new sera le fichier de l'initrd (je propose le "-new" pour ne pas ecraser l'ancien fichier). Il se peut que les options sont un peu differentes chez toi, verifies avec "man mkinitrd" comment il faut faire exactement.
Apres dans lilo.conf ou grub.conf on met une reference a "initrd-new" pour ce noyau.
3. Si c'est uniquement le ext3 le pb (car seulement compile en module) je crois on peut meme demarrer apres avoir enleve la ligne avec "initrd" dans lilo.conf/grub.conf. En principe ca marche car il pourra faire un mount en ext2 pour le 1er mount en read-only et apres il chargera le module depuis le disque et apres il refera le vrai mount en ext3.
Donc ca marche mais je crois c'est tres risque en cas de pepin, car de monter une partition ext3 (avec journal) qui n'est pas en etat "clean" (propre) en mode ext2 (qui ne peut reparer avec le journal) peut boussiler le formattage de la partition.
Donc compiler le noyau avec ext3 en directe et pas en module est la bonne solution.
4. Cette commande permet de changer le runlevel. Si tu poses la question pour le pb d'initrd (le noyau fait justement un message d'erreur ambigue "no init" found) c'est autre chose (ca veut dire "no initrd found") et avec les reponses precedentes cette question n'est plus pertinente.
Merci infiniment pour tes réponses !
Permettez-moi d'ajouter quelques info auprès tes réponses.
Tous ce que tu dis, sont corrects. Je veux just ajouter à tes réponses d'après quelque lecture sur Internet.
1) j'ai trouvé la commande:
# cat /proc/filesystems
qui va nous afficher tous les systemes de fichiers supportés de notre Version.
2) Merci pour la commande de créer une nouvelle initrd
# mkinitrd /boot/initrd-new <version_noyau_compile>
Peux tu m'éclaisir un peu plus la différence entre ext2 et ext3 ?
Comme tu dis ext2 n'écrit pas de journalier, parcontre ext3 oui.
Mais quand les fichiers vont etre ext2 et quand ext3 ? D'apres tes explications, je comprend que les modules ou pilotes à monter sont en ext2 et ceux qui sont intégrés dans Kernel sont ext 3 ???
4) Mettons, nous ne ferons pas les 3 questions avantes. Pour quel niveau d'exécution /sbin/init n'est pas exécuté ?
Niveau 0, 1, 2, 3
et Single
En devinant, je dirai le Single mode par ce que c'est le seul qui n'existe pas dans /etc/inittab ?
Merci encore kmf
Permettez-moi d'ajouter quelques info auprès tes réponses.
Tous ce que tu dis, sont corrects. Je veux just ajouter à tes réponses d'après quelque lecture sur Internet.
1) j'ai trouvé la commande:
# cat /proc/filesystems
qui va nous afficher tous les systemes de fichiers supportés de notre Version.
2) Merci pour la commande de créer une nouvelle initrd
# mkinitrd /boot/initrd-new <version_noyau_compile>
Peux tu m'éclaisir un peu plus la différence entre ext2 et ext3 ?
Comme tu dis ext2 n'écrit pas de journalier, parcontre ext3 oui.
Mais quand les fichiers vont etre ext2 et quand ext3 ? D'apres tes explications, je comprend que les modules ou pilotes à monter sont en ext2 et ceux qui sont intégrés dans Kernel sont ext 3 ???
4) Mettons, nous ne ferons pas les 3 questions avantes. Pour quel niveau d'exécution /sbin/init n'est pas exécuté ?
Niveau 0, 1, 2, 3
et Single
En devinant, je dirai le Single mode par ce que c'est le seul qui n'existe pas dans /etc/inittab ?
Merci encore kmf
Le ext3 n'est rien d'autre que ext2 avec journale de recuperation en plus.
(Regardes les deux fichiers ext2.txt et ext3.txt dans les sources de noyau dans le sous-repertoire: Documentation/filesystems/...)
Par consequent on peut monter une partition ext3 en mode ext2 et lire et ecrire les fichiers mais le journal de recuperation ne sera pas correctement actualise!!
Si on fait apres un mount d'une partion ext3 en mode ext2 un "umount" propre tel que l'etat de la partition reste "clean" il n'y a pas de problemes. Tout est bon!
Par contre si il y a plantage et l'etat de partition devient "unclean" (ou "dirty") la il peut y avoir un probleme tres grave!! Dans ce cas il faut absoluement faire la commande "fsck <partition>" avant d'essayer de remounter en mode "ext3".
Si on ne fait pas ca et si on reboote simplement le driver ext2 ou ext3 verra que la partition est "unclean". Avec un vieux linux (en ext2) ca lancerait le fsck qui verifie et repare correctement la partion et ca serait tres bien.
Mais avec un nouveau linux (en ext3) il va essayer d'utiliser le journal de recuperation pour reparer, sauf ce journal n'est pas a jour et cette reparation se transforme en destruction du formatage de la partition (disons au moins en endommagement grave).
Apart ca il faut ajouter que pendant le boot il y a toujour un 1er mount en lecture de la partion racine pour la verification du disque. Ce mount peut se faire en ext2 comme en ext3. Si c'est fait en ext2 ca permet de lire le module ext3 depuis le disque dur (au lieu depuis l'init-ramdisk).
Apres il y a un "remount" en ecriture mais maintenant en ext3 car le module a ete charge! J'ai essaye ca une fois et ca marche en effet (sur ma machine). Le message d'erreur du noyau (avec no init found) est seulement parceque les options de lilo/grub lui demande de chercher l'initrd qu'il ne trouve pas. Si on enleve ces options ca va marcher comme decrit ci-dessus. Mais ca me parrait comme meme un peu dangereux s'il y a un pepin/plantage entre le 1er mount en ext2 et 2nd mount en ext3 pour des raisons decrites ci-dessus. Peut-etre je me trompe et le fait que le 1er mount n'est qu'en lecture suffit d'eviter la catastrophe meme dans un tel cas. Cependant il suffit de compiler "ext3" en dur dans le noyau et le probleme n'exite plus.
Pour /sbin/init ca change simplement le run-level avec "/sbin/init <numero>". Comme pendant le boot il y a un parcours de certains runlevels (1,2,3, 5 pour le mode graphique, je crois ?) je suppose que les boot-scripts appellent cette commande chaque fois ils veulent changer le runlevel. Ce n'est pas un daemon qui tourne. Il ne faut pas confondre la commande /sbin/init avec le tout 1er processus "init" qui est lance par le noyau directement apres le boot. C'est ce processus qui fait l'execution des boot-scripts. Celui la est lance tout de suite quand le noyau a fini la detection de la hardware (pour laquelle les drivers sont compiles en directe, pour les modules c'est plus tard).
(Regardes les deux fichiers ext2.txt et ext3.txt dans les sources de noyau dans le sous-repertoire: Documentation/filesystems/...)
Par consequent on peut monter une partition ext3 en mode ext2 et lire et ecrire les fichiers mais le journal de recuperation ne sera pas correctement actualise!!
Si on fait apres un mount d'une partion ext3 en mode ext2 un "umount" propre tel que l'etat de la partition reste "clean" il n'y a pas de problemes. Tout est bon!
Par contre si il y a plantage et l'etat de partition devient "unclean" (ou "dirty") la il peut y avoir un probleme tres grave!! Dans ce cas il faut absoluement faire la commande "fsck <partition>" avant d'essayer de remounter en mode "ext3".
Si on ne fait pas ca et si on reboote simplement le driver ext2 ou ext3 verra que la partition est "unclean". Avec un vieux linux (en ext2) ca lancerait le fsck qui verifie et repare correctement la partion et ca serait tres bien.
Mais avec un nouveau linux (en ext3) il va essayer d'utiliser le journal de recuperation pour reparer, sauf ce journal n'est pas a jour et cette reparation se transforme en destruction du formatage de la partition (disons au moins en endommagement grave).
Apart ca il faut ajouter que pendant le boot il y a toujour un 1er mount en lecture de la partion racine pour la verification du disque. Ce mount peut se faire en ext2 comme en ext3. Si c'est fait en ext2 ca permet de lire le module ext3 depuis le disque dur (au lieu depuis l'init-ramdisk).
Apres il y a un "remount" en ecriture mais maintenant en ext3 car le module a ete charge! J'ai essaye ca une fois et ca marche en effet (sur ma machine). Le message d'erreur du noyau (avec no init found) est seulement parceque les options de lilo/grub lui demande de chercher l'initrd qu'il ne trouve pas. Si on enleve ces options ca va marcher comme decrit ci-dessus. Mais ca me parrait comme meme un peu dangereux s'il y a un pepin/plantage entre le 1er mount en ext2 et 2nd mount en ext3 pour des raisons decrites ci-dessus. Peut-etre je me trompe et le fait que le 1er mount n'est qu'en lecture suffit d'eviter la catastrophe meme dans un tel cas. Cependant il suffit de compiler "ext3" en dur dans le noyau et le probleme n'exite plus.
Pour /sbin/init ca change simplement le run-level avec "/sbin/init <numero>". Comme pendant le boot il y a un parcours de certains runlevels (1,2,3, 5 pour le mode graphique, je crois ?) je suppose que les boot-scripts appellent cette commande chaque fois ils veulent changer le runlevel. Ce n'est pas un daemon qui tourne. Il ne faut pas confondre la commande /sbin/init avec le tout 1er processus "init" qui est lance par le noyau directement apres le boot. C'est ce processus qui fait l'execution des boot-scripts. Celui la est lance tout de suite quand le noyau a fini la detection de la hardware (pour laquelle les drivers sont compiles en directe, pour les modules c'est plus tard).
