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
Attachment:
signature.asc
Description: OpenPGP digital signature