Kernel panic - not syncing: Fatal exception in interrupt

Support Debian
#21

Bon, remet le fichier ibdata1, édite le fichier /etc/mysql/my.cnf et change

Si c’est vraiment la zone, va voir
http://www.mysqlperformanceblog.com/2011/06/03/a-recovery-trivia-or-how-to-recover-from-a-lost-ibdata1-file/

#22

@fran.b, je vois que tu as corrigé ta coquille. [ … = 4 & … = 4] (j’avais laissé tourner le chrono, …)

Ceci dit, j’avoue que ce n’était vraiment pas à cela que je faisais allusion.

#23

Mais pas si éloigné tant que cela, non plus … 8)

J’envisage de reprendre mon traitement, gélule de poisson à base de spe**** de cet individu.

Radical, selon ma belle-mère. :unamused: :005 :005

Extrait la_bas.

Cela me fait penser que je n’ai (de mémoire, une fois de plus) pas sorti un .pdf de ces liens, liens ici et là, pouvant être éphémère … 8)

* edit *

Voilà, .pdf dans ma besace, également !

...

### Erreurs du moteur de stockage InnoDB MySQL >> http://www.sacdos.net/2011/01/non-classe/erreurs-du-moteur-de-stockage-innodb-mysql/
# innodb_force_recovery = 4

### Si vous ne souhaitez pas utiliser les tables InnoDB, vous pouvez ajouter l'option:
## ==> https://dev.mysql.com/doc/refman/5.0/fr/innodb-configuration.html
#skip-innodb

### 15.4. Configuration InnoDB ==> https://dev.mysql.com/doc/refman/5.0/fr/innodb-configuration.html

# Vous pouvez placer d'autres options MYSQL ici
# ...mysqld: Option '--set-variable' is deprecated. Use --variable-name=value instead
# Le fichier de données doit contenir vos données et index.
# Assurez vous que vous avez l'espace disque nécessaire.
##innodb_data_file_path = ibdata1:10M:autoextend
#
# Utilisez un buffer de taille 50 à 80 % de votre mémoire serveur
##set--variable = innodb_buffer_pool_size=70M
##set--variable = innodb_additional_mem_pool_size=10M
# 
# Utilisez un fichier de log de taille 25 % du buffer mémoire
##set--variable = innodb_log_file_size=20M
##set--variable = innodb_log_buffer_size=8M
#
##innodb_flush_log_at_trx_commit=1

...
#24

J’avais essayé cette option hier mais ça n’a pas marché (et j’ai réessayé à l’instant).
D’ailleurs, il n’y a pas de ligne innodb_force_recovery dans my.cnf par défaut (ni même une ligne concernant innodb!)

#25

Salut,

/…/…/Ajouter … non ?

Et, relancer le service, certes.

#26

[quote=“BelZéButh”]Salut,

/…/…/Ajouter … non ?

Et, relancer le service, certes.[/quote]

Oui, j’ai ajouté mais ça n’a rien changé :013
J’ai tenté de desinstaller et purger mysql-server-5.5. Mais ça démarrer toujours pas en le réinstallant! aptitude purge n’est pas sensé tous supprimer du paquet?

#27

Salut,

Plutôt excessif et radical, à mon goût. :083

Censé ? Oui !

Aucune base, en /var/lib/mysql/ à maintenir ?

Bref, concernant le nettoyage, profond et sans équivoque, ma pratique. 8)

# aptitude search ~c < Réflexion > && aptitude purge ~c 
# find / -name "*le_paquet*"
# rm -ri /chemin/la_bas/répertoires/et/fichiers/en_toute_connaissance_de_cause

Devrait amplement suffire.

Poursuivre ta quête, (relire) sans relâche aucune …

#28

bonjour,

Message from syslogd@localhost at Oct 29 18:56:45 ...
 kernel:[13317.854279] general protection fault: 0000 [#1] SMP

tu as quelqu’un avec pas assez de privilège qui veut écrire dans le ring 0

as-tu installé kdump?
tu connaitras le process ID ainsi que la fonction douteuse

http://wiki.incloudus.com/display/DOC/Debian+-+Kdump

A+
JB1
:033

#29

Salut,

[quote=“jb1”]as-tu installé kdump?
tu connaitras le process ID ainsi que la fonction douteuse

wiki.incloudus.com/display/DOC/Debian±+Kdump[/quote]

Héhé, ton intervention me ravit, :wink: … Merci jb1 !! :023

[07:58:25]:~$ acp kdump-tools crash kexec-tools makedumpfile linux-image-3.2.0-4-686-pae-dbg kdump-tools: Installé : (aucun) Candidat : 1.4.3-1 Table de version : 1.5.4-1 0 95 http://ftp.fr.debian.org/debian/ unstable/main i386 Packages 1.5.3-1 0 97 http://ftp.fr.debian.org/debian/ testing/main i386 Packages 1.4.3-1 0 990 http://ftp.fr.debian.org/debian/ stable/main i386 Packages 1.3.5-1 0 500 http://ftp.fr.debian.org/debian/ oldstable/main i386 Packages crash: Installé : (aucun) Candidat : 6.0.6-1 Table de version : 7.0.1-1 0 95 http://ftp.fr.debian.org/debian/ unstable/main i386 Packages 6.1.6-1 0 97 http://ftp.fr.debian.org/debian/ testing/main i386 Packages 6.0.6-1 0 990 http://ftp.fr.debian.org/debian/ stable/main i386 Packages 5.0.6-1 0 500 http://ftp.fr.debian.org/debian/ oldstable/main i386 Packages kexec-tools: Installé : (aucun) Candidat : 1:2.0.3-1 Table de version : 1:2.0.3-4 0 97 http://ftp.fr.debian.org/debian/ testing/main i386 Packages 95 http://ftp.fr.debian.org/debian/ unstable/main i386 Packages 1:2.0.3-1 0 990 http://ftp.fr.debian.org/debian/ stable/main i386 Packages 1:2.0.1-4 0 500 http://ftp.fr.debian.org/debian/ oldstable/main i386 Packages makedumpfile: Installé : (aucun) Candidat : 1.4.3-1 Table de version : 1.5.4-1 0 95 http://ftp.fr.debian.org/debian/ unstable/main i386 Packages 1.5.3-1 0 97 http://ftp.fr.debian.org/debian/ testing/main i386 Packages 1.4.3-1 0 990 http://ftp.fr.debian.org/debian/ stable/main i386 Packages 1.3.5-1 0 500 http://ftp.fr.debian.org/debian/ oldstable/main i386 Packages linux-image-3.2.0-4-686-pae-dbg: Installé : (aucun) Candidat : 3.2.51-1 Table de version : 3.2.51-1 0 990 http://ftp.fr.debian.org/debian/ stable/main i386 Packages 3.2.46-1+deb7u1 0 990 http://security.debian.org/ stable/updates/main i386 Packages [07:59:45]:~$

#30

bonjour,
l’exemple est facile à réaliser,
chez moi j’ai mis ceci:
aptitude install kdump-tools linux-image-3.2.0-4-amd64-dbg crash kexec-tools makedumpfile
GRUB_CMDLINE_LINUX_DEFAULT="crashkernel=128M@32M quiet"
je n’ai pas mis @32M tandis que sur un autre Linux j’ai mis 256M

/etc/default/kdump-tools
USE_KDUMP=1
KDUMP_RUNLEVEL="1"
KDUMP_SAVEDIR="file:///var/crash"
KDUMP_NET=“none"
KDUMP_SYSCTL=“kernel.panic_on_oops=1"
KDUMP_COREDIR=”/var/crash"
KDUMP_FAIL_CMD=“reboot -f"
DEBUG_KERNEL=/usr/lib/debug/boot/vmlinux-3.2.0-4-amd64
MAKEDUMP_ARGS=”-c -d 31”

j’ai fait un copier/coller de ce fichier et modifier 31 par 17
j’ai créé à la main /var/crash au panic il crée le répertoire 2013…

ne pas oublier le update-grub2
et plusieurs fois init 6

la doc est trés bien faite
attendre le panic!
le reboot se fait en 2 temps

merci à Richardo pour ce lien
A+
JB1
:030

#31

Bon, j’ai fait un “nettoyage profond” avec :

Et mysql remarche enfin. Mon dernier backup est bien valide. De plus c’est un backup fait quelques heures avant le plantage de mysql donc j’ai quasiment rien perdu.

Je croise le doigt que c’est bien cette barrette qui est en faute (j’ai essayé de démarrer le pc avec aujourd’hui, ça fait toujours le long bip)

Merci beaucoup à tous.