forum.opsi.org

Hallo zusammen,

Wir haben einen Rechnertyp in der Testumgebung, der Sorgen macht:
- Rechner-Typ: HP ProDesk 600 G3 MT (Y3E02AV)
- Bios-Modus: Legacy-Modus.
- Linux-Boot-Image: opsi-linux-bootimage_20170720-1_i386.deb
Nachtrag 08.03.2018:
- Alle Treiber sind digital signiert
- Opsi-Version 4.0.7.52

Die Treiber (einmal per DoubleDriver, einmal per Hersteller-Seite) wurden byAudit eingebunden.
Da der Rechnertyp zwei Kennungen liefert, habe ich das Verzeichnis und einen Symlink erzeugt.

./showdrivers findet ohne Probleme alle Treiber und listet (bis auf den nativen USB3.0)-Treiber alles grün.

Installation startet und läuft durch. Im Log werden alle notwendigen Treiber als erfolgreich kopiert gelistet.

Nach der Anmeldung dann die Ernüchterung:
- Standard-Microsoft Grafik-Treiber
- Ungefähr 6 Systemkomponenten nicht gefunden

Treiber von Hand über den Systemmanager nachinstalliert, als Quelle "C:\drv" angegeben: ERFOLG

Alle Treiber werden durch Opsi auf die Platte kopiert, dann aber nicht oder nur bedingt installiert.

Für Hinweise bin ich dankbar.


Grüße

Patrick

Ergänzung 08.03.2018:

Konfiguration 1:
- Bios-Modus: Legacy-Modus.
- Linux-Boot-Image: opsi-linux-bootimage_20170720-1_i386.deb

-> Windows installiert
-> Treiber liegen unter c:\drv
-> Treiber werden teilweise ignoriert (GraKa und Systemkomponenten)
-> Manuelle Treiberaktualisierung aus c:\drv ist ohne Einschränkung erfolgreich

Konfiguration 2:
- Bios-Modus: UEFI-Modus.
- Linux-Boot-Image: opsi-linux-bootimage_20170720-1_i386.deb

-> Installation bleibt beim Laden des miniroot hängen (Wartezeit bis zum manuellen Abbruch ca. 5 Minuten)

Konfiguration 3:
- Bios-Modus: Legacy-Modus.
- Linux-Boot-Image: opsi-linux-bootimage_20180226-1_i386.deb

-> Installation bleibt mit der Fehlermeldung "Could not find ramdisk image:miniroot.bz2" hängen

Konfiguration 4:
- Bios-Modus: Uefi-Modus.
- Linux-Boot-Image: opsi-linux-bootimage_20180226-1_i386.deb

-> Windows installiert erfolgreich inklusive aller Treiber
-> UEFI-Bootreihenfolge wird verändert: Windows Boot Manager verdrängt PXE von erster Stelle

Zu Konfiguration 3:
Das Bootimage ist größer als 90MB in experimental. Hierfür muss auch der opsi-atftpd aus experimental aktualisiert werden, der wurde entsprechend gepatcht.

Wie neu ist der Rechner?
Der Kernel muss den Rechner natürlich unterstützen. dementsprechend ist das Bootimage aus Testing bzw experimental in solchen Fällen ratsam

Gruß
Mathias

Hallo,
vielen Dank zum Hinweis zur Konfiguration 3.
Ich werde nächste Woche ebenfalls auch mal den atftpd aktualisieren.

Nachtrag zur Konfiguration 2:
Es scheint, als bleibe nur die Anzeige schwarz und im Hintergrund passierten Aktionen.
Wartet man noch länger, bootet der Rechner irgendwann neu und startet die WinPE-Installation.
Aber auch hier ist das (für Folgeinstallationen ungünstige) "Problem":
-> UEFI-Bootreihenfolge wird verändert: Windows Boot Manager verdrängt PXE von erster Stelle

Generell steht die Frage im Raume, direkt auf 4.1 zu gehen. Allerdings möchte ich jetzt erst einmal diesen Fehler beheben.

Der Rechner selbst ist in 11/2017 bestellt und geliefert worden.

Aber prinzipiell funktioniert er ja. Die Installation läuft in allen Fällen bis zum Desktop durch und alle Treiber sind anschließend auf der Festplatte vorhanden.

Anmerkung:
In Rücksprache mit anderen OPSI-Administratoren scheint dies ein typisches Fehlerbild speziell für neuere HP-Rechner zu sein.

Grüße

Patrick

evtl hilft sukzessive Abkochen/Aussortieren der Treiber oder ein Blick in die Pathelog vgl.: https://download.uib.de/opsi_stable/doc ... 6-logfiles

oder aber das uns zur Verfügung stellen eines Geraetes im Rahmen eines Supportvertrags.

Gruss
Bardo Wolf

Im Februar hat UIB (OPSI) ein neues Bootimage (08.02.2018, experimental) erstellt. Dort ist ein Intel-Grafiktreiber integriert speziell für UEFI integriert worden. Am besten mal im LAB-Netz mit einem Klon von der OPSI-VM experimentieren.

1. Treiberinstallation
Sehr interessant, das.
Nur noch mal zur Klarstellung: weder das bootimage, noch WinPE haben irgendwelche Aktien in der Installation von Treibern ins eigentliche Betriebssystem. Bis auf das Kopieren der - so vorhandenen - Treiberdateien nach schlußendlich c:\drv.
Die eigentliche Installation der Treiber erfolgt während der Setup-Phase.
Und warum das bei Dir im UEFI-Modus funktioniert, und im Legacy-Modus nicht, ist die spannende Frage.
Erste Anlaufstelle wären für mich die Panther-Logs.

2. Bootreihenfolge
Auch das ist unabhängig von bootimage und/oder WinPE.
Hier setzt das Setup einen neuen UEFI-Booteintrag. Und da Microsoft nach wie vor mit der Attitüde 'ich bin wichtig, laßt mich durch' arbeitet, mit höchster Priorität.
Da wird wohl nichts anderes übrigbleiben, als die Reihenfolge im Nachgang wieder anzupassen. Entsprechende Befehle muß ich leider schuldig bleiben, da ich mich bisher (gottseidank) mit UEFI noch nicht ernsthaft herumschlagen mußte.

das uns zur Verfügung stellen eines Geraetes im Rahmen eines Supportvertrags.

Ich habe darüber nachgedacht, den Rechner einzusenden. Allerdings steht das Rollout für Mittwoch auf dem Plan und bis dahin wäre der sicherlich nicht wieder hier (wie üblich arbeitet man unter Druck am besten und schiebt solche Rollouts bis zur letzten Sekunde vor sich her )
Ich kläre das mit dem Kunden ab, ob er noch einige Zeit warten kann.

Nur noch mal zur Klarstellung: weder das bootimage, noch WinPE haben irgendwelche Aktien in der Installation von Treibern ins eigentliche Betriebssystem.

Ohne mich mit der Mechanik der Treiberverteilung unter Opsi befasst zu haben, muss ich diese Aussage in Frage stellen, aber erst einmal so hinnehmen. Schließlich werden die Treiber im UEFI-Modus korrekt eingebunden.
Die Vermutung war, dass die Treiber entweder per /InstallDrivers-Parameter der setup.exe oder drvload ins WinPE und/oder zusätzlich über Post-Scripts per PnPUtil oder DevCon eingebunden zu "erzwungen" installiert werden.

Erste Anlaufstelle wären für mich die Panther-Logs.

Auf die Idee bin ich nicht gekommen - aber erstmal einen Kaffee, dann gehe ich die Sache an. Vielen Dank hierfür.

2. Bootreihenfolge

Auch hier war meine Vermutung, dass die Änderung der Bootreihenfolge nach erfolgreichem Setup bereits durch Post-Scripts im Opsi oder gar den Opsi-Client-Dienst wieder "gerade gezogen" wird. Ein Flag á la "Force Pxe first" in der Client-Config könnte sich als nützlich erweisen.
Hierzu noch eine Frage, die sich praktisch in 15 Minuten beantworten ließe: Kann die Boot-Reihenfolge durch das Setup auch bei gesetztem Bios-Passwort verändert werden? Das wäre - MS-Hoheit hin oder her - eine gravierende Sicherheitslücke. SecureBoot soll deaktiviert bleiben.

Im Februar hat UIB (OPSI) ein neues Bootimage (08.02.2018, experimental) erstellt. Dort ist ein Intel-Grafiktreiber integriert speziell für UEFI integriert worden. Am besten mal im LAB-Netz mit einem Klon von der OPSI-VM experimentieren.

Ich kann nicht ganz folgen. Mit dem experimentellen BootImage klappt es ja. Was natürlich dafür spricht, dass eben doch das Linux-BootImage seine Finger bei der Treiberintegration m Spiel hat.
"Wir" haben zwar 7000 UEFI-Lizenzen gekauft (2000 + 5000), dennoch stellt der Einsatz von UEFI für uns aufgrund dieser Boot-Reihenfolgen-Drangsalierung durch MS noch immer eher die Ausnahme dar. Da müssen noch einige Kaffees die Kehle runtergehen, bevor wir uns genötigt sehen, eigene Pakete und Scripte zur Manipulation des Bios zu basteln - ich für meinen Teil bevorzuge native Lösungen, die nicht versehentlich durch das nächste Produkt-Update überschrieben werden

Nachtrag 12.03.2018:
Wie ich gerade von meinem Kollegen Schaefer erfahren habe, hat dieser die Problematik "Bootreihenfolge" (um die es hier ja primär garnicht ging) bereits mit Herrn Wolf besprochen und den Hinweis auf das Paket "opsi-uefi-netboot" bekommen. Damit ist mein letzter Satz obsolet
(Quelle: https://download.uib.de/opsi4.0/product ... 0.5-3.opsi )
Ist halt die Problematik, wenn Themen sich vermischen.

ABER: Auch er hat die Erfahrung gemacht, dass HP-Rechner sogar auf dieses Paket nicht anspringen.

Ohne mich mit der Mechanik der Treiberverteilung unter Opsi befasst zu haben, muss ich diese Aussage in Frage stellen, aber erst einmal so hinnehmen. Schließlich werden die Treiber im UEFI-Modus korrekt eingebunden.

Das trifft mich jetzt schon hart. Da stellt einfach jemand meine Aussage in Frage. Unglaublich.
Versuchen wir es noch mal etwas detaillierter.
1. bootimage
Macht neben vielen anderen lustigen Dingen auch ein hardware inventory. Und kopiert, so vorhanden aus /drivers passende Treiberdateien lokal.
Zuerst nach /mnt/hd/drv/drvpe, und später auf die WinPe-Partition.
2. WinPE
Lädt in der Tat, so notwendig, Treiber per drvload nach. Das betrifft aber nur WinPE.
Wenn WinPe irgendwann mit dem OPSI-Server kommunizieren kann, wird schlußendlich nur ein 'setup.exe /unattend\unattend.xml' aufgerufen.
Also keine weitere Parametrisierung hinsichtlich Treiber.
3. Setup-Phase
Die Treiberintegration wird nur über die unattend.xml gesteuert. Relevanter Eintrag: Und nein, es gibt keine postinstall-scripts, die sich mit der Treiberintegration befassen.
Und ja, das Verhalten der Maschine ist interessant.

(Die spannenden Skripte sind setup.py und setup.opsiscript)

Das trifft mich jetzt schon hart. Da stellt einfach jemand meine Aussage in Frage. Unglaublich.

Ich hoffe, ich habe nicht das Fundament deiner Welt erschüttert

Erster Kaffee ist durch, aber "leider" auch eine erste Besprechung, die zeitlich eine Aufarbeitung aller hier erhaltenen Infos verhinderte.
Ebenso konnte ich die Aussagen meines Kollegen noch nicht verifizieren.

Fakt ist aber, ich habe gerade den Auftrag bekommen, einen Rechner für die Fehlerbehebung zu bestellen, den wir dann über den Support-Vertrag uib zur Verfügung stellen können.