centos – Welches Repro hält welche Version eines Pakets bereit

Das Beste ist natürlich wenn man von Systemkritischen Paketen ein eigenens Repro hat und dann dort nach und nach Updates einspielt. Vorher hat man diese optimalerweise in einem Staging Verfahren getestet (dev -> test -> produktion).

Um auf die Schnelle aus verschiedenen aktivierten Repros herauszufinden, welches Repro welche Version bereitstellt ist die Option „–showuplicates“ sehr angenehm.

yum list available --showduplicates packagename

Kann dann für z.B. puppet aus den Repros EPEL (alt), RPMForge (2.7.x) und YUM.PuppetLabs.com so aussehen:

Console_yum_list_available_showduplicates

Trixbox v2.6.2.3 und Sipgate Account

Da ich heute abend einen Fli4l Teamkollegen bei seiner ersten Trixbox geholfen habe, schnell das erfahrene niederschreiben :). Wichtig ist der Context „from-pstn“ in den Peer Details, sonst landen die eingehende Rufe irgendwo und werden mit „Dieser Anschluss ist vorrübergehend nicht erreichbar“ abgelehnt. Eine Inbound Route sollte auch gesetzt sein.

switch user -> dann Benutzer maint mit Passwort password

Unter „Trunks“ erstellen man einen „Sip Trunk“.

Wenn 1234567 der Username bei Sipgate ist, sowie 055511155555 die Rufnummer diesen wie folgt hinterlegen:


Outbound Caller ID: 1234567

PEER Details:
host=sipgate.de
domain=sipgate.de
username=1234567
fromuser=1234567
fromdomain=sipgate.de
secret=SEHRGEHEIM
type=peer
insecure=invite
canreinivite=no
disallow=all
allow=alaw
nat=no
context=from-pstn
; qualify=yes

Registration
Register String:

1234567:SEHRGEHEIM@sipgate.de/055511155555

Intel D945GCLF und Realtek r8101.ko BUG: soft lookup- CPU#1 stuck for 11s! halt:7887]

Diese formschöne Fehlermeldung erhält man mit dem Intel Atom Barebone Board D945GCLF Chipsatz. Ich habe gerade Ubuntu 8.04.1 aka Hardy am Wickel. 2.6.24-23-generic Kernel.

Man kann sich zwischen verschiedenen BUGs entscheiden. Der r8169 Treiber verursacht „dropped“ Packets laut ifconfig, segfaultet auch gern bei der Installation:

eth0      Link encap:Ethernet  Hardware Adresse 00:1c:c0:8d:c9:2d
inet Adresse:192.168.200.136  Bcast:192.168.200.255  Maske:255.255.255.0
inet6-Adresse: fe80::21c:c0ff:fe8d:c92d/64 Gültigkeitsbereich:Verbindung
UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
RX packets:3261 errors:0 dropped:4143098811 overruns:0 frame:0
TX packets:3198 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:1000
RX bytes:3130291 (2.9 MB)  TX bytes:606778 (592.5 KB)
Interrupt:220 Basisadresse:0x2000

Also den r8101.ko Treiber installieren vom Netzwerkkartenhersteller Realtek. Dieser Segfaultet nicht beim Starten des Rechners. Dafür hängt er beim Runterfahren des Rechners mit der Fehlmeldung

„BUG: soft lockup – CPU#1 stuck for 11s! [halt:7887]“

Hierzu gibt es bereits ein Bugreport. Als Workaround habe ich erstmal r8101.ko geblacklistet. Damit mir r8169.ko nicht einfach so abschmiert habe ich dbus-daemon deaktiviert. Ähnliche Probleme werden auch mit.

http://www.greenwireit.com/blog/2009/02/nc91-230-lf-progress-update-linux-issues/

Eine mögliche Lösung dieses Problems besteht in einen Kernelpatch wie http://linuxtrek1.blogspot.com/2008/10/ubuntu-on-intel-d945gclf-with-intel.html beschrieben.

Phoenix BIOS Mainboard Tyan S2676 „CANNOT FLASH IF MEMORY MANAGERS (E.G. HIMEM/EMM386) PRESENT“

FreeDOS LiveCD

FreeDOS LiveCD

Ein schöner Patient. Das Tyan Mainboard S2676 mit alten BIOS möchte geflasht werden. Okay. Leider wollte das Floppylaufwerk nicht, vielleicht ist auch der Port defekt. Also alternative Flashmethoden erkunden. Tyan hat drei verschiedene BIOS Hersteller AMI, Award und Phoenix.

Natürlich hab ich den Hauptgewinn erzielt – ein Phoenix BIOS. Ein Windows Updatetool gibt es hierfür nicht. Ein flashen von USB Stick (wie bei ASUS Easyflash z.b.) ist auch nicht vorgesehen.

Coreboot bietet auch eine Methode zum direkt flashen von BIOS Dateien. Da ich dies noch nicht verwendet habe, lass ich Jugend forscht bei Seite und nehme mir FreeDOS vor.

Das Zielsystem benötigt noch eine FAT16 oder FAT32 Partition. Unter VERWALTUNG > DATENTRÄGERMANGEMENT erstelle ich eine ca 35MB große Partition und formatiere diese mit FAT32. Hernach kopiere ich die Updatedateien herein. Entpacke diese und boote FreeDOS.

Eine c’t Notfall CD 26/2007 liegt noch rum, auf der ist ein FreeDOS drauf. Allerdings bekomme ich dort „CANNOT FLASH IF MEMORY MANAGERS (E.G. HIMEM/EMM386) PRESENT“ vom plash16.exe präsentiert. Später lese ich noch von undokumentierte Schalter zum unterdrücken dieser Meldung. Dann lieber FreeDOS ohne c’t Anpassungen ausprobieren. Wichtig ist das man das ca 154MB große LiveCD Image herunterlädt.

FreeDOS LiveCD Bootauswahl

FreeDOS LiveCD Bootauswahl

Dort „FreeDOS LiveCD only“ in der Bootauswahl nehmen. Dann auf mittels „cd c:“  auf die Datenpartition wechseln. Interessant. Klappt nicht. Ein „dir c:\s2676\“ zeigt die Dateien und eine kleine Batchdatei. Diese ruft plash16.exe mit den Update als Parameter auf. Okay, schreib ich mittels edit die Batchdatei um. Aufrufen und der Spass beginnt :-).

FreeDOS Tyan Phoenix BIOS Update mit Phlash16

FreeDOS Tyan Phoenix BIOS Update mit Phlash16

Gelegenheitsblogger …

Ja,  die Sitzpisser des Internets – Gelegenheitsblogger.

Wie passiert sowas?
Warum muss man sein WordPress öfter aktuallisieren als neue Einträge in einen Jahr ins Blog fliessen?
Ich red mich jetzt mal raus mit viel Stress im Job. Dann neuer Job, wieder viel Stress. Arbeiten hindert in gewissen Maße das Bloggen. Und Familie. Kinder sind auch zeitintensiv.

Ich gelobe Besserung!

VirtualBox 1.4.0 und OpenBSD Gast mit IDE timeouts unter Debian GNU/Linux

habe mich einen paar Stunden mit VirtualBox 1.4.0 binary Version rumgeärgert. Mein Debian Etch sollte ein OpenBSD 4.0 beherbergen. Leider kam immer beim anlegen der Partitionstabelle folgende Fehlermeldung:

wd0c: device timeout writing fsbn 0 (wd0 bn 0; cn 0 tn 0 sn 0), retrying
wd0(pciide0:0:0): timeout
type: ata
c_bcount: 512
c_skip: 0

Lösung: Die Version 1.4.0 hat einen Bug. SVN Version holen und kompilieren.

VirtualBox 1.4.0 und OpenBSD als Gast unter Debian GNU/Linux

#1017 – Can’t find file: ‚frm‘ (errno: 13)

Aua aua, nach dem das Freifunk Wiki in Hannover heute mit der Datenbank (naja eigentlich ohne Datenbank) Probleme bekam, hab ich mir doch nochmal mein MySQL Backup angeschaut. Beim Script schreiben ist mir ein „chmod 0600 datenbank“ blöderweise im falschen Ordner entfleucht. Sprich einige Ordner unterhalb von /var/lib/mysql waren nicht mehr durchschreitbar (+x) für den mysql Server. Super. Da bekommt man dann den o.g. Fehler beim reparieren der Datenbank (z.B. mit PhpMyAdmin). Sauber. Das Backup konnt trotzdem gebrauchen, einige Tabellen haben sich dann doch verabschiedet.