Windows ISO < USB-Stick

[Nickel]

Bin wohl auf diese Fehlinformation reingefallen:

Die Versionsnummer spielt nicht wirklich eine Rolle dabei,
was das MCT letztendlich für ESD-Dateien runterlädt.
Zumal die "10.0.22621.x (22H2)" immer noch die Basis der 23H2 ist.

 

[tollertyp]

Die Nummer passt bei aktuellen MCTs schon ganz gut meistens, zumindest die Hauptnummer. Mir ist schon klar, dass die Versionsnummer nicht angibt, was runtergeladen wird. Aber ich bin mir sicher, dass für 23H2 dann die Version nicht mehr 22621 sein wird.

Ich sagte ja, ich bin da drauf reingefallen.

 

[Apopex]

Zum Thema MCT 23h2: https://winfuture.de/news,139370.html

Setzt ventoy doch irgend etwas ins uefi (secure boot) rein?
Habe ich gerade beim stöbern bei denen auf der seite gefunden
https://www.ventoy.net/en/doc_delete_key.html

 

[Nickel]

Die Nummer passt bei aktuellen MCTs schon ganz gut meistens, zmindest die Hauptnummer.

Das aktuelle MCT für Windows 10 hat auch keine Build Nummer der 22H2 (19045.x)
sondern der 2004 (20H1) 19041.x welches die letze Basis ist bei Windows 10.
Die Hautptversionnummer wird sich wohl auch beim MCT für die 23H2 nicht ändern
weil die Basis immer noch die 22H2 ist.

 

[tollertyp]

Warten wir es mal ab :-)

 

[Nickel]

Setzt ventoy doch irgend etwas ins uefi (secure boot) rein?

Ventoy und Rufus müssen das Installationsmedium in NTFS erstellen
wegen der weit über 4GB großen install.wim.
UEFI-Boot geht aber nicht von NTFS und braucht FAT/FAT32,
und die Tools erstellen zusätzlich eine kleine FAT Partition für den UEFI-Boot.
Hier wird aber auch ein NTFS Treiber benötigt der keine Signatur hat
und diesen muss man irgendwie am SecureBoot vorbeibekommen.

Ergänzung (4. November 2023)

Nimmt man eine ESD-ISO die das MCT erstellt, braucht man das alles nicht.
Diese hat eine install.esd und passt auf FAT32 und man hat UEFI-Boot.
Rufus erkennt automatisch um welche ISO es sich handelt diesbezüglich.

 

[s1ave77]

UEFI-Boot unterstützt FAT32 und NTFS nach Spezifikation. Problem sind geizige Mainboardhersteller, die sich oft die NTFS-Unterstützung sparen.

Mein MSI X470 bootet anstandslos UEFI vom NTFS-Stick. Kann man sagen was man will, hat MSI mal richtig gemacht.

 

[Nickel]

NTFS nach Spezifikation

Wenn man ein Mainboard (UEFI) mit diesem NTFS Driver Feature hat,
sollte auch ein UEFI-Boot möglich sein von NTFS.
Diese Mainboards kann man aber wohl an einer Hand abzählen
und Ventoy und Rufus erstellen wiederum das Installationsmedium nicht dementsprechend dann.

 

[s1ave77]

Diese hat eine install.esd und passt auf FAT32 und man hat UEFI-Boot.

Scheint bei 23H2 ein Problem zu werden. Wenn die WIM, wie bei meinem UUPDump-ISO >6 GB groß ist, kann auch ESD nichts retten, soweit läßt sich das nicht komprimieren . WIM>ESD sind in der Regel 25% Reduktion.

Diese Mainboards kann man aber wohl an einer Hand abzählen

Leider . Deshalb hängt alles bei FAT32.

 

[Nickel]

6 GB groß ist, kann auch ESD nichts retten, soweit läßt sich das nicht komprimieren

Die ist ja so fett weil vieles reinintegriert wurde.
Müssten sie erst mal entschlacken bzw einfach ganz neu erstellen
Was MS ja nun tut und sich das MCT bis mitte November verschiebt laut Microsoft.

 

[tollertyp]

Oh Mann, gerade die ISO von MS gezogen, und selbst a ist noch die Sprache von 22621 in der WIM-File:

Ich würde mir von MS doch gerne etwas mehr Konsequenz bei den Versionsnummern wünschen.

 

[Nickel]

Die Basis ist halt die 22H2 (22621).
In der 23H2 werden sich nicht wenige System Dateien finden mit Version 22621.xxx.
Ist auch so bei Windows 10 seit Jahren, dass dort noch Hinweise auf "19041.x" auftauchen.

Ergänzung (4. November 2023)

Man schaue mal im Gerätemanager bei Standard Geräten
wo man keinen Treiber für braucht zu installieren, dort auf Treiber Details gehen.

Beispiel Windows 10 22H2 (19045.xxx)
Systemdatei - Windows 10 2004 (19041.x)

 

[s1ave77]

mehr Konsequenz bei den Versionsnummern wünschen.

Wird nicht passieren, kann nicht, um genau zu sein. Ein Build in der Abfolge erfüllt die Kriterien für 'Production' und wird Kandidat, tauchen keine Gamebreaker auf, wird er rausgeschickt.

Außer wenn wie schon bei Win 10 die Nummer gelockt werden auf bestimmte Schritte, ala 19041...19045.

Das 23H2-ISO vom Dump zeigt 22631 als Buildnummer, hmm 10er Schritte bei Win 11:

 

[tollertyp]

Ich installiere gerade mal von der ISO in einer VM.

 

[Nickel]

Oh Mann, gerade die ISO von MS gezogen, und selbst a ist noch die Sprache von 22621 in der WIM-File:

Beim Inplace Upgrade wird auch nichts neues featuremäßig Installiert,
da ist das "Enablement Package" integriert was freischaltet während dem Inplace Upgrade.
Bei Windows 10 war das schon so der Fall.
Schau doch mal jemand nach, der ein Inplace Upgrade mit der ISO der 23H2 gemacht hat,
im Window Update Verlauf ob da nicht das "Enablement Package" genannt wird.

Also, jetzt mal nur im Bezug auf die fette ISO der 23H2, was ja keine wirklich neue ISO ist.

 

[s1ave77]

Also, jetzt mal nur im Bezug auf die fette ISO der 23H2, was ja keine wirklich neue ISO ist.

Ist wie auch bei Win 10 ein neuer Build, auch wenn die Schritte klein sind. 23H2 sollte 22631 melden.

Das 23H2 hängt anscheinend noch im Release-Preview-Channel fest.

 

[Nickel]

Ist wie auch bei Win 10 ein neuer Build,

Das ist keine neue ISO, da ist alle möglich reinintegriert darum über 6GB.
Die ISO der 22H2 war eine neue, da ein neues Windows 11 @4GB

Bei Windows 10 das gleiche seit der 2004 (20H1), die hatte noch 4GB,
wie auch die 1903 und alles davor. 1909 war ja kein großes Update,
damit fing das dann an.
Hier gab es aber auch mal ISOs als V2 (Version 2) später als Download.
Eher nicht ganz neu aber wohl abgespeckt.

 

[s1ave77]

da ist alle möglich reinintegriert darum über 6GB.

Keine Ahnung, was das heißen soll, aber MS bastelt keine 'reintegrierten' ISOs. Das ist der Dateizustand wie nach dem Enablement-Package nur als Reset-Based-State (nicht deinstallierbar). Wie bei allen Releases auch.

Da gibt es nicht viel zu optimieren (das machen die eh schon sehr gut). Problem sind die vielen Editionen beim Standard-ISO. Das sind knapp ein Dutzend Indizes, das braucht Platz und fällt ihnen grad auf die Füße.

EDIT: Server-ISOs sind schon länger jenseits der 7 GB.

 

[Nickel]

Keine Ahnung, was das heißen soll, aber MS bastelt keine 'reintegrierten' ISOs.

Doch, genau das. Darum sind diese so fett.
Habe oben noch ergänzt und lass es dabei,
keine Lust auf Wettstreits.

 

[Apopex]

Ventoy und Rufus müssen das Installationsmedium in NTFS erstellen
wegen der weit über 4GB großen install.wim.
UEFI-Boot geht aber nicht von NTFS und braucht FAT/FAT32,
und die Tools erstellen zusätzlich eine kleine FAT Partition für den UEFI-Boot.
Hier wird aber auch ein NTFS Treiber benötigt der keine Signatur hat
und diesen muss man irgendwie am SecureBoot vorbeibekommen.

Ergänzung (4. November 2023)

Nimmt man eine ESD-ISO die das MCT erstellt, braucht man das alles nicht.
Diese hat eine install.esd und passt auf FAT32 und man hat UEFI-Boot.
Rufus erkennt automatisch um welche ISO es sich handelt diesbezüglich.

Das verstehe ich schon, aber warum muss z.b. ventoy oder vlt auch rufus dann etwas ins uefi bzw secure boot schreiben.
Ich mag das nicht wenn eine software etwas am system ändert.
Das auf dem stick eine eigene start partition sein muss leuchtet mir auch ein.

Aber warum macht es sich MS so kompliziert und muss es so verkleinern das es auf einer Fat32 Partition funktionert. Die könnten beim erstellen des Sticks es doch genau so machen mit einer kleinen start partition das dass ntfs dateisystem gelesen werden kann.
Sowas was die treiben ist doch sowas von total veraltet.. heute nich mit Fat32 herum zu machen...