[Eisfair] HILFE mein Eis hat 6 Std vor der Urlaubsreise die Platte gekillt

Peter Schauder p_schauder at web.de
Di Mai 29 18:58:05 CEST 2018


On Tue, 29 May 2018 18:05:25 +0200, Marcus Roeckrath
<marcus.roeckrath at gmx.de> wrote:
Hi Marcus,

danke erstmal. Ich hab die Kiste jetzt wieder am rennen...und würde
aus Zeitgründen erstmal die Augen verschließen und hoffen...

Aber MariaDB zickt. Ich hab jetzt in /var/log/mysqld/55/mysqld.log das
hier gefunden:

cess 4031 ...
180529 17:53:17 InnoDB: The InnoDB memory heap is disabled
180529 17:53:17 InnoDB: Mutexes and rw_locks use GCC atomic builtins
180529 17:53:17 InnoDB: Compressed tables use zlib 1.2.8
180529 17:53:17 InnoDB: Using Linux native AIO
180529 17:53:17 InnoDB: Initializing buffer pool, size = 128.0M
180529 17:53:17 InnoDB: Completed initialization of buffer pool
180529 17:53:17 InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
InnoDB: Restoring possible half-written data pages from the
doublewrite buffer...
InnoDB: Error: tried to read 1048576 bytes at offset 0 1048576.
InnoDB: Was only able to read 876544.
180529 17:53:19  InnoDB: Operating system error number 5 in a file
operation.
InnoDB: Error number 5 means 'Input/output error'.
InnoDB: Some operating system error numbers are described at
InnoDB:
http://dev.mysql.com/doc/refman/5.5/en/operating-system-error-codes.html
InnoDB: File operation call: 'read'.
InnoDB: Cannot continue operation.
180529 17:53:20 mysqld_safe mysqld from pid file
/run/mysql/55/mysql.pid ended

Sieht für mich so aus, als ob die Recovery der letzten Einträge nicht
funktioniert. Ich würde da durchaus drauf verzichten wollen (also
nicht auf die Datenbank, aber auf die letzten Transaktionen), weiß
aber nicht, wie ich das anstellen muß.

Irgendeine Idee dazu?

Gruß
Peter

>Hallo Peter,
>
>Peter Schauder wrote:
>
>> die Koffer werden gerade gepackt und mein Server hat entschieden eine
>> Kernelpanic zu produzieren.
>> 
>> Nach Reboot:
>> 
>> EXT4-fs (sda3) re-mounted. Opts: errors=remount-ro
>> * Checking file systems...
>> fsck from util-linux 2.28
>> /dev/sda3: clean , 144512/3473408 files, 1165711/13879808 blocks
>> /dev/sda1: clean, 21/12288 files, 1944/49152 blocks
>> Possibly non-existent device?
>> /dev/sda4: clean 14/285040 files, 332032/1138944 blocks
>> 
>> fsck failed. Pleas repair manually and reboot. The root
>> file system is curretly mounted read-only. To remount it
>> read-write do:
>> 
>> wenn ich
>>  fsck /dev/sda3
>>  fsck /dev/sda4
>>  fsck /dev/sda1
>> 
>> starte, dann gibt es ein paar Statusmeldungen
>> fsck from util-linux 2.28
>> e2fsck 1.43.6
>> /dev/sda4: clean, 14/285040 files, 332032/1138944 block
>> 
>> Sieht für mich ok aus, aber wie bekomme ich die Kiste wieder gebooted?
>> Ctrl-D bring mich nach einem Reboot wieder genau hierhin
>> 
>> nach mount -n -o remount,rw /
>> und "reboot" komme ich wieder genau hier hin
>
>So aus der Ferne schlecht zu sagen:
>
>Mal die Kabel der Platte an Board und Platte ein- und ausgesteckt?
>
>Die kernelpanik und die Bootprobleme weisen schon sehr deutlich auf ein
>Plattenproblem hin.
>
>Rettungs-CD starten und dann dort mal mit "smartctl -a /dev/sda" die Werte
>auslesen; dann mal mit "dd if=/dev/sda of=/dev/null" schauen, ob die Platte
>Sektor für Sektor ohne Fehlermeldung (z. B: I/O-Error) gelesen werden kann.
>
>Eventuell den fsck auch im Rettungssystem.



Mehr Informationen über die Mailingliste Eisfair