Probleme nach Wechsel Hardware

31/01/2016 - 19:20 von Jan Kappler | Report spam
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)

Hallo Leute,

seit zwei Wochen habe ich mit meinem Server erhebliche Probleme.
Hardware: Alix1.D-Mainboard, SATA-Controller (PCI-Steckkarte), Debian
Wheezy auf 2-GB-CF-Karte, 2 x Seagate 2,5"-HDD 250GB zur Datenspeicherung

server:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 1 1,9G 0 disk
└─sda1 8:1 1 1,9G 0 part /
sdb 8:16 0 232,9G 0 disk
└─vg1-vg1--lv_jan (dm-5) 254:5 0 220G 0 lvm /srv/jan
sdc 8:32 0 232,9G 0 disk
├─vg0-vg0--lv_swap (dm-0) 254:0 0 512M 0 lvm [SWAP]
├─vg0-vg0--lv_home (dm-1) 254:1 0 100M 0 lvm /home
├─vg0-vg0--lv_tmp (dm-2) 254:2 0 200M 0 lvm /tmp
├─vg0-vg0--lv_var (dm-3) 254:3 0 10G 0 lvm /var
└─vg0-vg0--lv_public (dm-4) 254:4 0 200G 0 lvm /srv/public

Die HDD (sdb, sdc) sind in zwei VGs organisiert:
server:~# vgdisplay -s
"vg0" 232,88 GiB [210,79 GiB used / 22,09 GiB free]
"vg1" 232,88 GiB [220,00 GiB used / 12,88 GiB free]

server:~# lvscan
ACTIVE '/dev/vg0/vg0-lv_swap' [512,00 MiB] inherit
ACTIVE '/dev/vg0/vg0-lv_home' [100,00 MiB] inherit
ACTIVE '/dev/vg0/vg0-lv_tmp' [200,00 MiB] inherit
ACTIVE '/dev/vg0/vg0-lv_var' [10,00 GiB] inherit
ACTIVE '/dev/vg0/vg0-lv_public' [200,00 GiB] inherit
ACTIVE '/dev/vg1/vg1-lv_jan' [220,00 GiB] inherit

Das OS befindet sich auf der CF-Karte, Swap, /home, /tmp, /var sowie die
Datenverzeichnisse auf den LV.

Beginn der Probleme: Ich wollte vg1-lv_jan vergröàŸern und hab zuvor den
Server (der praktisch 24/7 là¤uft) neu gestartet mit forciertem Test der
Dateisysteme:
shutdown -rF now

1. Problem: Soweit kommt die Kiste aber nicht: Der Kernel wird geladen,
doch beim Laden der initialen Ramdisk passiert nichts mehr. Wenn sonst
eine entsprechende Meldung erfolgt, sehe ich nur einen schwarzen
Bildschirm mit in der linken oberen Ecke blinkendem Cursor.

1.1 Dieses erste Problem habe ich nur auf dem Alix-Board mit meiner
"originalen" CF-Karte. Eine zweite Karte [1] bootet weiter und là¤dt die
initrd. (Dann bleibt er allerdings bei fsck stehen, weil es
unterschiedliche Angaben der Blockanzahl von Medium/Superblock moniert.
Mittlerweile haben Versuche, den Superblock/das Dateisystem zu
reparieren, die Karte "zerlegt", sprich ich muss sie neu
partitionieren/formatieren.)
Frage: Woran kann es liegen, das die eine Karte hà¤ngt, die seit Jahren
ohne Probleme là¤uft, die andere aber weiter bootet?

Die Karte ist mit erweiterten Optionen gemountet, um die Schreibzugriffe
auf den Flash zu verringern:
/dev/disk/by-uuid/b8b7ab63-45bc-464b-baba-fab434efe6db on / type ext3
(rw,noatime,errors=remount-ro,commit=120,barrier=1,data=ordered)

1.2 Vor einiger Zeit hatte ich einen alten Rechner vorbereitet, der als
Ersatz dienen soll. Mainboard ist ein Asus P3B-F mit Intel Pentium-II
400 MHz und 256MB SDRAM. Die CF-Karte steckt in einem Adapter IDE-CF,
als SATA-Controller dient der aus dem Server.
Der Rechner bootet mit derselben Karte, die im Alix-Board Probleme
macht. Nach Anpassung von ethx kann ich auch auf diesen Reserve-Server
zugreifen.
Frage: Warum bootet die CF-Karte vom Asus-Board, wà¤hrend sie beim
Alix-Board hà¤ngt?
Anmerkung: Mit dem Reserve-Server lief beim ersten Booten fsck
problemlos durch.

2. Problem: Seit dem 24.01. bekomme ich nach dem Booten diese Meldung
(dritte Zeile):
Jan 31 16:14:09 server kernel: [ 22.933509] NFSD: Using
/var/lib/nfs/v4recovery as the NFSv4 state recovery directory
Jan 31 16:14:09 server kernel: [ 22.990700] NFSD: starting 90-second
grace period
Jan 31 16:16:46 server kernel: [ 124.631876] NFSD: failed to write
recovery record (err -17); please check that /var/lib/nfs/v4recovery
exists and is writeable

Komisch:
server:/var/log# ls -l /var/lib/nfs
insgesamt 20
-rw-r--r-- 1 root root 1850 Jan 31 16:14 etab
-rw-r--r-- 1 root root 0 Jun 7 2015 export-lock
-rw-r--r-- 1 root root 0 Mai 22 2013 rmtab
drwxr-xr-x 9 root root 0 Jan 31 16:14 rpc_pipefs
drwxr-xr-x 2 statd nogroup 4096 Jun 7 2015 sm
drwxr-xr-x 2 statd nogroup 4096 Jun 7 2015 sm.bak
-rw-r--r-- 1 root root 4 Jan 31 16:14 state
drwxr-xr-x 3 root root 4096 Jan 31 12:25 v4recovery
-rw-r--r-- 1 root root 0 Mai 22 2013 xtab

Das Verzeichnis existiert und ist fà¼r root beschreibbar. Wieso dann
diese Fehlermeldung? Im Internet hab ich dazu nichts gefunden.

3. Problem: Von einer der beiden Festplatten bekomme ich im Log diese
Meldungen offensichtlich immer dann, wenn viel auf die Platte
geschrieben werden soll:
Jan 31 15:52:58 server kernel: [12614.742280] ata3.00: exception Emask
0x0 SAct 0x0 SErr 0x2400000 action 0x0
Jan 31 15:52:58 server kernel: [12614.742334] ata3.00: BMDMA2 stat
0x68650001
Jan 31 15:52:58 server kernel: [12614.742371] ata3: SError: { Handshk
UnrecFIS }
Jan 31 15:52:58 server kernel: [12614.742407] ata3.00: failed command:
WRITE DMA EXT
Jan 31 15:52:58 server kernel: [12614.742469] ata3.00: cmd
35/00:e0:b8:7b:11/00:02:15:00:00/e0 tag 0 dma 376832 out
Jan 31 15:52:58 server kernel: [12614.742479] res
51/04:e0:b8:7b:11/00:02:15:00:00/e0 Emask 0x1 (device error)
Jan 31 15:52:58 server kernel: [12614.742538] ata3.00: status: { DRDY ERR }
Jan 31 15:52:58 server kernel: [12614.742566] ata3.00: error: { ABRT }
Jan 31 15:52:58 server kernel: [12614.892318] ata3.00: configured for
UDMA/100
Jan 31 15:52:58 server kernel: [12614.892381] ata3: EH complete

Nach kurzer Zeit wird anscheinend die Geschwindigkeit reduziert:
...
Jan 31 15:53:25 server kernel: [12641.723466] ata3.00: status: { DRDY ERR }
Jan 31 15:53:25 server kernel: [12641.723503] ata3.00: error: { ABRT }
Jan 31 15:53:25 server kernel: [12641.723568] ata3: hard resetting link
Jan 31 15:53:25 server kernel: [12642.040138] ata3: SATA link up 1.5
Gbps (SStatus 113 SControl 310)
Jan 31 15:53:25 server kernel: [12642.056309] ata3.00: configured for
UDMA/66
Jan 31 15:53:25 server kernel: [12642.056363] ata3: EH complete

und noch weiter:
Jan 31 15:53:27 server kernel: [12643.812743] ata3: hard resetting link
Jan 31 15:53:27 server kernel: [12644.132139] ata3: SATA link up 1.5
Gbps (SStatus 113 SControl 310)
Jan 31 15:53:27 server kernel: [12644.148312] ata3.00: configured for
UDMA/33
Jan 31 15:53:27 server kernel: [12644.148377] ata3: EH complete

Nach einer Weile kommt auch:
Jan 31 15:54:03 server kernel: [12680.032150] ata3: lost interrupt
(Status 0x51)
Jan 31 15:54:03 server kernel: [12680.032231] ata3.00: exception Emask
0x0 SAct 0x0 SErr 0x2400000 action 0x6 frozen
Jan 31 15:54:03 server kernel: [12680.032308] ata3: SError: { Handshk
UnrecFIS }

Das geht noch eine Minute oder so, dann kommt zwischendurch:
Jan 31 15:55:39 server kernel: [12775.352403] sd 2:0:0:0: [sdb] Result:
hostbyte=DID_OK driverbyte=DRIVER_SENSE
Jan 31 15:55:39 server kernel: [12775.352429] sd 2:0:0:0: [sdb] Sense
Key : Aborted Command [current] [descriptor]
Jan 31 15:55:39 server kernel: [12775.352455] Descriptor sense data with
sense descriptors (in hex):
Jan 31 15:55:39 server kernel: [12775.352469] 72 0b 00 00 00 00
00 0c 00 0a 80 00 00 00 00 00
Jan 31 15:55:39 server kernel: [12775.352517] 15 53 48 f8
Jan 31 15:55:39 server kernel: [12775.352541] sd 2:0:0:0: [sdb] Add.
Sense: No additional sense information
Jan 31 15:55:39 server kernel: [12775.352570] sd 2:0:0:0: [sdb] CDB:
Write(10): 2a 00 15 53 48 f8 00 02 c0 00
Jan 31 15:55:39 server kernel: [12775.352616] end_request: I/O error,
dev sdb, sector 357779704
Jan 31 15:55:39 server kernel: [12775.352674] Buffer I/O error on device
dm-5, logical block 41893103
Jan 31 15:55:39 server kernel: [12775.352714] lost page write due to I/O
error on dm-5

(und weitere Zeilen dieser Art bis logical block 41893112). Komisch ist,
das der Upload der Daten - Video mit MediathekView speichern - auf sdc
erfolgte, jedoch von sdb diese Meldung kommt. Okay, ich hab eine
Textdatei zu diesem Zeitpunkt gespeichert, vielleicht war das dann zu
viel ;-)

Den Port am SATA-Controller habe ich schon geà¤ndert, die Platten
umgesteckt, à¤ndert aber nichts:
Jan 31 16:36:46 server kernel: [ 1380.064148] ata6: lost interrupt
(Status 0x51)
Jan 31 16:36:46 server kernel: [ 1380.064214] ata6.00: exception Emask
0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
Jan 31 16:36:46 server kernel: [ 1380.064302] ata6.00: failed command:
WRITE DMA EXT
Jan 31 16:36:46 server kernel: [ 1380.064395] ata6.00: cmd
35/00:60:c0:df:57/00:01:15:00:00/e0 tag 0 dma 180224 out
Jan 31 16:36:46 server kernel: [ 1380.064406] res
40/00:01:01:4f:c2/00:00:00:00:00/10 Emask 0x4 (timeout)
Jan 31 16:36:46 server kernel: [ 1380.064527] ata6.00: status: { DRDY }
Jan 31 16:36:46 server kernel: [ 1380.064618] ata6: hard resetting link
Jan 31 16:36:47 server kernel: [ 1380.384138] ata6: SATA link up 1.5
Gbps (SStatus 113 SControl 310)
Jan 31 16:36:47 server kernel: [ 1380.400318] ata6.00: configured for
UDMA/100
Jan 31 16:36:47 server kernel: [ 1380.400379] ata6: EH complete

Aufgefallen ist mir im Log diese Meldung:
Jan 31 16:14:09 server kernel: [ 19.408525] e100 0000:00:0b.0:
firmware: agent aborted loading e100/d101m_ucode.bin (not found?)
Jan 31 16:14:09 server kernel: [ 19.409455] e100 0000:00:0b.0: eth2:
CPUSaver disabled. Needs "e100/d101m_ucode.bin": -2
Jan 31 16:14:09 server kernel: [ 19.409994] ADDRCONF(NETDEV_UP): eth2:
link is not ready
Jan 31 16:14:09 server kernel: [ 19.412355] e100 0000:00:0b.0: eth2:
NIC Link is Up 100 Mbps Full Duplex
Jan 31 16:14:09 server kernel: [ 19.413393] ADDRCONF(NETDEV_CHANGE):
eth2: link becomes ready

Dieses Mainboard hat keine Onboard-NIC, ich verwende eine
PCI-Steckkarte. Könnte die fehlende Firmware zu groàŸe CPU-Last
verursachen, wenn à¼ber das Netzwerk schreibend zugegriffen wird? Im
Leerlauf passiert offenbar nichts.
SMART liefert keine beunruhigenden Infos, der kurze Selbsttest lief
anstandslos durch.

Ergà¤nzung: Beim soeben erfolgten Test verursacht ein Abspielen von Video
(mp4) à¼ber das Netzwerk à¤hnliche Fehler, aber mit "failed command: READ
DMA EXT".
Offenbar treten die Meldungen aber nur bei Laufwerk sdc auf, das
Abspielen eines Videos aus einem Verzeichnis auf sdb provoziert
zumindest keine.


Entschuldigt den Umfang an Informationen, doch die Probleme scheinen
komplex zu sein und fallen unglà¼cklicherweise mit dem Upgrade des
Desktop-PC auf neue Hardware+Debian 8 zusammen. Anders gesagt, sie
passen mir gerade à¼berhaupt nicht :-(

Beim Problem 1 weiàŸ ich nicht, ob das Alix-Board eine Macke hat oder die
CF-Karte. Ich werde mal eine Test-Installation auf der zweiten CF-Karte
(ohne Festplatten) versuchen. Beim Problem 2 bin ich völlig ratlos.
Beim Problem 3 könnte es die Festplatte sein, worauf SMART aber nicht
hindeutet. Der Controller könnte es sein, aber dasselbe Problem an
unterschiedlichen Ports bei derselben Platte? Eventuell könnte ich die
Kabel austauschen und die Firmware fà¼r die Intel-Netzwerkkarte
installieren und schauen, ob sich etwas à¤ndert.

Mir ist wichtig, eine Einschà¤tzung speziell dieses Problem durch euch zu
bekommen. Ich will reagieren können, bevor vielleicht die Festplatte
oder andere Hardware komplett abschmiert.


[1] Ich habe diese vor einigen Monaten versucht mit cp zu kopieren, was
aber nur bedingt geklappt hat. Trotz gleichem Hersteller und gleichem
Typ scheinen sich beide Karten in der Anzahl der Blöcke zu unterscheiden.



Mit freundlichem GruàŸ
Jan Kappler





 

Lesen sie die antworten

#1 Jan Kappler
06/02/2016 - 14:00 | Warnen spam
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)

Hallo Leute,

ich bin etwas weiter gekommen.

Am 31.01.2016 um 19:18 schrieb Jan Kappler:
3. Problem: Von einer der beiden Festplatten bekomme ich im Log diese
Meldungen offensichtlich immer dann, wenn viel auf die Platte
geschrieben werden soll:
...
Den Port am SATA-Controller habe ich schon geàndert, die Platten
umgesteckt, àndert aber nichts:
...
SMART liefert keine beunruhigenden Infos, der kurze Selbsttest lief
anstandslos durch.
...
Offenbar treten die Meldungen aber nur bei Laufwerk sdc auf, das
Abspielen eines Videos aus einem Verzeichnis auf sdb provoziert
zumindest keine.
...
Beim Problem 3 könnte es die Festplatte sein, worauf SMART aber nicht
hindeutet. Der Controller könnte es sein, aber dasselbe Problem an
unterschiedlichen Ports bei derselben Platte? Eventuell könnte ich die
Kabel austauschen und die Firmware für die Intel-Netzwerkkarte
installieren und schauen, ob sich etwas àndert.



Ich habe die Anschlusskabel ausgetauscht, nun scheint Ruhe zu sein. Die
Fehlermeldungen kommen nicht mehr.
Die übrigen Probleme bestehen weiterhin, hat jemand eine Idee?



Mit freundlichem Gruß
Jan Kappler





Ähnliche fragen