Si vous bidouillez un peu trop votre Linux et qu'à un moment il "freeze" et que même CTRL-ALT-SUPPR ne le ranime pas, n'appuyez surtout pas le bouton reset de votre ordi car ça implique un fsck au prochain démarrage.
Essayer d'abord les contrôles systèmes dans l'ordre suivant :
Alt-SysRq-S (met le swap sur disque)
Alt-SysRq-U (remonte tout en readonly)
Alt-SysRq-B (reboot)
Et adieu le check forced :)
Plus d'infos dans /usr/src/linux/Documentation/sysrq.txt
Forum Astuces.divers [Terminal] Eviter les check forced !
5
juin
2001
# Et les éléphants....
Posté par Aurélien Bompard (site web personnel) . Évalué à 1.
R S E I U B
R passe ton clavier en mode RAW, après tu peux réessayer C-A-Del ou mieux C-A-BackSpace (tue X).
E je sais plus ;)
I non plus ;)
U remonte des systèmes de fichier en mode Read-only
Il y a une phrase (à la con) pour se souvenir de tout :
Raising Skinny Elephants Is Utterly Boring.
J'avais aussi trouvé quelquepart : "Remembering the Sequence Entirely Is Useful, Buddy" mais je préfère l'autre. ;)
[^] # Re: Et les éléphants....
Posté par xof . Évalué à 2.
* What are the 'command' keys?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
'r' - Turns off keyboard raw mode and sets it to XLATE.
'k' - Secure Access Key (SAK) Kills all programs on the current virtual
console. NOTE: See important comments below in SAK section.
'b' - Will immediately reboot the system without syncing or unmounting
your disks.
'o' - Will shut your system off (if configured and supported).
's' - Will attempt to sync all mounted filesystems.
'u' - Will attempt to remount all mounted filesystems read-only.
'p' - Will dump the current registers and flags to your console.
't' - Will dump a list of current tasks and their information to your
console.
'm' - Will dump current memory info to your console.
'0'-'9' - Sets the console log level, controlling which kernel messages
will be printed to your console. ('0', for example would make
it so that only emergency messages like PANICs or OOPSes would
make it to your console.)
'e' - Send a SIGTERM to all processes, except for init.
'i' - Send a SIGKILL to all processes, except for init.
'l' - Send a SIGKILL to all processes, INCLUDING init. (Your system
will be non-functional after this.)
'h' - Will display help ( actually any other key than those listed
above will display help. but 'h' is easy to remember :-)
pour pouvoir utiliser ces combinaisons, il faut les avoir compilés leurs support dans le noyau (kernel hacking/Magic Sysrq key)
il est possible de les désactiver grâce à un simple:
echo "0" > /proc/sys/kernel/sysrq
mais la meilleure des choses reste de lire la doc du noyau pour en savoir plus.
[^] # Re: Et les éléphants....
Posté par Pierre Jarillon (site web personnel) . Évalué à 1.
Ou en anglais sur : http://www.linuxhq.com/kernel/v2.4/doc/sysrq.txt.html(...)
# Re: Eviter les check forced !
Posté par doublehp (site web personnel) . Évalué à 1.
tune2fs -j /dev/hda?
ou encore mieux , utilisez les vrais systems de fichires journalises
( les meilleurs actuellement disponibles sur le marcher sont ext3 et XFS
(( apt-get install xfsprogs sous debian )) )
bon j esquive le troll poilu et je ne dis pas lequel des 2 je prefere ;)
[^] # Re: Eviter les check forced !
Posté par matiasf . Évalué à 1.
ben ext3 puisque tu le cites en premier.
[^] # Re: Eviter les check forced !
Posté par doublehp (site web personnel) . Évalué à 1.
Perdu ;)
j ai cite dans l ordre alphabetique, mais je n ai QUE du XFS !
Parce que XFS ROXOR, alors que je connais pas mal de monde qui a perdu beaucoup de donnee a cause de l incapacite de l EXT3 de recouvrer 100% des inodes ouverts en ecriture lors du crash ... ext3 perd meme parfois des inode fermes lors du crash ...
Alors que le XFS .... j ai meme ete jusqu a faire un reset pendant la copie d un "gros fichier" ( genre un filme ... ) ben apres redemarrage, je pouvais visionner la moitie du filme, a partir de la copie que j avais interrompue ...
Mais chuuu t ... c est un troll ... TRES poilu ...
[^] # Re: Eviter les check forced !
Posté par Anonyme . Évalué à 1.
[^] # Re: Eviter les check forced !
Posté par matiasf . Évalué à 1.
C'est quoi ton propos ? Tu nous expliques que Linux c'est nul ?
Voilà mon interprétation de ta phrase :
- "je connais une personne (toi) qui a perdu des donnees en utilisant EXT3".
Ben çà peut arriver. J'ai même eu une expérience malheureuse avec ext3 (et une seule !) en 18 mois d'utilisation sur la même machine (peut-être un problème hardware ?).
Enfin, il faut noter que les disques sous IDE ne sont généralement pas adaptés aux systèmes de fichier journalisé (XFS en fait parti !). En effet, les disques IDE ne respectent pas, entre autre, toujours les ordres d'écriture contrairement aux disques SCSI ce qui est problèmatique pour les coupures de courant. Par contre les disques IDE sont généralement OK pour les kernel panic et reset.
Donc si tu perds des donnés après coupure de courant en utilisant des disques IDE çà peut-être normal (fonction de tes disques et controleur IDE).
Notes aussi qu'actuellement ext3 est le seul a journaliser les données contrairement à XFS (reiserfs V4 doit le faire maintenant et sera peut-être disponible dans Linux 2.6).
Je connais personne qui a un problème avec XFS car je ne connais personne qui utilise XFS.
Mais chuuu t ... c est un troll ... TRES poilu ...
[^] # Re: Eviter les check forced !
Posté par - - . Évalué à 2.
mort du troll poilu (coup d'épée vorpale)
[^] # Re: Eviter les check forced !
Posté par Flyounet (site web personnel) . Évalué à 1.
De plus le Troll étant une bête qui se régénère à chaque tour, nous pouvons dire que depuis que ton message a été posté, il est de nouveau vivant !
Tu m'aurais dit, je lui mets des coups de +1,+2,+3,+4,+5 (langue de flamme en français ?), je t'aurais dit : il est peut-être pas mort mais au moins ce qu'il a perdu, il ne le régénèrera pas.
[^] # Re: Eviter les check forced !
Posté par KernelPanic26 . Évalué à 1.
De plus il sera dispo dans le kernel 2.6 (fini la recup des patches sur opensource.sgi.com.)
Epilation du troll ....
[^] # Re: Eviter les check forced !
Posté par doublehp (site web personnel) . Évalué à 1.
[^] # Re: Eviter les check forced !
Posté par EchoPapaMike . Évalué à 1.
A mon avis tout disque moderne , qu'il soit SCSI, FIBRE CHANNEL , IDE , ne respecte l'ordre d'ecriture , il s'agit pour lui d'optimiser le deplacement des tetes .
De plus linux lui rajoute encore sa sauce, les lectures et les ecritures ne sont pas faites dans l'ordre des demandes .
Les disques hybrides ATA , qui ont une memoire flash , sont adaptes au systeme de fichier journalises .
[^] # Re: Eviter les check forced !
Posté par poil oq . Évalué à 1.
oui il m'est arrivé de planter régulièrement par le passé à cause de je ne sais plus quel soft, et j'avais une machine en EXT3 et une autre en XFS (avec la même RedHat 7.1, donc toutes les mêmes version de soft) et autant de plantages sur l'une que sur l'autre.
Que des emmerdes au reboot de l'EXT3, qui a arreté de perdre des données au reboot quand je l'ai passé en XFS. Et jamais eu aucun soucis en XFS à cause des reboots (qui tourne toujours aujourd'hui en serveur web et samba).
XFS > Xtra_Super_Top_Reliable_File_System !! ;o)
[^] # Re: Eviter les check forced !
Posté par Zorro (site web personnel) . Évalué à 1.
[^] # Re: Eviter les check forced !
Posté par doublehp (site web personnel) . Évalué à 1.
moi je met tout dans le kernel ... mon initrd est vide, et mon /etc/modules aussi !
[^] # Re: Eviter les check forced !
Posté par Pooly (site web personnel) . Évalué à 1.
[^] # Re: Eviter les check forced !
Posté par campagnard . Évalué à 1.
[^] # Re: Eviter les check forced !
Posté par fenril . Évalué à 1.
Un système de fichiers est dit journalisé, entre autres choses, quand il tient un compte rendu (le journal) décrivant les fichiers dans lesquels il est en train d'écrire, ainsi que l'état dans lequel ils étaient avant.
Si d'aventure l'opération d'écriture ne se termine pas correctement, on se sert du journal pour revenir en arrière (tiens , ce ne serait pas un pléonasme, ca?)
Si tout va bien on vire la transaction du journal.
# Re: Eviter les check forced !
Posté par David FORT . Évalué à 1.
Si jamais la Ooops s'est produit dans le code qui gère le FileSystem, et que avant de faire une Oops le code fautif à corrompu des buffers. Et bien en faisant une synchro des buffers(c'est ce que fait le remontage en ReadOnly), on fait recopie sur le disque des buffers CORROMPUS !!!
C'est vraiment une super idée si on a envie de perdre toutes les données d'une partition(bonjour la corruption de fichiers généralisée). Les développeurs du noyau conseilles de n'utiliser cette sys-req key seulement en connaissance de cause. "En connaissance de cause" voulant dire qu'on a une console sur le port série qui permet de savoir ou ca a déconné exactement.
Pour avoir été victime d'une corruption de fichier par ce biais je déconseilles plutôt catégoriquement cette technique(même s'il m'arrive de m'en servir de temps à autre). Le temps d'un fsck ne vaut pas le temps de réinstalle d'une partoche.
[^] # Re: Eviter les check forced !
Posté par doublehp (site web personnel) . Évalué à 1.
Mon dur fait 40Go ...
il faut 9 minutes a windows 2k pour formatter une partition de 4Go en NTFS sur le meme disque ... la creation d une partition de 40Go en XFS doit bien prendre au moins 6 a 7s ...
bref ... quand on journalise, ca va bien plus vite d apuyer sur reset, que de se saouler avec les sysrq ... t a surement raison, mais j etais convaincu de leur inutilite avent ...
et de toute facon, je les ai vire parceque des fois tu apuye dessus par megarde, et la tu sais pas comment t en sortire ...
=> rm -rf /sysrq ...
[^] # Re: Eviter les check forced !
Posté par Eric E.D.V. . Évalué à 1.
# Bricolage maison
Posté par pada . Évalué à 1.
Reprendre Sans Espoir Indispose Un Benet
Heureusement je n'en ai besoin maintenant que rarement.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.