Fehler bei der Verifizierung des .Net-Frameworks 3.5

Fehler bei der Verifizierung des .Net-Frameworks 3.5

Postby hbuhrmester » 11.10.2013, 22:17

Hallo,

ich habe gestern versucht, ein neu installiertes Windows XP auf den aktuellen Stand zu bringen. Für den Download der Updates habe ich das Linux-Skript DownloadUpdates.sh in der Version 8.4 benutzt. Ich konnte den Fehler aber auch mit der aktuellen Version 8.6 verifizieren.

Die Betriebssystemauswahl und die weiteren Eingaben in der Konsole waren:

Code: Select all
OS: 1, Windows XP
Sprache: b, deutsch
Servicepacks: y
.Net framwork: y
Microsoft Security Essentials: n
Windows Defender: n
Proxy: keiner
ISO-Image: n


Bei der Installation der Pakete unter Windows habe ich eine Fehlermeldung bei der Installation des .Net Frameworks 3.5 bekommen:

Code: Select all
Checking .NET Framework 3.5 SP1 installation state...
Installing .NET Framework 3.5 SP1...
Verifying integrity of ..\dotnet\dotnetfx35.exe...
hashdeep.exe: Unable to load any matching files.
Try `hashdeep.exe -h` for more information.
ERROR: File hash does not match stored value (file: ..\dotnet\dotnetfx35.exe).
ERROR: Installation of ..\dotnet\dotnetfx35.exe failed (errorlevel: ).
Warning: .NET Framework 3.5 SP1 Language Pack installation file (..\dotnet\x86-glb\dotnetfx35langpack_x86de*.exe) not found.
Warning: Update kb958481 not found.
Warning: Update kb958483 not found.
Warning: Update kb958484 not found.

Installation successful. Please reboot your system now and recall Update afterwards.


Die Installation ist bei meinen Versuchen zweimal an derselben Stelle abgebrochen. Obwohl offensichtlich ein Fehler aufgetreten ist und das .Net Framework 3.5 nicht installiert wurde, und auch keine weiteren Updates, hieß es am Ende "Installation successful". Das ist wahrscheinlich ein Bug im Installationsskript DoUpdate.cmd. Aber ich wollte mich ja auf die Linux-Seite konzentrieren...

Das Problem war offenbar die Integritätsprüfung bei der Installation. Nachdem ich die Integritätsprüfung deaktiviert hatte, konnte ich auch das .Net Framework 3.5 ohne Fehlermeldungen installieren.

Tatsächlich enthält der Ordner "client/dotnet" fünf Exe-Dateien für die Frameworks 3.5, 4.0 und 4.5:

Code: Select all
dotnetfx35.exe
dotNetFx40_Full_x86_x64.exe
dotNetFx40LP_Full_x86_x64de.exe
dotnetfx45_full_x86_x64.exe
dotNetFx45LP_Full_x86_x64de.exe


Die Datei client/md/hashes-dotnet.txt enthält aber nur Hashwerte für die letzte dieser Dateien, während die Prüfsummen für die ersten vier Dateien fehlen.

Der Fehler muss im Shellskript DownloadUpdates.sh liegen, in diesem Block ab Zeile 843:

Code: Select all
  echo "Creating integrity database for .Net ..."
  cd ../client/bin
    for Datei in ../dotnet/*.exe
    do
    test -s "$Datei" && \
    hashdeep -c md5,sha1,sha256 -l "$Datei" | tr '/' '\\' > ../md/hashes-dotnet.txt
    done
  cd "$PATH_PWD"


Nun gibt es einen feinen Unterschied zwischen "Redirecting Output" (>) und "Appending Redirected Output" (>>). So wie es aussieht, wird die Datei hashes-dotnet.txt in der for-Schleife viermal auf Null zurückgesetzt.

Als einfachen Patch könnte man schreiben:

Code: Select all
  echo "Creating integrity database for .Net ..."
  cd ../client/bin
    rm --force ../md/hashes-dotnet.txt
    for Datei in ../dotnet/*.exe
    do
    test -s "$Datei" && \
    hashdeep -c md5,sha1,sha256 -l "$Datei" | tr '/' '\\' >> ../md/hashes-dotnet.txt
    done
  cd "$PATH_PWD"


Oder, wenn die Idee ist, auf leere Dateien zu testen und diese zu überspringen, dann kann man diese leeren Dateien auch gleich ganz löschen:

Code: Select all
  echo "Creating integrity database for .Net ..."
  cd ../client/bin
    for Datei in ../dotnet/*.exe
    do
        test -s "$Datei" || rm "$Datei"
    done
    hashdeep -c md5,sha1,sha256 -l ../dotnet/*.exe | tr '/' '\\' > ../md/hashes-dotnet.txt
  cd "$PATH_PWD"


Ausserdem scheint der Ordnername "client/dotnet/x86-deu" falsch zu sein. Erwartet wird im Skript eher "client/dotnet/x86-glb", sodass das deutsche Languagepack nicht gefunden wird (siehe Fehlermeldung oben). Die Datei client/md/hashes-dotnet-x86-glb.txt ist ganz leer (0 Bytes). Oder vielleicht sollten es tatsächlich zwei getrennte Ordner sein?

Als Fix habe ich einmal einen symbolischen Link im Verzeichnis client/dotnet/ erstellt:

Code: Select all
ln -s x86-deu x86-glb


Nach dem nächsten Aufruf von DownloadUpdates.sh hatte die Datei hashes-dotnet-x86-glb.txt nun eine Größe von 19,4 KB.

Leider unterstützt Windows XP keine symbolischen Links (Windows Vista angeblich schon). Ich musste den Ordner client\dotnet\x86-deu deshalb noch einmal nach client\dotnet\x86-glb kopieren. Dann hatte der UpdateInstaller.exe aber noch einmal 15 zusätzliche Updates installiert, alle aus dem Verzeichnis client\dotnet\x86-glb.

Viele Grüße,

Hartmut Buhrmester
hbuhrmester
 
Posts: 326
Joined: 11.10.2013, 21:59

Re: Fehler bei der Verifizierung des .Net-Frameworks 3.5

Postby boco » 12.10.2013, 18:11

Windows unterstützt den Link-Kram schon, allerdings bietet es keinerlei komfortable Möglichkeit der Erstellung solcher Links. Die Link Shell-Extension nimmt sich des Problems an (http://schinagl.priv.at/nt/hardlinkshel ... llext.html).

Es gibt sogar Treiber die SymbolicLink-Funktionalität auf WinXP bereitstellen (gibt es auf oben genannter Seite auch).
Microsoft update catalog: http://catalog.update.microsoft.com/v7/site/
Windows Install media download: https://support.microsoft.com/en-us/help/15088/windows-create-installation-media
boco
 
Posts: 2030
Joined: 24.11.2009, 18:00
Location: Germany

Re: Fehler bei der Verifizierung des .Net-Frameworks 3.5

Postby hbuhrmester » 15.10.2013, 23:00

Weitere Änderungen:

Ich hatte bereits den Verdacht geäußert, dass das Verzeichnis client/dotnet/x86-deu einen falschen Namen hat und durch client/dotnet/x86-glb ersetzt werden sollte.

Tatsächlich gibt es im Verzeichnis wsusoffline/static Vorlagen für die verschiedenen Sprachen. Für die .Net Downloads liest das Skript DownloadUpdates.sh aber alle Vorlagen ein und fasst sie zu zwei neuen, sprachunabhängigen Dateien zusammen. Die Installierer für die .Net Frameworks 3.5, 4.0 und 4.5 landen im Verzeichnis client/dotnet. Alle Updates und auch die deutschen Sprachpakete landen im Unterverzeichnis client/dotnet/x86-glb.

Dann muss man nur herausfinden, wo das Verzeichnis client/dotnet/x86-deu verwendet wird. In der Datei DownloadUpdates.sh heißt es ab Zeile 831:

Code: Select all
# dotnet/cpp
if [ "$dotnet" == "1" ]; then
#    Vz=dotnet
#    Txt=".Net "
#    down_msse_cpp
  echo "Downloading .Net framework..."
  mkdir -p ../client/dotnet/${OS_ARCH}-$lang
  doWget -i ../temp/StaticUrls-dotnet.txt -P ../client/dotnet
  mv ../temp/Urls-dotnet-${OS_ARCH}.txt ../temp/Urls-dotnet-${OS_ARCH}.tmp
  grep -i -v -f ../exclude/ExcludeList-dotnet-${OS_ARCH}.txt ../temp/Urls-dotnet-${OS_ARCH}.tmp > ../temp/Urls-dotnet-${OS_ARCH}.txt
  doWget -i ../temp/Urls-dotnet-${OS_ARCH}.txt -P ../client/dotnet/${OS_ARCH}-$lang


In diesem Block muss man client/dotnet/${OS_ARCH}-$lang zweimal durch client/dotnet/${OS_ARCH}-glb ersetzen:

Code: Select all
# dotnet/cpp
if [ "$dotnet" == "1" ]; then
#    Vz=dotnet
#    Txt=".Net "
#    down_msse_cpp
  echo "Downloading .Net framework..."
  mkdir -p ../client/dotnet/${OS_ARCH}-glb
  doWget -i ../temp/StaticUrls-dotnet.txt -P ../client/dotnet
  mv ../temp/Urls-dotnet-${OS_ARCH}.txt ../temp/Urls-dotnet-${OS_ARCH}.tmp
  grep -i -v -f ../exclude/ExcludeList-dotnet-${OS_ARCH}.txt ../temp/Urls-dotnet-${OS_ARCH}.tmp > ../temp/Urls-dotnet-${OS_ARCH}.txt
  doWget -i ../temp/Urls-dotnet-${OS_ARCH}.txt -P ../client/dotnet/${OS_ARCH}-glb


Damit landen die Updates im richtigen Ordner. Wenn man aber die Downloads unter Linux mit denen der Windows-Version von wsusoffline vergleicht, dann sind es zuviele Updates: Im Ordner dotnet/x86-glb finden sich in der Linux-Version 44 zusätzliche Dateien gegenüber der Windows-Version.

Der Grund ist anscheinend, dass das Linux-Skript nicht alle Ausnahmenlisten berücksichtigt: Es gibt eine Datei exclude/ExcludeList-dotnet-x86.txt mit Ausnahmen speziell für die .Net Frameworks. Die allgemeine Liste exclude/ExcludeList-superseded.txt enthält Kennungen für veraltete Updates, auch für die .Net Frameworks.

Das Skript DownloadUpdate.sh berücksichtigt zurzeit nur die erste Liste. Als Fix muss man beide Ausnahmenlisten zusammenfügen und von der Liste der .Net Downloads abziehen.

Code: Select all
# dotnet/cpp
if [ "$dotnet" == "1" ]; then
#    Vz=dotnet
#    Txt=".Net "
#    down_msse_cpp
  echo "Downloading .Net framework..."

# combine ExcludeList-dotnet-${OS_ARCH}.txt and ExcludeList-superseded.txt
  rm -f ../temp/tmpExcludeList-dotnet-${OS_ARCH}.txt
  touch ../temp/tmpExcludeList-dotnet-${OS_ARCH}.txt
 
  test -f ../exclude/ExcludeList-dotnet-${OS_ARCH}.txt && \
      cat ../exclude/ExcludeList-dotnet-${OS_ARCH}.txt >> \
          ../temp/tmpExcludeList-dotnet-${OS_ARCH}.txt
 
  test -f ../exclude/ExcludeList-superseded.txt && \
      cat ../exclude/ExcludeList-superseded.txt >> \
          ../temp/tmpExcludeList-dotnet-${OS_ARCH}.txt

# substract tmpExcludeList-dotnet-${OS_ARCH}.txt from Urls-dotnet-${OS_ARCH}.txt
  rm -f ../temp/ValidUrls-dotnet-${OS_ARCH}.txt
  touch ../temp/ValidUrls-dotnet-${OS_ARCH}.txt
 
  test -f ../temp/Urls-dotnet-${OS_ARCH}.txt && \
    grep -F -i -v -f ../temp/tmpExcludeList-dotnet-${OS_ARCH}.txt \
    ../temp/Urls-dotnet-${OS_ARCH}.txt > \
    ../temp/ValidUrls-dotnet-${OS_ARCH}.txt

# create download directory and get downloads
  mkdir -p ../client/dotnet/${OS_ARCH}-glb
  doWget -i ../temp/StaticUrls-dotnet.txt -P ../client/dotnet
  doWget -i ../temp/ValidUrls-dotnet-${OS_ARCH}.txt -P ../client/dotnet/${OS_ARCH}-glb


Jetzt gibt es auf der Linux-Seite nur noch zwei zusätzliche Downloads:

  • dotnet/x86-glb/dotNetFx45LP_Full_x86_x64de.exe
  • dotnet/x86-glb/dotNetFx40LP_Full_x86_x64de.exe

Das sind anscheinend die deutschen Language Packs für die .Net Frameworks 4.0 und 4.5. Das ist auch ganz richtig so; auf der Windows-Seite bekommt man nur das Language Pack für das .Net Framework 3.5.

Auf der Windows-Seite bekommt man fünf zusätzliche Downloads: zwei im Ordner wxp/deu, zwei im Ordner dotnet/x86-glb und einen im Ordner win/glb

  • wxp/deu/windowsxp-kb980195-x86-deu_6b1e94aa5b99a1769ebd3d012047101d54150431.exe
  • wxp/deu/windowsxp-kb2626416-x86-deu_c4a0e511997ffa7513f0d65a92d606f02f130d04.exe
  • dotnet/x86-glb/ndp20sp2-kb2478658-x86_f5ee9a61889f15c0c44b79db01b92695137a8aff.exe
  • dotnet/x86-glb/ndp35sp1-kb2416473-x86_ba1edad5ea6edcde2ef26d810db2193a3ef86d0d.exe
  • win/glb/capicom-kb931906-v2102_5891b5de8ce331dc998656e20f1ce0b795e88786.exe

Die ersten vier Dateien sind alle in der Ausnahmendatei exclude/ExcludeList-superseded.txt aufgeführt - sie sind also überholt und sollten nicht mehr heruntergeladen werden.

Die CAPICOM-Datei wird nur auf einigen Servern verwendet. Man kann darüber etwas auf http://support.microsoft.com/kb/931906 lesen. Für Windows XP ist sie jedenfalls nicht wichtig.

Damit bin ich mit dem Ergebnis ganz zufrieden. Ich hätte die fertige Datei auch gerne hochgeladen, aber die Forumsoftware lässt auch gängige Dateierweiterungen wie txt oder zip nicht zu.

Viele Grüße,

Hartmut
hbuhrmester
 
Posts: 326
Joined: 11.10.2013, 21:59


Return to Linux

Who is online

Users browsing this forum: No registered users and 5 guests