Je veux faire un fsck sur ma partition (ReiserFS) Debian sans la monter auparavant. J’essaie avec le cd de Debian mais il essaie tout le temps de monter la partition. Est-ce qu’il y a une façon de le faire ?
Salut,
Prendre un cd-live et faire fsck depuis cet session 
En avez-vous un à me proposer? Avec ceux que j’ai essayé, je n’ai pas réussi.
Salut,
Knoppix
Salut, salut,
Et pourquoi pas un live-cd de Debian? 
http://debian-live.alioth.debian.org/
Un live-cd etch avec gnome en “i386” (cf la section download pour les autres):
http://live.debian.net/cdimage/etch-builds/current/i386/debian-live-etch-i386-gnome-desktop.iso
Bon courage à tous et toutes… 
Méthode 1) Tu quittes gnome et tu coupes l’interface graphique, tu démontes ton disque et tu fsck
Méthode 2) Tu boutes avec l’option init=1 ou éventuellement init=/bin/bash
[quote=“fran.b”]Méthode 1) Tu quittes gnome et tu coupes l’interface graphique, tu démontes ton disque et tu fsck
Méthode 2) Tu boutes avec l’option init=1 ou éventuellement init=/bin/bash[/quote]
Mais dans tous les cas, on ne doit pas pouvoir démonter / ?
Re,
[quote]
Mais dans tous les cas, on ne doit pas pouvoir démonter / ?[/quote]
C’est pourquoi la seule bonne méthode est d’utiliser un cd-live 
rescuecd si knoppix ne te plait pas ! Avec tellement d’autres possibilités qu’il est indispensable (a mon avis)
J’ai essayé le dvd live de Knoppix. J’ai fait fsck et il m’a dit que je devais utiliser l’option --rebuild-tree. Je vais devoir faire un backup de mon disque et refaire un fsck avec --rebuild-tree.
[quote=“Shenga”][quote=“fran.b”]Méthode 1) Tu quittes gnome et tu coupes l’interface graphique, tu démontes ton disque et tu fsck
Méthode 2) Tu boutes avec l’option init=1 ou éventuellement init=/bin/bash[/quote]
Mais dans tous les cas, on ne doit pas pouvoir démonter / ?[/quote]
Aucune importance, elle est montée en ro, tu fais pour en être sur
mount / -o remount,ro
et là tu peux faire un fsck sans problème…
Si il fallait cherche un CD live pour faire un fsck de la racine, on serait mal parti tout de même…
Re,
Quand tu as remonté en ro, comment fsck peut-il corriger une erreur ?
fsck travaille sur le disque pas sur le système de fichiers…
Re,
Très juste, autant pour moi
[quote=“fran.b”][quote=“Shenga”][quote=“fran.b”]Méthode 1) Tu quittes gnome et tu coupes l’interface graphique, tu démontes ton disque et tu fsck
Méthode 2) Tu boutes avec l’option init=1 ou éventuellement init=/bin/bash[/quote]
Mais dans tous les cas, on ne doit pas pouvoir démonter / ?[/quote]
Aucune importance, elle est montée en ro, tu fais pour en être sur
mount / -o remount,ro
et là tu peux faire un fsck sans problème…
Si il fallait cherche un CD live pour faire un fsck de la racine, on serait mal parti tout de même…[/quote]
Ok, merci pour l’info !
il doit y avoir une inversion de termes dans la phrase 
il doit y avoir une inversion de termes dans la phrase [/quote]
Absolument pas, fsck travaille directement sur /dev/hda1 (mettons) donc le disque (la partition) et non à travers le système de fichiers. fsck n’a pas besoin des fonctionnalités ext 2/3 fournies par le noyau et accède directement aux blocs. il utilise le bas niveau.
le problème n’est pas là.
Il n’y a pas un fsck, mais des fsck en fonction du système de fichiers.
:~$ ls /sbin/fsck
/sbin/dosfsck /sbin/fsck.cramfs /sbin/fsck.minix /sbin/fsck.ufs
/sbin/e2fsck /sbin/fsck.ext2 /sbin/fsck.msdos /sbin/fsck.vfat
/sbin/fsck /sbin/fsck.ext3 /sbin/fsck.nfs /sbin/fsck.xfs
(certains sont des liens).
Après avoir déterminé quel est le système de fichiers concerné tel ou tel utilitaire sera utilisé pour corriger les problèmes inhérents à chaque système de fichiers, soit inodes, blocs, etc. etc. Les problèmes ne sont pas sur la partition (à la rigueur des problèmes de chevauchement), mais sur le fs
La partition sert uniquement de cadre. D’ailleurs si ce n’était pas le cas, le fait de monter le fs en ro n’aurait aucun sens. D’aillerus tu parles de blocs, et les blocs font partie du fs. Mais, bien entendu les divers fsck sont indépendants du noyau et du “drivers” du système de fichiers.
le problème n’est pas là.
Il n’y a pas un fsck, mais des fsck en fonction du système de fichiers.
:~$ ls /sbin/fsck
/sbin/dosfsck /sbin/fsck.cramfs /sbin/fsck.minix /sbin/fsck.ufs
/sbin/e2fsck /sbin/fsck.ext2 /sbin/fsck.msdos /sbin/fsck.vfat
/sbin/fsck /sbin/fsck.ext3 /sbin/fsck.nfs /sbin/fsck.xfs
(certains sont des liens).
[/quote]Je n’ai pas dit le contraire, on répare sur un disque (une partition en fait) un système de fichiers. L’utilitaire dépend bien sur du système de fichiers[quote]
Après avoir déterminé quel est le système de fichiers concerné tel ou tel utilitaire sera utilisé pour corriger les problèmes inhérents à chaque système de fichiers, soit inodes, blocs, etc. etc. Les problèmes ne sont pas sur la partition (à la rigueur des problèmes de chevauchement), mais sur le fs
[/quote]Là tu te trompes, tu confonds la table de partition (qui n’est pas en cause ici) et le contenu de la partition, ou bien tu n’as pas le même sens que moi du mot partition (qui désigne pour moi le contenu linéaire de la partition). En clair
dd if=/dev/hda1 of=Image
fsck Image
va faire un réparation de ton système de fichier sur le fichier Image et rendra un fichier Image contenant une partition tout à fait correcte. Tu pourras même faire
dd if=Image of=/dev/hda1
et ta partitiuon sera réparée (sauf si elle est montée en même temps ce qui donnera des résultats curieux).
Tu accèdes à la partition au niveau des blocs et tu la répares. Lorsque tu montes une partition en RO, tu t’interdit de modifier les fichiers sur la partition mais tu peux toujours accéder au «fichier partition» (Image ci dessus, /dev/hda1, …) lui même et le modifier.
Tu confonds la structure logique de la partition (organisation en fichiers, i./e le haut niveau) et la partition elle même (assemblage de blocs). fsck (le fsck concerné en fait) ouvre le «fichier partition» (pas la table, le fichier lui même) et remet une cohérence sur son contenu. De la même manière testdisk ouvre le disque /dev/hda et analyse et éventuellement répare la table de partition. En cas d’échec, il reconstruit une table de partition à partir du contenu du disque.
Donc on est d’accord sur ce point.
Je ne me trompe pas, mais en effet, il faut être certain que nous parlons tous les deux de la même chose. Pour moi, très succintement, une partition est un “marqueur” avec un début et une fin précisant son emplacement sur le disque dur, emplacement appelé à contenir un système de fichiers. D’ailleur on peut créer une partition, et on créera ensuite un système de fichiers, contenu dans cette partition, système de fichiers qui pourra être de taille inférieure à la partition. Mais passons, en réalité je pense que nous parlons de la même chose
[quote=“fran.b”]En clair
dd if=/dev/hda1 of=Image
fsck Image
va faire un réparation de ton système de fichier sur le fichier Image et rendra un fichier Image contenant une partition tout à fait correcte. Tu pourras même faire
dd if=Image of=/dev/hda1
et ta partitiuon sera réparée (sauf si elle est montée en même temps ce qui donnera des résultats curieux). [/quote]
dd va récupérer l’ensemble, c’est à dire le contenant (la partition) et contenu (le système de fichiers et les data) Il est donc normal que le fsck se fasse ensuite sur l’image. Il en serait d’ailleurs de même si l’on créait un fichier vide avec dd, pour ensuite le monter en loop et y créer un système de fichiers.
Et c’est là que nous différons. Plus exactement, je n’accède pas à la partition au niveau des blocs, mais à travers l’adresse physique de la partition, j’accède au système de fichiers au niveau des i-noeuds, des blocs, des répertoires, le tout à partir des superblocs ou metadata du système de fichiers concerné.
D’ailleurs fsck nous dira :
:~# fsck.ext3 -f -v /dev/hdc1
e2fsck 1.40.8 (13-Mar-2008)
Passe 1 : vérification des i-noeuds, des blocs et des tailles
Passe 2 : vérification de la structure des répertoires
Passe 3 : vérification de la connectivité des répertoires
Passe 4 : vérification des compteurs de référence
Passe 5 : vérification de l’information du sommaire de groupe
Et si je fais une erreur de cible, il préviendra :
Le superbloc n’a pu être lu ou ne contient pas un système de fichiers
ext2 correct. Si le périphérique est valide et qu’il contient réellement
un système de fichiers ext2 (et non pas de type swap, ufs ou autre),
alors le superbloc est corrompu, et vous pourriez tenter d’exécuter
e2fsck avec un autre superbloc :
Il est toujours question de système de fichiers.
C’est pour cela que j’ai réagi à cette phrase :
“fsck travaille sur le disque pas sur le système de fichiers…” qui demandait à être précisée.
Je ne pense pas confondre, car en ce qui me concerne je fais bien la distinction entre partition et système de fichiers.
là je suis tout à fait d’accord. La table de partition va seulement renseigner au niveau /dev/ sur la position physique du système de fichiers, et celui-ci sera ensuite analysé.
oui, et des éventuelles sauvegardes du mbr et meta. C’est ainsi d’ailleurs qu’il retrouve parfois l’emplacement d’une ancienne table détruite.