Windows 10 und die ISO/FAT32/UEFI-Falle

Microsoft läuft mit Windows 10 in eine selbst verschuldete Falle, weil die ISO-Installationsmedien einfach zu fett werden und die Installationsabbilddateien die 4 GByte FAT32-Grenze sprengen? Das ist auf UEFI-Systemen mit Secure Boot ein Problem, um das man sich mit Kniffen herum lavieren muss. Hier ein Blick auf das Problem und mögliche Lösungen.


Anzeige

Ein Hinweis aus der Leserschaft

Vor einigen Tagen hatte ich im Blog-Beitrag Hyper-V 2nd Gen: Betriebssystem lässt sich nicht installieren über Installationsprobleme im Zusammenhang mit Hyper-V berichtet. Hatte zwar einen anderen Hintergrund, aber Blog-Leser Karl hat mich dann auf Twitter auf ein anderes Problem aufmerksam gemacht.

Microsoft hat damit begonnen, seine ISO-Installationsdateien für Windows 10 mit aktualisierten Servicing Stack Updates (SSUs) und kumulativen Updates (CUs) zu ergänzen. Das soll verhindern, dass es Installationsprobleme gibt, was eine gute Sache ist. Denn das reduziert auch die Notwendigkeit, das alles beim Setup oder Zurücksetzen von Windows 10 über dynamische Updates aus dem Internet herunterladen zu müssen.

Der Pferdefuß an dieser Geschichte: Die install.wim wächst sich dadurch aus und übersteigt die 4 GByte Dateigröße. Dies ist aber die Grenze für das FAT32-Dateisystem, und dieses Dateisystem wurde bei der UEFI-Definition für das Secure Boot-Design für die UEFI-Boot-Partition mit herangezogen. Karl deutet in obigem Tweet an, dass das zu Problemen führt. Werfen wir einfach mal einen Blick auf den Sachverhalt.

Ein paar Hintergrund-Informationen

Damit ein Installationsmedium mit Windows im UEFI-Modus von USB-Sticks booten kann, muss es im FAT32-Dateiformat formatiert worden sein (optische Medien natürlich ausgenommen). Wenn aber die install.wim die Grenze von 4 GByte von der Dateigröße übersteigt, lässt sie sich nicht mehr auf ein FAT32-formatiertes Medium wie einen USB-Stick schreiben. Da Microsoft die install.wim aber aufbläht, übersteigt diese irgendwann die 4 GByte-Grenze und man hat ein Problem.

Bei DVDs tritt die Problematik zwar nicht auf. Dort liegt aber die maximale Größe für Medien bei 4,7 GByte.

UEFI-Spezifikation und FAT32-Boot

Die Lösung wäre, das Installationsmedium mit NTFS zu formatieren und zur Installation zu verwenden. Natürlich könnten auch Linux-Dateisystemen zum Speichern der Installationsdateien verwendet werden – was aber bei Windows keine Option ist. Das Problem: Wenn der Installationsdatenträger nicht FAT32-formatiert ist, klappt das Booten von Windows-Installationsmedien meist nicht mehr.

Laut diesem Artikel gibt es in der UEFI-Spezifikation zwar keinen Grund, warum das Booten von NTFS-Medien nicht klappen sollte. Die Spezifikation besagt nur, dass FAT32-Boot unterstützt werden muss. Der FAT32-'Zwang' für die Boot-Partition wurde von Microsoft m.W. im Zusammenhang mit 'Secure Boot' eingeführt. Eine UEFI/GPT-Installation von Windows erfordert z.B. auch eine EFI-Boot-Partition im FAT32-Format auf der betreffenden Festplatte (siehe dieses Microsoft-Dokument).

Moderne Mainboards sollen, laut diesem Artikel, auch das Booten von NTFS-Datenträgern im UEFI-Modus unterstützen. Aber es gibt genügend Fälle, wo das nicht unterstützt wird (die Geräte, wie Microsofts Surfaces, zeigen dann die Boot-Medien nicht einmal an).


Anzeige

Einige Lösungsansätze skizziert

Bereits der oben verlinkte Artikel beschreibt, wie man USB-Installationsmedien für Windows 10 erstellen kann, die dieses Problem umgehen. Der Ansatz: Man erstellt Windows 10 USB-Installationsmedien, die von einer kleinen FAT32-Partition booten und dann eine größere NTFS-Partition verwenden, auf der die install.wim-Datei mit ihrer Übergröße liegt.

Axel Vahldiek hat das mal bei heise in diesem Artikel für Windows 8.1 aufbereitet. Dort finden sich die gleichen Tipps, wie man das Problem mit einem Medium, welches mehrere Partitionen unterstützt, lösen kann (eine UEFI-FAT32-Boot-Partition und eine erweiterte NTFS-Partition für die überlange WIM-Datei).

Das Ask Core-Team von Microsoft hat sich bereits 2013 in diesem englischsprachigen Beitrag des Problems angenommen. Die Lösung liegt entweder in der Aufteilung der WIM-Dateien auf Größen unter 4 GByte oder in der Verwendung eines USB-Mediums mit zwei Partitionen (FAT32 und NTFS), wie bereits im heise-Artikel skizziert.

Wer es lieber in Deutsch liest, MVP-Kollege Gregor Reimling behandelt hat sich dieses Problems ebenfalls für Windows Server 2016 angenommen und beschreibt in diesem Blog-Beitrag, wie man durch Teilen der install.wim um die 4 GByte-Grenze herum lavieren kann. Das erfordert aber manuelle Eingriffe, da Windows selbst bei den meisten USB-Sticks nur das Anlegen einer Partition unterstützt. Man muss mit diskpart auf der Ebene der Eingabeaufforderung hantieren.

Der Ansatz von RUFUS

Der Entwickler des Tools Rufus hat sich in diesem Forenthread zu Wort gemeldet. Rufus kann ein Feature UEFI:NTFS verwenden, um die FAT32-Limitierungen durch einen eigenen Boot-Lader zu umgehen. Der Entwickler nimmt in der RUFUS FAQ dazu ausführlich Stellung. Thomas Krenn hat im Wiki sogar die Einstellungen beschrieben, wie man vorgehen muss. Also alles paletti?

Der NTFS-Ansatz und das Problem mit Secure Boot

Verwendet man den Ansatz von Rufus, wird zwar ein Installations-USB-Medium geschrieben, was theoretisch auch booten kann. Falls beim UEFI-System aber der von Microsoft propagierte Secure Boot eingestellt ist, klappt das nicht. Denn Secure Boot erfordert, dass signierte Boot-Treiber verwendet werden. Der UEFI:NTFS-Treiber/Bootlader hat m.W. aber keine solche Signatur (zumindest gibt diese Rufus GitHub-Seite nichts dergleichen an).

Rufus und Secure Boot

Rufus weist mit einem Dialogfeld darauf hin, dass man Secure Boot für die Installation abschalten muss. Vergisst man das, wird beim Booten wahrscheinlich der Fehlercode 0xc000000d angezeigt. Dann muss man zur Installation Secure Boot abschalten.


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Windows 10 abgelegt und mit verschlagwortet. Setze ein Lesezeichen auf den Permalink.

23 Antworten zu Windows 10 und die ISO/FAT32/UEFI-Falle

  1. Karl Wester-Ebbinghaus (@tweet_alqamar) sagt:

    Danke für die Aufbereitung Günter!

    Derzeit reduziere ich die wim Größen mittels ntlite x64. Das geht auf SSDs recht schnell.

  2. Sherlock sagt:

    In den besagten Artikeln steht aber teilweise Unsinn.
    Erstens habe ich noch kein ESD-ISO von MS gesehen, in dem die install.wim größer als 4 GB war. Wenn man das ISO mit dem MS-Media Creation Tool erstellt, bekommt man einschließlich 1903 immer ein für FAT32 passendes ISO und mir ist auch nicht bekannt, dass MS dies zu ändern gedenkt.
    Weiterhin ist der Heise-Artikel veraltet. Windows unterstützt schon lange auf allen USB-Sticks mehrere Partitionen. Die im Heise-Artikel genannte Lösung ist auch recht umständlich. Ebenso ist die Vorgehensweise von Rufus völliger Quark. Auch das Splitten der WIM ist maximal umständlich.

    Die einfachste Lösung für eine install.wim, die größer als 4 GB ist, ist IMHO diese:
    Zwei Partitionen auf dem Stick
    1x 1 GB FAT32
    Das Setup *ohne* den Ordner Sources auf die FAT32-Partition kopieren.
    Danach manuell den Ordner sources erstellen und *nur* die boot.wim hinein
    kopieren. Partition aktiv setzen. Für UEFI-Installationen muss die Partition aber NICHT aktiv gesetzt werden!

    1 x NTFS Partition
    Das Setup komplett auf die NTFS-Partition kopieren.

    Es kann nun von der FAT32-Partition gebootet werden, das Setup bedient sich dann automatisch aus der NTFS-Partition – ganz ohne Eingabe von x bcdedit-Monstern im CLI.

    Aber wie gesagt: einfach die ESD-Version ziehen, damit entfällt aller Umstand.

    • Micha45 sagt:

      +1
      So schaut's aus. Die ESD-Version zu nutzen, ist für die meisten Nutzer die beste Lösung.
      Wer, aus welchen Gründen auch immer, eine install.wim benötigt, der kann diese auch durch Löschen der darin enthaltenen und nicht benötigten Editionen auf unter 4 GB drücken. Das macht man entweder mit einem Tool wie nlite, oder eben über das windowsinterne dism. Eigentlich benötigt man gar kein Tool von Drittanbietern.

  3. Anonymous sagt:

    WIM files kann man mit bordmitteln splitten

  4. Markus S. sagt:

    Das einfachste – ich bin beim USB-Stick schon sehr früh auf das Problem gestoßen – ist, einfach einen Export mit dism.exe zu machen, um eine ESD-File daraus zu machen.
    –> Dism.exe /Export-Image /SourceImageFile:$("$WIMFolder$WIMFile") /SourceIndex:$WIMIndex /DestinationImageFile:G:\sources\install.esd /Compress:Recovery

  5. Tom sagt:

    Ach, UEFI – ist halt alles viel besser und schaut vor allem viel besser aus mit all dem "bling-bling". Auch wenn das im ersten Moment wohl etwas populistisch klingen mag, sind das meine ersten Gedanken dazu!

    Vielen Dank für die Informationen :-)

  6. oli sagt:

    Wie vor mir schon jemand anmerkte, ist das nicht wirklich ein Problem:

    dism /split-image /imagefile:d:\wim\install.wim /SWMFile:d:\iso\sources\install.swm /filesize:2000

    Unser Custom-Image ist 8GB groß. UEFI-Installation funktioniert problemlos mit der gesplitteten install.wim.

  7. Walter sagt:

    Man kann auch WinSetupfromUSB von hier http://www.winsetupfromusb.com/downloads/ herunterladen, damit gibt es keine Probleme.

  8. Robert sagt:

    Ein Rätsel bleibt, warum MS nicht initial die ISOs mit WIM mit 4GB statt ESD mit dann rund 3 GB anbietet, was neben dieser Problematik auch pro Download 1 GB weniger über die Leitung und andere Ressourcen jagt.

    Mit dem aktuellen ADK/DISM erzeugte mein cmd-batch gestern aus der Win10_1903_V1_German.iso mit 4,85 GB in einem Rutsch eine ISO mit rund 3,6 GB. Dabei werden die Versionen Home und Pro extrahiert, SSU, Update, Flash und .Net integriert, alle Apps bis auf Store entfernt und dieses zu einer Install.ESD komprimiert.
    Bei Interesse kann ich das gerne bereitstellen und erläutern.

  9. Ganz einfache Lösung: Vom FAT32 USB-Stick ohne install.wim booten, dann auf einen NTFS USB-Stick wechseln, der die kompletten Windows 10 Installationssourcen enthält …

  10. Michael K. sagt:

    Was ist aus dem Gastbeitrag geworden?

  11. tomtom sagt:

    Hallo,

    ich habe mich vor einiger Zeit auch immer wieder mit denBootsticks rumgeärgert. mal wird er erkannt und mal wieder nicht. Den Ansatz von Rufus habe ich auch eine Zeit so durchgeführt aber oft konnte ich selbst mit abgeschalteten SecureBoot nicht booten. DieSticks wurden meistens nicht erkannt. Seit dem ich mit diskpart ein FAT32 Stick erstelle und mit DISM die install.wim in eine install.esd konvertiere habe ich keine Problem mehr.

    Allerdings würde mich der Ansatz von Robert interessieren. Ich habe selbst mal versucht ein Image mit an die install.esd ranzuhängen allerdings wurde die Datei dann 12GB groß.

    Ich nutze mal die Chance und stupse dich Günter nochmal an.

    • Michael K. sagt:

      Hallo tomtom,

      habe das so gelöst:
      Erstelle mir einen UEFI-Boot-Stick mit Rufus von einem Windows 10 Medium, bei dem ich die install.wim aus dem sources-Verzeichnis entfernt habe (geht dann schneller mit dem Stick schreiben;) ).
      Ein angepasstes install.wim-File teile ich – wie folgt – auf:
      splitten:

      Dism /Split-Image /ImageFile:.\install2split.wim /SWMFile:.\install.swm /FileSize:3000

      Die install.swm, install2.swm, install3.swm (je nach Ausgangsgröße der wim-Datei werden entsprechend viele swm-Dateien mit 3 GB erzeugt – Fat32-konform) dann einfach in den sources-Ordner auf dem Stick kopieren. Das Setup ist tatsächlich schlau genug diese "zusammenzusetzen"…

  12. Stanarsch sagt:

    Bei Clean-Install WIN_10_20H2 sollte die Zuordnungseinheit bei Rufus auf 8192Byte eingestellt werden. Auf meinem PC hat es, ohne splitting der Dateien, funktioniert. Secure-Boot muss offline sein!

  13. Anonymous sagt:

    Ich benutze das Tool – Ventoy https://www.ventoy.net
    Ich finde es besser als RUFUS da der Datenträger mit einer EFI Partition formatiert wird und auf der 2.Partition kann man beliebig viele ISO-Dateien ablegen.
    Diese werden dann beim booten von Ventoy automatisch im Bootmenu aufgelistet. Klappt zwar nicht mit allen ISO's aber Windows10 läuft.

    P.S.: Vielen Dank auch an Herrn Born für die zahlreichen Blogeinträge, für jeden Techniker der sich mit Windows rumschlagen muss ein Segen und mit keinem Geld der Welt aufzuwiegen. Microsoft könnte sich von solchen Blogeinträgen eine große Scheibe abschneiden. :)

Schreibe einen Kommentar zu Thomas Langhans Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.