Kategori Computer

Kernel Bug in CentOS 7

Sonntag, Februar 12th, 2017

Nach dem neu starten unserer VServer Plattform mit dem Kernel 3.10.0-514, traten nach sofort nach dem Booten folgende schwerwiegenden Fehler im Log auf:

kernel: Buffer I/O error on dev dm-15, logical block 8892681, lost async page write
kernel: sd 4:0:0:0: [sdc] FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
kernel: sd 4:0:0:0: [sdc] Sense Key : Not Ready [current]
kernel: sd 4:0:0:0: [sdc] Add. Sense: Logical unit communication failure
kernel: sd 4:0:0:0: [sdc] CDB: Write(16) 8a 00 00 00 00 00 37 7d 48 00 00 00 40 00 00 00
kernel: blk_update_request: I/O error, dev sdc, sector 930957312
kernel: sd 4:0:0:0: [sdc] FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE

Aber auch folgende syslog events traten auf, nachdem mittels:

lvmcreate -L 10G -n lv_snapshot -S vg/lv

ein snapshot erzeugt wurde.

kernel: EXT4-fs (dm-28): INFO: recovery required on readonly filesystem
kernel: EXT4-fs (dm-28): write access will be enabled during recovery
kernel: EXT4-fs warning (device dm-28): ext4_clear_journal_err:4718: Filesystem error recorded from previous mount: IO fail
ure
kernel: EXT4-fs warning (device dm-28): ext4_clear_journal_err:4719: Marking fs in need of filesystem check.
kernel: EXT4-fs (dm-28): recovery complete
kernel: EXT4-fs (dm-28): mounted filesystem with ordered data mode. Opts: (null)
kernel: EXT4-fs (dm-28): INFO: recovery required on readonly filesystem
kernel: EXT4-fs (dm-28): write access will be enabled during recovery
kernel: EXT4-fs (dm-28): orphan cleanup on readonly fs
kernel: EXT4-fs (dm-28): 6 orphan inodes deleted
kernel: EXT4-fs (dm-28): recovery complete

Schlimmer noch, die VMs wechselten nach kurzer Zeit in den read only Modus. Und konnten ohne erweitertes Filesystem Check nicht wieder gestart werden.

Zugglück sind wir schnell auf den Kernel Parameter gekommen, der das Problem verursacht hat.

Dieser Wert war bei älteren Servern noch auf 512 eingestellt. Bei den von dem Bug betroffenen Server durfte er nicht über 4096 eingestellt sein, stand aber immer wieder auf 8192.

Der CentOS Bug Report 12725, in dem das selbe verhalten mittels:

parted -s /dev/sda unit s print

beschrieben wurdet, half uns den Fehler weiter auf den Kernel einzuschränken. Immer wenn eine Partitionsabfrage, oder eine Änderung am LVM Stattgefunden hat, änderte sich der Wert plötzlich wieder auf 8192.

Folgende udev Regel, die wir unter /etc/udev/rules.d/99-san.rules eingefügt haben, verhinderte das umstellen des wertes:

Fazit:
Ein so schwerwiegenden Kernel Bug ist mit schon lange nicht mehr untergekommen. Er hatte für uns zufolge das wir bei einzelnen VMs nur noch teile retten konnten und komplett aus dem Backup wiederhergestellt werden mussten. Auch das Rechercheiren des Bugs ist bei CentOS kaum möglich. Da es zu RedHat binär kompatibel kann man nicht einfach durch ein git repository zu scrolen und sich die Änderungen und Kommentare anschauen. Wo bei mir die Überlegung offen ist, zukünftig auf einen Vanilla-Kernel zu wechseln und/oder CentOS zu vermeiden.

Unser Kernel: 3.10.0-514.6.1.el7.x86_64
Quelle Burgreport: https://bugs.centos.org/view.php?id=12725

2847 Tage Uptime

Mittwoch, Februar 8th, 2017

Nach dem der Cisco Switch beim Letzten Stromausfall nicht überlebt hat. Ist jetzt auch einer meiner ältesten Server nicht mehr da.
Bei einer Uptime von 2847 Tagen habe ich das Letzte Screenshot gemacht:

Neben der Uptime habe ich auch mittels dumpe2fs /dev/sda1 den Zeitpunkt anzeigen lassen wann das Filesystem das letzte mal ein gehangen wurde. Das war am 08.02.2009.

Da heutzutage Server Quasi täglich mit Sicherheitsupdates versorgt werden müssen und es mittlerweile stabile Livemigration von VMs gibt. Wird es bei mir nicht mehr vorkommen, dass ein Server eine derart hohe Uptime erreichen wird.

cisco: kex: algorithm: diffie-hellman-group1-sha1

Donnerstag, Dezember 1st, 2016

Auf unsere CISCO 4500 haben wir ein ios mit SSH. Leider ist das aber eine SSH die schon etwas in die Jahre gekommen ist. Somit meckert meine SSH unter Ubuntu 16.04 das die Ciphers (Verschlüsselungsverfahren) nicht erlaubt sind.

ssh admin@switch
Unable to negotiate with switch port 22: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1

Dies kann man zum Glück noch explizit aktivieren:
ssh admin@switch -oKexAlgorithms=+diffie-hellman-group1-sha1
Password:
Switch>

Damit ich zukünftig dies nicht immer wieder hier nachlesen muss. Habe ich dies in meine .ssh/config dauerhaft verdrahtet.

Host switch
KexAlgorithms=+diffie-hellman-group1-sha1


Die beiden Cisco 4500 kurz nach dem Einbau.

Error 0xc80003f3: Failed to execute MSU package.

Montag, November 28th, 2016

Es gibt nichts schöneres als diese Steinchen auf Stöckchen Probleme in Windows. Nach dem Installieren eines Steuer Programms kam Folgende Fehlermeldung:

Dies deutete daraufhin das bei der Installation von Visual C++ etwas schief gegangen ist.
Visual C++ Redistributable for Visual Studio 2017 (64-bit)

Bei der Installation wurde in der Logdatei folgende Meldung ausgegeben:
Error 0xc80003f3: Failed to execute MSU package.

Dies wiederum brachte mich zur folgenden Lösung. Ich habe das Windows6.1-KB2999226-x64.msu in der richtigen Version 64/86 heruntergeladen und ausgepackt. Darauf in mit DISM von Hand installiert:


C:\>mkdir XXXX

C:\>wusa.exe Windows6.1-KB2999226-x64.msu /extract:XXXX

C:\>DISM.exe /Online /Add-Package /PackagePath:XXXX\Windows6.1-KB2999226-x64.cab

Tool zur Abbildverwaltung für die Bereitstellung
Version: 6.1.7600.16385

Abbildversion: 6.1.7601.18489

1 von 1 werden verarbeitet - Paket "Package_for_KB2999226~31bf3856ad364e35~amd64
~~6.1.1.7" wird hinzugefügt
[==========================100.0%==========================]
Der Vorgang wurde erfolgreich beendet.

C:\>

Hiernach sind bei der Installation des vc_redist.x64.exe keine Fehler mehr aufgetreten.

Software Raid detached Devices

Montag, November 14th, 2016

Nachdem wir bei eine Software Raid eine defekte Platte getauscht haben, wurde diese immer noch in der mdadm Übersicht geführt sda1[2](F).
cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid1 sdc1[0] sda1[2](F) sdb1[1]
104320 blocks [2/2] [UU]

Das removen mit –remove ging leider nicht:
mdadm /dev/md0 --remove /dev/sda1
mdadm: cannot find /dev/sda1: No such file or directory

Hierfür muss man alle detached Devices entfernen:
mdadm /dev/md0 --remove detached
mdadm: hot removed 8:1