Neueste Einträge:

In der Version 1.5.1 der Extension macina_banners (Advanced Banner Management) scheint es ein Problem mit der Kategorisierung der Banner über mehrere Sysfolder zu geben. In meinem Fall wurden einfach alle Banner angezeigt, unabhängig von der Einstellung, die über typoscript getroffen worden ist. pidList = 123 wird also ignoriert. Das Problem trat in meinem Fall mit einer TYPO3 4.4-Installation auf.

Das Problem scheint im code der Extension zu liegen. Für das Problem ist nämlich bereits ein Fix verfügbar, welcher für die Version 1.5.2 der macina_banners geplant ist und aktuell darauf wartet eingebaut zu werden. Da 1.5.2 schon eine Weile auf sich warten lässt, habe ich den Code manuell übernommen.

Für eine schnelle Abhilfe kann die Extension also direkt editiert werden:

/pfad/zum/webserver/typo3conf/ext/macina_banners/pi1/class.tx_macinabanners_pi1.php

Hier fügen wir hinter den folgenden Zeilen (in Extension-Version 1.5.1 ist das nach Zeile 173)

// alle banner die die aktuelle page id nicht in  excludepages stehen haben
$where .= “AND NOT ( excludepages regexp ‘[[:<:]]”.$GLOBALS['TSFE']->id.”[[:>:]]’ )”;

den folgenden Code ein:

// FIX pidList beachten !! Version 1.5.2
if ( $conf['pidList'] != null && $conf['pidList'] != ” )
{
$where .= ” AND pid IN ( “.$conf['pidList'].” ) “;
}

Weiter Infos:

Bei einer aktuellen Debian Linux Installation in Verbindung mit PHP 5.3.3 aus dem Dotdeb-Repository gab es ein Problem mit der Session-Verwaltung:

Fatal error: session_start(): Failed to initialize storage module: files (path: ) in /path/to/php/script/session.inc.php on line 123

Zu lösen war das Problem recht einfach: In der php.ini war die Zeile (session.save_path) auskommentiert. Wird diese einkommentiert

session.save_path = “/tmp”

und der Apache neugestartet, ist das Problem behoben. In anderen Distributionen (OpenSUSE) ist der Speicherort von Haus aus über diese Methode angegeben. Bei einer PHP-Installation aus den Debian-Repositorys tritt das Problem möglicherweise auch nicht in Erscheinung (nicht weiter verfolgt).

Da die Lösung im HP PDF-Handbuch auf die Schnelle nicht zu finden war: Der Boot ohne Passwort ist bei einem Secure Router 7102dl folgendermaßen möglich:

Im ersten Schritt den Router über ein serielles Kabel mit dem Rechner verbinden. Router sollte ausgeschaltet sein (da wir im Bootvorgang aktiv werden müssen). PuTTY eignet sich als Software hervorragend. Connection type: Serial auswählen; Speed auf 9600 baud belassen). Router einschalten und folgende Meldung abwarten:

Executing bootstrap…
ram: 134217728 bytes of RAM detected.
Serial Number: US511XXXXX
Bootstrap version: J02.01, checksum: 9B84, Tue Mar 29 10:48:20 2005
flash: initializing flash devices…
flash: 33554432 bytes of FLASH detected at 0xfe000000 – dev 0x0001007e
vfs: NONVOL: 504 tracks, 64 sectors/track, 1024 bytes/sector.
eth0/1: initializing…
eth0/1: MAC address is 00:XX:XX:XX:XX:XX
bootstrap: Checking boot configuration…
bootstrap: Primary image is ‘NONVOL:/J02_01.biz’.
You have 5 seconds to press escape to enter bootstrap mode.

An dieser Stelle ESC drücken

bootstrap: User escaped to command line interface.
cli: starting user interface

Press ‘?’ for help.
bootstrap#

bypass passwords
boot

Der Zugriff auf den Router ist danach ohne Passwort möglich und man kann ein neues Passwort vergeben.

Eine nachträglich aktivierte bzw. installierte Netzwerkkarte (oder andere Hardware) kann in einer Microsoft Windows Server 2008 (R2) Core Installation oder einer Microsoft Hyper-V Server 2008 (R2) Installation einiges an Spass bedeuten.

In meinem Fall verfügen die betroffenen Server über zwei onboard Broadcom-Netzwerkkarten des gleichen Typs (d.h. es wird der gleiche Treiber verwendet). Jeweils eine der Karten war zum Installationszeitpunkt über das BIOS der Server deaktiviert. Gegen allen Erwartungen verweigerte die nachträglich aktivierte Netzwerkkarte den Dienst. Ein Remote-Zugriff auf den Gerätemanager unserer Hyper-V Server 2008 R2 Installation zeigte, dass die nachträglich aktivierte Karte einen Fehler 31 aufwies (das Gerät funktioniert nicht ordnungsgemäß, da Windows die für das Gerät erforderlichen Treiber nicht laden kann). Auf einem Standard-Windows hätte ich nun das Gerät neu installiert. Leider ist das ohne einen lokalen Gerätemanager nicht so ohne Weiteres möglich. Der Remote-Gerätemanager dient nur zur Ansicht.

Eine mögliche Lösung ist die Verwendung von Microsoft DevCon aus dem WDK (Windows Driver Kit). Der Download der .iso-Datei ist über 600 MB schwer. Es gibt die devcon.exe auch zum Einzeldownload – jedoch würde ich hier zumindest zur nötigen Vorsicht raten. Nach der Installation kann man das WDK entweder auf CD brennen oder – sofern man noch über wenigstens eine funktionierende Netzwerkkarte verfügt – entpacken und auf den Server kopieren.

Nach dem Download und der Installation des WDK befindet sich devcon unter dem ausgewählten Installationspfad wie folgt wieder (es sind drei Versionen für ia64, amd64 und i386 verfügbar):

C:\Tools\WinDDK\Tools\devcon\amd64\devcon

DevCon scheint insgesamt nicht sehr beliebt zu sein. Die meisten Probleme entstehen wohl bei der Suche nach der passenden Hardware-ID der betroffenen Hardware. Wie so oft führen viele Wege nach Rom. Im Fall der nicht funktionierenden Netzwerkkarte halte ich das folgende Vorgehen für gut:

Der folgende Befehl listet uns die Hardware auf, die der Klasse net entspricht:

C:\Tools\WinDDK\Tools\devcon\amd64>devcon hwids =net

PCI\VEN_14E4&DEV_165B&SUBSYS_705D103C&REV_10\4&1A5F56DF&0&00E5
Name: HP NC107i PCIe Gigabit Server Adapter
Hardware IDs:
PCI\VEN_14E4&DEV_165B&SUBSYS_705D103C&REV_10
PCI\VEN_14E4&DEV_165B&SUBSYS_705D103C
PCI\VEN_14E4&DEV_165B&CC_020000
PCI\VEN_14E4&DEV_165B&CC_0200
Compatible IDs:
PCI\VEN_14E4&DEV_165B&REV_10
PCI\VEN_14E4&DEV_165B
PCI\VEN_14E4&CC_020000
PCI\VEN_14E4&CC_0200
PCI\VEN_14E4
PCI\CC_020000
PCI\CC_0200

PCI\VEN_14E4&DEV_165B&SUBSYS_705D103C&REV_10\4&29F6B73F&0&00E4
Name: HP NC107i PCIe Gigabit Server Adapter #2
Hardware IDs:
PCI\VEN_14E4&DEV_165B&SUBSYS_705D103C&REV_10
PCI\VEN_14E4&DEV_165B&SUBSYS_705D103C
PCI\VEN_14E4&DEV_165B&CC_020000
PCI\VEN_14E4&DEV_165B&CC_0200
Compatible IDs:
PCI\VEN_14E4&DEV_165B&REV_10
PCI\VEN_14E4&DEV_165B
PCI\VEN_14E4&CC_020000
PCI\VEN_14E4&CC_0200
PCI\VEN_14E4
PCI\CC_020000
PCI\CC_0200
2 matching device(s) found.

“devcon classes” gibt übrigens eine Liste der verfügbaren Geräte-Klassen aus.

Nun können wir uns den Status der Geräte anzeigen lassen:

C:\Tools\WinDDK\Tools\devcon\amd64>devcon status “PCI\VEN_14E4&DEV_165B&SUBSYS_705D103C&REV_10″

PCI\VEN_14E4&DEV_165B&SUBSYS_705D103C&REV_10\4&1A5F56DF&0&00E5
Name: HP NC107i PCIe Gigabit Server Adapter
Driver is running.

PCI\VEN_14E4&DEV_165B&SUBSYS_705D103C&REV_10\4&29F6B73F&0&00E4
Name: HP NC107i PCIe Gigabit Server Adapter #2
The device has the following problem: 31
2 matching device(s) found.

Das Gerät zu deaktivieren und zu reaktivieren brachte keinen Erfolg – daher werden beide Netzwerkkarten entfernt:

C:\Tools\WinDDK\Tools\devcon\amd64>devcon remove “PCI\VEN_14E4&DEV_165B&SUBSYS_705D103C&REV_10″

C:\Tools\WinDDK\Tools\devcon\amd64>devcon reboot

Der “devcon reboot” war in meinem Fall leider notwendig. Ein einfaches “devcon rescan” erkannte die beiden Karten zwar, sorgte jedoch bei einer der Karte für einen neuen Fehler. Nach dem Neustart wurden die Karten nun korrekt erkannt. Man kann das System natürlich auch über andere Wege neustarten lassen ;-).

C:\Tools\WinDDK\Tools\devcon\amd64>devcon status “PCI\VEN_14E4&DEV_165B&SUBSYS_705D103C&REV_10″

PCI\VEN_14E4&DEV_165B&SUBSYS_705D103C&REV_10\4&1A5F56DF&0&00E5
Name: HP NC107i PCIe Gigabit Server Adapter
Driver is running.

PCI\VEN_14E4&DEV_165B&SUBSYS_705D103C&REV_10\4&29F6B73F&0&00E4
Name: HP NC107i PCIe Gigabit Server Adapter #2
Driver is running.

Hilfreich beim Arbeiten mit DevCon sind die folgenden Seiten:

Bei der Installation eines Microsoft Windows Server 2008 R2 erhielt ich kürzlich folgende Fehlermeldung:

Windows kann nicht in dem gewählten Pfad installiert werden. Fehler: 0×80300001

Problemlösung bei mir: Einfach die Windows-Setup-CD wieder einlegen und im Partitionsmenu auf einen nicht aktiven Menupunkt klicken ;-)

Was war passiert? Um auf den eingebauten 3ware RAID-Controller zuzugreifen musste ich über die Option “Treiber laden” die 3ware-Treiber von der 3ware-CD laden.

Nach der Partitionierung der Festplatte über das Windows-Setup befand sich die 3ware-CD immer noch im Laufwerk und Windows schmiss einen irreführenden Fehler 0×80300001. Nach einiger Sucherei an falscher Stelle habe ich die Windows-CD wieder eingelegt und das Problem war erledigt.

Diese falsche Fehlermeldung wird übrigens auch bei Windows 7 ausgegeben – unglaublich.

Powered by WordPress
Theme basiert auf Motion