perso je doute que la conversion fasse les chose proprements… j’ai formater direct en ext4 est c est mieux que l’ext3 coter fragu, qui montai a 30% … 
bon après peut etre que sa change rien,si c est la cas je dis rien hein 
Jusqu’au bout capitaine :
[code]tune2fs -O extents,uninit_bg,dir_index /dev/sda1
fsck -Df /dev/sda1
find /mnt/disk -xdev -type f -exec chattr +e {} ;
find /mnt/disk -xdev -type d -exec chattr +e {} ;[/code]
Avec un live-CD d’BoutToutMou 10.10.
[quote=“youki”]Ca a fonctionne pour moi a part un detail :
[quote]$ sudo fsck -pDf /dev/sdr4
fsck from util-linux-ng 2.17.2
fsck.ext2: No such file or directory while trying to open /dev/sdr4
/dev/sdr4:
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193
ubuntu@ubuntu:~$ sudo fsck -pDf /dev/sda2
fsck from util-linux-ng 2.17.2
/dev/sda2: One or more block group descriptor checksums are invalid. FIXED.
/dev/sda2: Group descriptor 0 checksum is invalid.
/dev/sda2: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
(i.e., without -a or -p options)[/quote]
J’ai donc fait en enlevant le p.[/quote]
Je confirme, ne s’exécute pas avec l’option -p, la retirer résouds tout. (il détecte probablement trop d’erreur par rapport à une situation normale pour accepter le mode automatique).
[code]# fsck -pDf /dev/sdaX
PartName: One or more bloc groupe descriptor checksums are invalid. CORRIGÉ.
PartName: Le checksum du descripteur de groupe 0 est invalide.
PartName: INCONSISTENCE INATTENDUE ; EXÉCUTEZ fsck MANUELLEMENT.
(i.e., sans options -a ou -p)
[/code]
# fsck -Df /dev/sdaX
One or more bloc groupe descriptor checksums are invalid. Corriger<o>? oui
et il fait le boulot
Bonjour,
Hier au soir (jusqu’à tôt ce matin 
!) j’ai suivi ton tuto !
Ce que tu y a mis est nickel sauf que j’ai enlevé l’option"-p".
Le problème, c’est que j’ai buté sur la suite !
Au reboot, grub inopérant.
Pas de problème, j’utilise un live cd pour le réinstaller en chroot.
<début des emmer…>
Je n’arrive pas à entrer dans le chroot !
Ma conclusion : quelque chose s’est mal passé.
Je réinjecte la sauvegarde que j’avais fait préciseusement avec l’utilitaire clonezilla du livecd parted magic
Je redémarre, même problème de grub, chroot toujours impossible.
Je vais voir quelques info sur le net ! Je n’utilisais pas le bon cd ! J’ai une architecture 64 bits et j’utilisais un x86 ! 
Je grave un nouveau cd à partir d’un live cd qui trainait, je chroot, je réinstalle grub et je retrouve mon système d’avant.
</fin des emmer…>
Je suis persévérant, et je retente la procédure précédente (hors balise)
Je chroot avec le mode rescue du netinstall debian qui au passage est excellent !
Je reinstalle grub
Le système ne boot pas !
Google me dit :
ajouter l’option : GRUB_CMDLINE_LINUX=“rootfstype=ext4” dans /etc/default/grub.
Et me voici enfin avec mon système en ext4 avant la prochaine étape : le passage en testing (cf mon prochain post)!
Conclusion :
Ajouter à ton tuto :
- essayer le chroot avant !
- Ajouter l’option grub ci dessus.
Faire une bonne sauvegarde aide à rester serein
Merci beaucoup pour la sauvegarde j’ai prévenu lol.
Pour le chroot, si tu me dis comment le faire étape après étape je l’intègre tout de suite. Pour l’astuce de grub je la met en prérequis. Je pensais que le test en modifiant /etc/fstab suffisait mais j’ai était bète en fait il faut plutôt essayer en demandant à grub de monter la partition ext3 comme si elle était en ext4.
@seb-ksl > Je n’ai pas oublié ton problème. J’ai du mal à comprendre d’où ça viens. J’ai beaucoup cherché de solution de défragmentation la seule que j’ai pu trouver c’est de faire une sauvegarde de la partition en question (des fichiers de cette partition) avec tar, rsync ou autre (pas dd pas partimage) et de restaurer. Sinon avec le temps ton système de fichier se défragmenteras de lui même.
Pas de problème, j’ai décidé de toute façon de reformater proprement en ext4 dès que j’aurai un peu de temps. Merci quand même !
Tu as vu comment que tu avais une fragmentation importante ?
Chroot pour les nuls :
Munissez vous d’un CD debian netinstall ou buisnesscard de votre architecture.
Au boot :
- Advanced option >
- Rescue mode
- Sélectionner la langue, votre situation géographique, la disposition du clavier
- Donner un nom au système (on s’en fou, on s’en servira pas ! )
- Entrez le nom de domaine ( inutile si internet via box )
- Choisir la partition à monter comme système de fichier racine
- Exécuter un shell dans /dev/sdXX
- Continuer
Vous êtes dans la matrice du chroot !
Exit pour quitter. Aucune connaissance utile en chroot !
J’oubliais un point qui peut-être intéressant à faire avant la conversion : une vérification du disque !
Tout est intégré merci 
(y compris le premier fsck pour le système)
J’avais programmé un fsck au premier reboot après la conversion, et il affiche le % de “blocs non-contigus”, que j’ai toujours associé (à tort ?) à la fragmentation. Ce qui est sûr, c’est que même si ce n’est pas la fragmentation réelle, ce % a explosé sur les 2 partitions, et que xinit met un temps x1,5 à x2 pour tout lancer.
Allright, après une réinstallation de Squeeze directement sur de l’ext4, tout roule parfaitement !
Bonjour,
Je viens récemment de convertir mon système de fichier sur mon disque dur principal (sda1) de ext3 vers ext4 en suivant cette méthode (curieusement j’affine mieux mes recherches en anglais qu’en français).
J’aimerai modifier les attributs des fichiers pour profiter des extents (et ainsi des performances offertes par e4rat), mais j’ai une erreur en utilisant chattr qu’importe le fichier dont je tente de modifier l’attribut, que je sois root ou non :
chattr +e /home/emralegna/256colors2.pl
chattr: Invalid argument while setting flags on /home/emralegna/256colors2.pl
la procédure de conversion s’est déroulée sans aucun problème, et il semble bien que mon système soit en ext4 :
% df -T
Filesystem Type 1K-blocks Used Available Use% Mounted on
/dev/mapper/truc-root
ext4 6724784 5809648 573532 92% /
tmpfs tmpfs 1030396 0 1030396 0% /lib/init/rw
udev tmpfs 1024056 316 1023740 1% /dev
tmpfs tmpfs 1030396 440 1029956 1% /dev/shm
/dev/sda1 ext4 233335 34049 186838 16% /boot
/dev/mapper/truc-home
ext4 467801664 248100324 195938396 56% /home
/dev/sda1 ext4 233335 34049 186838 16% /boot
/dev/mapper/truc-home
ext4 467801664 248100324 195938396 56% /home
(Oui le / est pas mal surchargé ; faudrait que je change la taille de la partition, l’installeur donnant une taille trop petite par défaut, mais je ne sais pas encore comment faire avec les partition type LVM2.)
[code]% cat /etc/fstab
/etc/fstab: static file system information.
proc /proc proc defaults 0 0
/dev/mapper/truc-root / ext4 noatime,errors=remount-ro,data=writeback,commit=100,nobh 0 1
#/dev/sda1
UUID=“7e8fbcce-dc6c-4730-9ef6-1ffc0f5eb2c2” /boot ext4 noatime 0 2
/dev/mapper/truc-home /home ext4 noatime,data=writeback,commit=100,nobh 0 2
/dev/mapper/truc-swap_1 none swap sw 0 0
[/code]
J’utilise Debian unstable avec certains programmes de experimental ponctuellement, non critiques, comme Amarok ou KDE SC 4.6.
Je suis peut-être debout depuis trop longtemps pour remarquer l’endroit où j’ai loupé le train. 
Vous avez une idée ?
Merci.