Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
gute Arbeit und in so kurzer Zeit, mein Respekt, ich kann das nicht.
Frage: Wirst du die ISO´s neu hochladen ? Oder kann man auch selber etwas machen ?
Noch eine Frage zu den Versionen mit den Bootloader von Windows 10. Ich konnte keinen gültigen Windows 7 Key am Anfang des Setup für das InplaceUpgrade eingeben. Mit einen Windows 10 Key habe ich nicht probiert, da ich keinen habe.
bitte denk daran, es ist Wochenende und Adventszeit, Weihnachten steht vor der Tür, da gibt es bestimmt auch noch wichtigere Dinge zu erledigen. Ich habe früher ähnliches mit der Win-XP CD gemacht. Stunden über Stunden daran gesessen, ja sogar nächtelang bis es fertig war.
Nun habe ich auch Deine x86er ISO mit dem Win10-Bootloader in einer VM durchlaufen lassen und das auch im bekannten Thread dokumentiert.
Dabei schlug nach dem Installieren des November Rollups auch ein älteres Update zum Servicing Stack (KB3177467) auf.
Siehst Du eine Problematik wegen der Wiederherstellungsumgebung (WinRE)?
Ich kann das magels aktueller HW nicht testen.
Das Problem beim InPlaceUpgrade wird durch das KB3042058 (Default Cipher Suite Priority Order) verursacht.
Dieses benötigt nämlich als pre-requisite das KB3020369 (Servicing Stack Update von April 2015), welches erst nach dem KB2553552 ("SP1-Wrapper") installiert werden sollte.
Da man aber KB2553552 nicht slipstreamen kann, sondern nur nachträglich in der SetupComplete, kann man das KB3020369 und damit auch das KB3042058 nicht ins ISO einbauen.
Also muss man KB3042058 und KB3020369 aus dem ISO raus lassen, dann funktioniert auch das InPlaceUpgrade.
<Win10.RS1>\Recovery\WindowsRE\Winre.wim mit 309 MB von Juli 2016 vergleiche
mit der c:\Recovery\3c8a23ae-bd7b-11e6-82dd-c212e3b4d42d\Winre.wim mit 171 MB von November 2010,
so kann ich mir nicht vorstellen, dass man davon im Bedarfsfall irgendwelche Reparaturoptionen anstoßen kann.
Man liefe bei neueren Chipsätzen in ähnliche Probleme wie beim Installieren.
Ganz frech die 10er-WinRE an die Stelle der 7er nach c:\Recovery\... zu kopieren wäre natürlich ein Ansatz.
Ein vorheriges Umbenennen der 7er wäre natürlich zu empfehlen.
Du meinst also die Datei von
Win10.iso\sources\install.wim\2\Windows\System32\Recovery\winre.wim
nach
win7.iso\sources\install.wim\2\Windows\System32\Recovery\winre.wim
kopieren?
Kann man denn mit der Win10 Recovery-Environment eine Win7-Installation reparieren?
Oder meinst du die Datei
win7.iso\sources\install.wim\2\Windows\System32\Recovery\winre.wim
ebenfalls mit NVMe-Treibern etc aufrüsten?
Die Integration der Microsoft NVMe-Treiber hat bereits bei der boot.wim nicht funktioniert, also wird es höchstwahrscheinlich auch bei der WinRE.wim nicht funktionieren.
Braucht man sowas überhaupt?
Wenn Windows irgendwie rumzickt, dann holt man einfach den Backup zurück (Paragon, AOMEI, Macrium Reflect).
Da hätte ich auch noch ein etwas spezielles Problem, das bei mir zweimal aufgetreten ist.
Ausgangssituation: Skylake-System, UEFI-Boot, Bolkos 64bit-Windows mit Win10-Setup.
Die Installation läuft durch, nach dem ersten Neustart kommt die Anzeige "Registrierungseinstellungen werden aktualisiert" - entweder da blieb das System stehen, oder wo die vier farbigen Punkte zum Windows-Logo zusammenfliegen. Oder ich hatte einen schwarzen Bildschirm ohne Anzeige.
Abhilfe: Beim Dell XPS 13 hat es geholfen, im BIOS "Legacy" zu aktivieren - was auch immer dahintersteckt, denn man kann dann immer noch im UEFI-Mode starten. Dann alle Treiber installieren, danach darf Legacy wieder abgestellt werden.
Nun stand ich vor dem Problem, dass ein Laptop nur die Auswahl zwischen Legacy und UEFI ermöglicht, was nach der Installation im UEFI-Mode ein unstartbares System hinterließ. Im Legacy-Mode kein Problem, nach der Installation aller Treiber und Konvertierung der Festplatte zu GPT (mit AOMEI) war die Umstellung zu UEFI möglich. Es wird also ev. mit irgendeinem Treiber zusammenhängen, vermute ich.
Du meinst also die Datei von
Win10.iso\sources\install.wim\2\Windows\System32\Recovery\winre.wim
nach
win7.iso\sources\install.wim\2\Windows\System32\Recovery\winre.wim
kopieren?
Die jeweiligen Install.WIMs habe ich nicht aufgedröselt, um die WinRE.wim herauszupulen.
Ich ging von denen aus, die als fertiges Ergebnis an den angegebenen Orten liegen. Sie dürften aber identisch mit denen aus der Install.wim sein.
Um leichter zum Testen die WinRE am fertig installierten Rechner aufzurufen, könnte man den Bootmanager nach einem Vorschlag aus einer c't von 2011 aufbohren. Den habe ich unter dem Reiter WinRE-Eintrag dokumentiert.
Aber wie gesagt: Für einen richtigen Test fehlt mir die richtige aktuelle HW.
Gruß, Nemo
PS:
Beachte, dass sich Dein Beitrag zeitlich mit meinem vorigen überschnitten hat, als ich den um "SP2" ergänzte.
Es ging mir nicht darum, wie man das Convenience Rollup integriert, denn dazu habe ich bereits ausführlichst mehrere Beiträge verfasst.
Es ging mir lediglich darum, ob das InPlace-Upgrade mit einer solchen ISO funktioniert.
Das habe ich bisher noch nicht getestet, aber das wäre interessant, weil KB3042058 und KB3020369 dann auch mit drin sind, die aber bei "unserer" aktuellen ISO eben dieses InPlace-Upgrade-Problem verursacht haben.
Meinst du das Tool "WPI v8.7.3!"?
Wie lautet der Befehl?
Ergänzung ()
Opa Hermie schrieb:
Abhilfe: Beim Dell XPS 13 hat es geholfen, im BIOS "Legacy" zu aktivieren - was auch immer dahintersteckt, denn man kann dann immer noch im UEFI-Mode starten. Dann alle Treiber installieren, danach darf Legacy wieder abgestellt werden.
Dazu müsste man wissen, was genau die Einstellung "Legacy" bei diesem Laptop bewirkt, denn "Legacy" funktioniert nicht überall einheitlich:
The legacy mode settings differ from machine to machine. For example on this Lenovo if it can't boot from legacy mode it will switch to UEFI, although it is quite a slow process.
On other machines like my Dell it tries to boot into legacy mode and if it can't it just gives up.
Im Legacy-Mode kein Problem, nach der Installation aller Treiber und Konvertierung der Festplatte zu GPT (mit AOMEI) war die Umstellung zu UEFI möglich. Es wird also ev. mit irgendeinem Treiber zusammenhängen, vermute ich.
Eventuell ist dieses Laptop ein Fall für den "Intel Rapid Storage Treiber v14"?
Wenn ich den aber einbaue, dann funktioniert das ISO nicht mehr mit anderen Chipsätzen als den Intel 7-100.
Teste mal die normale ISO (ohne den Win10 Bootloader), aber dafür mit integriertem Intel RST v14.
War die Quelle DVD oder USB-Stick?
War das Ziel SATA oder M2- oder PCIe-NVMe?
Ist AHCI aktiv?
Gibt es im UEFI eine Option "Secure Boot"?
Welches Modell war das?
Eventuell ist dieses Laptop ein Fall für den "Intel Rapid Storage Treiber v14"?
Wenn ich den aber einbaue, dann funktioniert das ISO nicht mehr mit anderen Chipsätzen als den Intel 7-100.
Teste mal die normale ISO (ohne den Win10 Bootloader), aber dafür mit integriertem Intel RST v14.
Also:
Immer vom Stick, da es mittlerweile kaum noch kompakte Laptops mit Laufwerk gibt. Für Härtefälle hab' ich einen USB-DVD-Brenner. Den Stick als Verursacher kann man ausschließen, da Probleme meist viel eher auftreten (startet erst garnicht, Setp geht nicht oder Installation/Kopieren bricht ab) und man nichtmal zum ersten Neustart kommt.
Sowohl NVMe- als auch SATA-SSDs. Daran wirds wohl nicht liegen. AHCI kann man mittlerweile garnicht mehr abschalten, also in den IDE-CSM wechseln. Die NVMe-SSD lief auch nach der Installation ohne weiteres Zutun mit dem richtigen Treiber (stornvme oder wie der heißt).
Secure-Boot kann und muss man abstellen, außerdem habe ich die hinterlegten Securekeys gelöscht.
Das zweite Laptop ist ein Xiaomi Mi Air 12,5, etwas exotisch, da hier nicht erhältlich. Das XPS 13 habe ich nicht mehr, weils ständig kaputt war.
RST brauchte keines der Geräte, also weder nachinstallieren noch bei der Installation. Ev. Chipsatztreiber? Bei einem älteren HP mit 3. oder 4. Core-i-CPU lief die Installation mit demselben iso anstandslos, auch im UEFI-Modus.
Nachteil:
Diese ISO funktioniert dann evtl. nicht mehr mit anderen Chipsätzen außer denen, die der Intel Chipsatztreiber kennt.
Ich könnte mehrere Varianten des Chipsatztreibers mit aufs ISO packen und die passenden Installationszeilen vorbereiten, allerdings mit "REM" auskommentiert, so dass sie keinen Schaden anrichten.
Falls man dann den Treiber installiert haben möchte, entfernt man das REM vor der passenden Zeile.
Evtl. könnte man auch mit irgendeinem Tool während des SetupComplete-Scripts den aktuellen Chipsatz abfragen und dann automatisch die passende Chipset-Driver-Installation vornehmen.
Kennt jemand so ein Tool?
Leider gibt es von Intel kein Chipsatztreiberpaket, das für sämtliche Chipsets gültig ist.
Noch einmal zum Thema Wiederherstellungsumgebung (WinRE) von Win10 für Win7:
Einen Test in einer VM habe ich dokumentiert unter dem Reiter "Satz mit "x".
Die Bezeichnung sagt alles dazu: Als Tiger gesprungen - als Bettvorleger gelandet.
Abhilfen, warum das richtig eingegebene Paßwort nicht anerkannt wurde, werden natürlich gerade deswegen gerne entgegengenommen.
So, das habe ich gemacht und habe nun ein Multibootsystem, was leider kein startbares Windows 7 hat. Windows 10 geht ohne Probleme.
Im abgesicherten Modus bleibt es bei classpnp.sys hängen, ansonsten alles wie bereits beschrieben (Bild friert bei der Flagge ein).
Die Wiederherstellung von Windows 10 funktioniert genauso, wie von Nemo beschrieben, nämlich garnicht. Es kommt eine Nutzerkontenabfrage inkl. Passworteingabe, aber unter 7 gibts ja noch kein Konto, weil die Installation vorher tot war. Das Konto gehört zu Windows 10.
