[geklärt]Fragen zu Grub2, MBR und Dual-Boot

[BeastXXL]

Hallo Community,

sorry, wenn ich wieder ein Thread eröffne, obwohl es noch kein wirkliches Problem gibt. ps:
Da ich aber auf ein funktionierendes System (Linux) angewiesen bin, kann und will ich mir keine Fehler leisten. Daher frage ich lieber vorher...

Grund meiner Frage ist der blöde Patch von Windows (KB3033929). Der soll ja richtig Probleme machen, wenn ein MS-fremder Bootloader (wie z.B. GRUB2) installiert ist.
Nach dem Artikel auf Golem wird dringend geraten, vor der Installation des Patches den ursprünglichen MS-Bootloader zu instalieren. Danach dann wieder GRUB2 installieren.

Nun die Gretchen-Frage: wie installiere ich GRUB2 am sichersten und unkompliziertesten? Im Idealfall so, dass es wie vorher aussieht?

Ich habe eine Vorgehensweise im Internet gefunden. Da stellt sich mir schon die erste Frage, welche Konsolenumgebung die beste ist oder ob das überhaupt keinen Unterschied macht: 1. die Konsole einer Live-CD, 2. die Konsole von der Installations-DVD (DVD Rescue) oder 3. das installierte Linux durch z.B. "System-Rescue-CD" laden (lassen) und dort die Konsole verwenden. Ich tendiere zu Pkt. 2.

Die Vorgehensweise habe ich hier gefunden: https://forums.opensuse.org/content.php/128-Re-install-Grub2-from-DVD-Rescue
Die root-Partition muss natürlich angepasst werden, aber sonst würde ich das 1:1 so übernehmen...
Hab ihr irgendwelche Einwände gegen diese Anleitung?

Das Programm, das Golem erwähnt, kenn ich nicht. Außerdem habe ich hier sicher irgendwo auch SuperGrub2Disk auf irgend einer SystemRescue- oder UltimateBoot-CD. Allerdings habe ich das Prog noch nie ausprobiert und befürchte, dass das Menü dann nicht mehr so aussieht, wie jetzt. Hat jemand mal SuperGrub2Disk ausprobiert? Wie war das Ergebnis?

Achso, und wenn ich das Ganze richtig verstanden habe, würde das ganze eigentlich nur den MBR betreffen (habe kein UEFI). Einen zusätzlichen Bootmenü-Eintrag (als Datei in /etc/grub.d abgelegt) dürfte das garnicht kümmern, richtig?

Danke schonmal für eure Meinung dazu.

 

[josef-wien]

Mit 3. kannst Du das installierte System über die Super Grub2 Disk (die auch auf der System Rescue CD enthalten ist) starten und dann mit YaST den bootloader wieder einrichten.

1. und 2. bringen wesentlich mehr Arbeitsaufwand (und somit auch Fehlermöglichkeiten) und sollten nur dann herangezogen werden, wenn 3. bei Dir nicht funktioniert.

P. S. Wäre der bootloader nicht im MBR, sondern in der Systempartition installiert, müßtest Du nur vor Deiner Windows-Aktion das boot flag auf die Windows-Partition und danach wieder zurück (auf die Linux-Systempartition bzw. die erweiterte Partition) ändern.

 

[Anonymous]

Grund meiner Frage ist der blöde Patch von Windows (KB3033929). Der soll ja richtig Probleme machen, wenn ein MS-fremder Bootloader (wie z.B. GRUB2) installiert ist.

Wir konnten gesichert feststellen, dass Systeme, bei denen der Windows-Bootloader als primärer Loader aktiviert ist, dieses Update erfolgreich installieren können, und dass Systeme, auf denen ein anderer Bootloader als primärer Bootloader angegeben ist, das Update selbst dann nicht installieren können, wenn der Benutzer mit diesem Loader Windows auswählt.

Wie sieht Deine Partitionierung/Bootkonfiguration aus?

 

[BeastXXL]

Hallo ihr zwei,

zunächst folgende Ausgabe:

localhost:/home/beastxxl # fdisk -l

Festplatte /dev/sda: 465,8 GiB, 500107862016 Bytes, 976773168 Sektoren
Einheiten: Sektoren von 1 * 512 = 512 Bytes
Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes
E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes
Festplattenbezeichnungstyp: dos
Festplattenbezeichner: 0x766ad33c

Device     Boot     Start       End   Sectors  Size Id Type
/dev/sda1  *           63 105643439 105643377 50,4G  7 HPFS/NTFS/exFAT
/dev/sda2       105643440 330133503 224490064  107G  f W95 Ext'd (LBA)
/dev/sda5       105643503 251128079 145484577 69,4G  7 HPFS/NTFS/exFAT
/dev/sda6       251128143 255337109   4208967    2G 82 Linux swap / Solaris
/dev/sda7       255337173 297363455  42026283   20G 83 Linux
/dev/sda8       297365504 330133503  32768000 15,6G 83 Linux

Ich hoffe, es reicht. Wenn nicht, dann bitte nachfragen.

@josef: ja, Pkt. 3 ist mir jetzt auch am liebsten. Zumal es dort wohl auch auf Konsole reichen soll

grub2-install /dev/sda

auszuführen. Hab ich erst später herausgefunden. An die Möglichkeit über YAST den Bootloader neu zu installieren hatte ich noch garnicht gedacht...

Das mit der Systempartition hatte ich früher mal mit oS 11.2 oder 11.3 ausprobiert indem ich den Installationsvorschlag bzgl. des Bootloaders übernahm. Hat bis zum nächsten kalten Start (d.h. Rechner für ein paar Stunden aus) gehalten. Ich weis nicht, was damals schief gelaufen war, jedenfalls startete immer Win automatisch. Seit dem installiere ich GRUB immer in den MBR und habe seit dem nie wieder ein Problem damit gehabt.

 

[Anonymous]

Nach dem Artikel auf Golem wird dringend geraten, vor der Installation des Patches den ursprünglichen MS-Bootloader zu instalieren. Danach dann wieder GRUB2 installieren.

So ist es –für Dich– richtig. Du bist von diesem Problem betroffen, da dein (GRUB)Bootloader im MBR der Festplatte installiert ist.
Hast Du noch eine Kopie vom M$-Bootloadercode? Dann könntest Du die einfach zurückschreiben und dann den M$-Patch installieren:

$ dd if=/home/ich/Sicherungskopie-MBR-win6.1 of=/dev/sda bs=1 count=440

→ Wenn Du keine MBR-Kopie mehr besitzt, kannst Du mit der Windoof-Installations-CD oder mit einem „Werkzeug aus dem Internet“ den original Windoof-Bootloader bzw. einen nachgeahmten M$-Bootloader-Code wiederherstellen lassen.

Dann startest Du Dein installiertes Linux per SuperGrubDisk2 von der SystemRescueCD zum Beispiel und installierst den Grub2-Bootcode z.B. per YaST erneut auf der Platte.

Das mit der Systempartition hatte ich früher mal mit oS 11.2 oder 11.3 ausprobiert indem ich den Installationsvorschlag bzgl. des Bootloaders übernahm. Hat bis zum nächsten kalten Start (d.h. Rechner für ein paar Stunden aus) gehalten. Ich weis nicht, was damals schief gelaufen war, jedenfalls startete immer Win automatisch. Seit dem installiere ich GRUB immer in den MBR und habe seit dem nie wieder ein Problem damit gehabt.

Ich weiß, was da schiefgelaufen war: Das Bootflag in der msdos-Partitionstabelle war auf die 1. Partition gesetzt.
Der Grub-Bootloadercode lag aber bei Dir in der 2. Partition.
Das hättest Du nur per fdisk nachzusehen brauchen und das Bootflag umändern.

Und in diesem Falle wäre der Windoof-Patch KB3033929 bei Dir anstandslos über die Bühne gelaufen, ohne dass das Bootflag hätte auf sda1 zurückgestellt werden müssen. Windoof-Update will nur den Windoof-Bootcode im MBR. — Grub oder LILO mag er nicht.

 

[BeastXXL]

→ Wenn Du keine MBR-Kopie mehr besitzt, kannst Du mit der Windoof-Installations-CD oder mit einem „Werkzeug aus dem Internet“ den original Windoof-Bootloader bzw. einen nachgeahmten M$-Bootloader-Code wiederherstellen lassen.

Dann startest Du Dein installiertes Linux per SuperGrubDisk2 von der SystemRescueCD zum Beispiel und installierst den Grub2-Bootcode z.B. per YaST erneut auf der Platte.

Nein, eine Sicherungskopie habe ich nicht, da ich quasi gleich nach der Installation von Win Linux hinterher installiert habe. Aber so, wie du es oben beschreibst, habe ich es vor zu machen.

Ich weiß, was da schiefgelaufen war: Das Bootflag in der msdos-Partitionstabelle war auf die 1. Partition gesetzt.
Der Grub-Bootloadercode lag aber bei Dir in der 2. Partition.
Das hättest Du nur per fdisk nachzusehen brauchen und das Bootflag umändern.

Mal abgesehen davon, dass ich einige Stellen im Web gefunden habe, die davon abraten GRUB2 nicht im MBR zu installieren, kenn ich mich nicht wirklich mit der Variante mittels Bootflag aus.
Wie funktioniert das denn so im groben?
Ich rate mal ins Blaue: der MS-Bootloader hockt im MBR und GRUB2 auf meiner root-Partition. Bootflag wird auf die root-Partition gesetzt. Irgendwie wird so bei einem Neustart GRUB2 geladen (inkl. Win-Eintrag im Menü). Sollte wieder eine solche Situationwie jetzt entstehen, ändere ich irgendwie die Position vom Bootflag und beim nächsten Start läder der MS-Bootloader.
Ist alles vorbei ändere ich wieder irgendwie den Bootflag zurück auf die root-Partition und alles ist wie vorher. Richtig?

Egal für welche Variante ich mich entscheide: ich werde vorher eine Sicherungskopie von grub.cfg machen.

 

[josef-wien]

http://forum.linux-club.de/viewtopic.php?f=89&t=118877&p=754189&#p754189
http://www.gnu.org/software/grub/manual/grub.html#BIOS-installation

 

[Anonymous]

Mal abgesehen davon, dass ich einige Stellen im Web gefunden habe, die davon abraten GRUB2 nicht im MBR zu installieren, kenn ich mich nicht wirklich mit der Variante mittels Bootflag aus.
Wie funktioniert das denn so im groben?
Ich rate mal ins Blaue: der MS-Bootloader hockt im MBR und GRUB2 auf meiner root-Partition. Bootflag wird auf die root-Partition gesetzt. Irgendwie wird so bei einem Neustart GRUB2 geladen (inkl. Win-Eintrag im Menü).

Das Bootflag sitzt in der Disc Operating System-Partitionstabelle. Darin gibt es genau vier Einträge für vier (Primär-)Partitionen: Eine davon erhält das Bootflag. In den MBR wird während der Installation eines Betriebssystems Maschinencode hinein geschrieben, der sog. Master Boot Code. Der sucht die dos-Partitionstabelle und startet dann aus der „aktiven“ Partition: z.B. entweder Win-doof direkt (1.Partition) oder GRUB (2./3. oder 4.Partition).

Sollte wieder eine solche Situationwie jetzt entstehen, ändere ich irgendwie die Position vom Bootflag und beim nächsten Start läder der MS-Bootloader.
Ist alles vorbei ändere ich wieder irgendwie den Bootflag zurück auf die root-Partition und alles ist wie vorher. Richtig?

Richtig, aber unnötig, weil der M$-MasterBootCode bei dieser Variante unangetastet bleibt. (Das hatte ich Dir aber schon genau gesagt.)

Egal für welche Variante ich mich entscheide: ich werde vorher eine Sicherungskopie von grub.cfg machen.

Nein: vom (kompletten) Master Boot Record.
$ dd if=/dev/sda of=/home/ich/Sicherungskopie-MBR-win6.1-HDDbzwSSD bs=512 count=1

GRUB-im-MBR-Problem: Der Windoof-Update-Patch KB3033929 benötigt den ganz speziellen Maschinencode von Micro$oft und verschluckt sich am GRUBschen Master Boot Code im Master Boot Record.

Mein Vorschlag:
Installiere GRUB2 trotzdem so, wie openSUSE13.2 es gerne hätte: → neue Boot-Konfiguration vorschlagen lassen und übernehmen.
Falls Micro$oft wieder einmal alle Nicht-Windoof-Only-User ärgern will, spielst Du einfach die Kopie des MBR (440 Bytes genügen dabei) zurück.

Als Erstes musst Du jetzt allerdings den WINDOOFschen Master Boot Code wiederherstellen. Nun kommt der M$-Patch KB3033929 an die Reihe. Dann machst Du die Kopie vom MBR (→ z.B. per SystemRescueCD).
Anschließend startest Du Dein installiertes Linux per SuperGrubDisk2 (von der SystemRescueCD zum Beispiel: → SGD) und installierst den Grub2-Bootcode z.B. per YaST erneut auf der Platte.

Und ändere mal Deine Überschrift ab. Blöde Fragen gibt es nicht — höchstens blöde Antworten.
(z.B.: Frage zu Grub2 und MBR bei Parallelinstallation)

 

[Freddie62]

Hier gab es viele Probleme mit dem o.g. Patch. Glücklicherweise hatte ich alle Laptops so eingestellt, daß Grub2 in den MBR installiert wurde. => gparted installiert. => Bootflag auf sda2 (WIN-Recovery) gesetzt. => Neustart (Nur noch WIN). Alle Updates installiert (mehrfach neu gebootet). => Mittels Supergrubdisk Opensuse gestarted. Über gparted das Bootflag wieder auf / gesetzt. Fertig.

CU Freddie

 

[BeastXXL]

Hallo zusammen,

ich gebe zu, mir raucht langsam der Kopf.

Ich versuche mal das Gelesene so widerzugeben, wie ich es verstanden habe. Bitte korrigieren, falls nötig.

Um bei diesem und zukünfigen Win-Patches keine Probleme zu bekommen, darf kein GRUB2-Bootloader im MBR stehen, sondern ein Master Boot Code.
Diesen bekomme ich entweder von der Win-Installations-DVD mittels

bootrec /fixmbr

bzw.

fixmbr

oder über Yast --> Bootloader durch "Generischen Bootcode in MBR schreiben". (Ich favorisieren die Win-DVD-Version.)
Win-Patches einspielen.
Mit einer Linux-Live-CD sichere ich den MBR.

Mit SuperGrubDisk2 boote ich mein installiertes openSUSE. Dann zu YAST --> Bootloader
GRUB2 lasse ich "Aus Root-Partition starten" (Haken setzen). Den Haken bei "aus Master-Boot-Record starten" entferne ich, damit GRUB2 nicht wieder in den MBR installiert wird.
Durch das "setzen der Aktiv-Flag für Bootpartiton" wird vermutlich die Bootflag bei /dev/sda7 gesetzt, da das meine root-Partition ist und GRUB2 aus eben dieser starten soll.
(So, wie ich hier das gerade aufschreibe, klingt die Sache mit "aus Root-Partition starten" und "Aktiv-Flag für Bootpartition setzen" irgendwie doppelt-gemoppelt.)

Ein ändern des Bootflags ist dann nicht mehr nötig, da für Win der MBR normal ist. Sollte es ein Problem damit geben, dass GRUB2 nicht geladen wird, könnte es daran liegen, dass die Bootflag nicht bei der root-Partition steht. Ansonsten könnte ich die Sicherungskopie in den MBR schreiben (Linux-Live-CD).

Wenn das alles korrekt ist, dann bleiben nur noch diese Fragen:

Installiere GRUB2 trotzdem so, wie openSUSE13.2 es gerne hätte: → neue Boot-Konfiguration vorschlagen lassen und übernehmen.

Ich habe gerade nachgesehen, bei mir gibt es dort keine Möglichkeit, sich eine neue Boot-Konfiguration vorschlagen zu lassen. Wie soll ich die bekommen?

Wie bekomme ich YAST dazu, den Bootloader zu installieren? Ich habe gelesen, dass man den Trick anwenden muss, erst "GRUB" einzustellen und dann wieder zurück auf "GRUB2" --> http://www.opensuse-forum.de/allgemeines/opensuse-installation/10553-grub-wiederherstellen/
Ist das wirklich so oder gibt es irgendeine Rückmeldung?

Das sichern des MBR müsste doch eigentlich auch am Ende der ganzen Prozedur noch gehen, oder?

Was meint Freddie62? Ich denke, das geht nicht, wenn GRUB2 im MBR ist. Bin etwas verwirrt...

Danke für euer Feedback und ggf. Korrekturen.

 

[josef-wien]

Einen generischen MBR brauchst Du nicht zu sichern, den kannst Du auf die von Dir beschriebenen Arten jederzeit erzeugen. (Wenn GRUB2 im MBR enthalten ist, reicht das Sichern des MBR nicht, Du mußt auch die folgenden Sektoren, die den Code von GRUB2 enthalten, sichern und gegebenenfalls wiederherstellen. Wenn zwischen Sichern und Wiederherstellen die Partitionierung geändert wurde, dürfen vom MBR nur die ersten 440 Stellen wiederhergestellt werden. Ich halte nichts von dieser Art "Sicherung".)

Der Boot-Code des generischen MBR kennt keine logischen Partitionen. GRUB2 muß bei Dir in die erweiterte Partition, und die erweiterte Partition muß das boot flag erhalten.

Die Fragen zu YaST müssen andere beantworten. (GRUB Legacy wird von der Bootloader-Einrichtung von 13.2 nicht mehr unterstützt.)

 

[BeastXXL]

Hallo josef,

deiner Antwort entnehme ich, das meine beschriebene Vorgehensweise grundsätzlich richtig ist. Richtig?
Ob der MBR nun gesichert wird oder nicht, ist nicht soooo wichtig, denke ich.

Dein Hinweis zu GRUB2 und der erweiterten Partition hinterlässt bei mir ein Fragezeichen. Und zwar, weil ich gerade noch einmal das YAST-Tool (Bootloader) angesehen habe. Dort habe ich drei Möglichkeiten, wo ich GRUB2 starten lassen kann. "Aus dem Master-Boot-Record", "Aus der Root-Partition" und "Aus der erweiterten Partition".
Ich kann mir denken, dass nur der letzte Punkt ("erweiterten Partition") evtl. noch eine genauere Ortsangabe haben will. Die anderen beiden Punkte sollten ihre Ziele selbst finden können.

Bsp.:
Wenn ich das also richtig verstehe, dann sollte sich GRUB2 in /dev/sda7 installieren, wenn ich "aus Root-Partition starten" wähle.
Wenn ich GRUB2 von meiner home-Partition starten lassen wollte, müsste ich "aus erweiterten Partition starten" wählen und irgendwo /dev/sda8 angeben, so dass sich GRUB2 genau dort installiert.

Allerdings gibt es dort anscheinend keine Möglichkeit, den Ort auf der "erweitertenPartition" näher zu bestimmen. Zumindest sehe ich keine. Gut, ist jetzt nicht so schlimm, da GRUB2 bei mir sowieso aus der Root-Partition starten soll.
Was mich bei der ganzen Sache aber am meisten verwirrt: ich kann alle drei Möglichkeiten auswählen! Der "Speicherort des Bootloaders" kann sowohl im MBR als auch in der Root- und einer erweiterten Partition sein. Gleichzeitig! Ist das irgendwann sinnvoll?

Gib es sonst noch jemand, der mir einen Hinweis geben möchte?
Bin allen, die mir bisher geantwortet haben und allen anderen mit weiteren Hinweisen sehr dankbar.

PS: ich finde einfach keine Anleitung, wie man über Konsole GRUB2 woanders als im MBR installiert. Alle Anleitungen zeigen die Installation in den MBR.

 

[josef-wien]

"Aus der erweiterten Partition"

Es gibt nur (maximal) eine erweiterte Partition, und in genau deren Boot-Sektor muß der bootloader hinein (selbst YaST ist in der Lage, bei Dir /dev/sda2 als erweiterte Partition zu erkennen).

Einen bootloader in eine logische Partition (wie z. B. Deine Systempartition /dev/sda7) zu installieren, macht nur dann Sinn, wenn Du ihn von einem anderen bootloader aus aufrufst, denn:

Der Boot-Code des generischen MBR kennt keine logischen Partitionen.

wie man über Konsole GRUB2 woanders als im MBR installiert

Findest Du es nicht logisch, an Stelle von /dev/sda einfach /dev/sda2 anzugeben?

 

[Anonymous]

Was meint Freddie62? Ich denke, das geht nicht, wenn GRUB2 im MBR ist. Bin etwas verwirrt...

Ja!
Viele Köche verderben den Brei.

 

[BeastXXL]

Es gibt nur (maximal) eine erweiterte Partition, und in genau deren Boot-Sektor muß der bootloader hinein (selbst YaST ist in der Lage, bei Dir /dev/sda2 als erweiterte Partition zu erkennen).

OK, also bei YAST nur "aus erweiterter Partition" auswählen. Nix anderes.
Ich weis, du kannst mir dazu keine Antwort geben, aber welche Partition ist bei YAST mit "Root-Partition" gemeint? Z.B. eine root-Partition, die eine primäre Partition ist (swap und home liegen auf einer erweiterten Partition)?
Und die Sache, dass ich alle drei Speicherorte gleichzeitig auswählen kann, ist mir ein Rätsel.

Der Boot-Code des generischen MBR kennt keine logischen Partitionen.

Äh, sorry, hatte ich überlesen...

wie man über Konsole GRUB2 woanders als im MBR installiert

Findest Du es nicht logisch, an Stelle von /dev/sda einfach /dev/sda2 anzugeben?

Ja, wenn man weis, dass das möglich ist. Bisher habe ich nur die /dev/sda-Version gefunden, die als sicher gilt. Wenn ich andere Möglichkeiten gefunden habe (was bei mir sehr selten war), gabs Warnungen in Massen. Und bei schlecht dokumentieren Sachen mache ich gern ein Fragezeichen dahinter.

@rolandb: Danke für die Richtigstellung.

OK, bis hierhin würde ich sagen, dass meine Eingangsfrage beantwortet wurde und ich danke allen ganz herzlich.

Ich hoffe inständig, dass alles funktioniert und ganz besonders, dass Win nicht auf die blöde Idee kommt, selbst die Boot Flag zu ändern. Habe solche Berichte gelesen. Es gibt zwar die Theorie, dass Boot Flag beständig ist, wenn man sie über Win setzt, aber eine Bestätigung dafür konnte ich noch nicht finden.

Sollte es trotz aller Bemühungen nicht gehen, weis ich ja, wie ich GRUB2 in den MBR istallieren kann Und spätestens dann melde ich mich wieder.

 

[josef-wien]

welche Partition ist bei YAST mit "Root-Partition" gemeint?

Für das laufende System kann es nur eine Systempartition geben, und das ist bei Dir /dev/sda7.

Boot Flag zu ändern

Das kannst Du mit jedem Live-System (auch das Rettungssystem der openSUSE-DVD gehört dazu) festlegen:

sfdisk -A2 /dev/sda

 

[BeastXXL]

welche Partition ist bei YAST mit "Root-Partition" gemeint?

Für das laufende System kann es nur eine Systempartition geben, und das ist bei Dir /dev/sda7.

Das ist schon klar. Ich dachte nur, evtl. ist damit eine andere Partition gemeint...weil es ja für mich keinen Sinn macht, GRUB in /dev/sda7 zu installieren.
Aber das soll eben "nur" ein grafisches Tool sein, welches alle Möglichkeiten durchführen können soll. Ob dabei etwas Sinn macht oder nicht, muss der User vor dem Bildschirm wissen...

Boot Flag zu ändern

Das kannst Du mit jedem Live-System (auch das Rettungssystem der openSUSE-DVD gehört dazu) festlegen:

sfdisk -A2 /dev/sda

Jepp, obwohl ich erstmal mit dem Tool von YAST mein Glück versuchen möchte. Wenn das nicht klappt (warum auch immer), dann versuche ich GParted oder evtl. Ranish Partition Manager von der Ultimate Boot CD.

 

[BeastXXL]

Hallo,

damit ich diesen Thread wirklich abschließen kann, möchte ich das Endergebnis und meinen Weg dorhin beschreiben.

Im Grunde hat alles, wie gewünscht funktioniert:
Wie weiter oben beschrieben, habe ich mit der Win-Install-DVD den MBR wiederhergestellt.
Der Reboot hat problemlos geklappt und Windows geladen.
Dann mit der SuperGrub2Disk (von der UltimateBoot-CD) das installierte openSUSE gestartet. Mittels YAST GRUB2 in die erw. Partition installiert und Bootflag auf Bootpartition setzen lassen. Hat übrigends sofort geklappt. Die Probleme aus div. Foren kann ich nicht bestätigen.
Auch der nächste Reboot hat wie gewünscht geklappt und das bekannte Menü geladen. Sowohl openSUSE als auch Win lassen sich wie gewohnt starten.

Soweit so gut. Eigentlich hatte ich mir gewünscht, mit dieser Konstellation für sämtliche Win-Patches (eben auch KB3033929) gerüstet zu sein. Da ich aber beim besten Willen nicht herausbekommen konnte, ob bei diesem Patch "nur" der Win-Bootloader im MBR reicht oder ob zusätzlich noch die erste Partition aktiviert sein muss, habe ich sicherheitshalber vor der Installation der Patches mittels cfdisk die Bootflag auf /dev/sda1 gesetzt. Ja, ich hatte weder Mut noch Lust wegen so einer Sache Probleme mit den Patches zu bekommen. :-/
Nach einem Reboot startete also Win automatisch und ich habe alle Patches ohne Probleme installieren können.
Wieder über SuperGrub2Disk openSUSE gestartet und mit cfdisk die Bootflag auf /dev/sda2 gesetzt.

Nachdem die Bootflag auf der erw. Partition stand, habe ich mal getestet, ob Windows sie automatisch auf die erste Partition ändert. Also habe ich Win gestartet, wieder heruntergefahren und dann den PC einige Zeit komplett vom Strom getrennt. Nach dem Neustart war klar: Win hat nichts verändert!

Mein Fazit: Es ist schön, wenn alles mal so funktioniert, wie vorgesehen. OK, der ganze Aufwand nur für so einen blöden Win-Patch ist schon irgendwie bescheuert. Mich würde interessieren, ob irgendjemand weiß, ob für diesen Patch auch die Bootflag auf /dev/sda1 nötig war oder nicht. Zumindest für zukünftige Patches wird es etwas einfacher, weil ich nur die Bootflag ändern muss. Wäre natürlich schöner, wenn das nicht nötig wäre...

Noch einmal ein großes Danke an alle für die vielen Tipps. Hat mir wirklich sehr geholfen

 

[Anonymous]

Wäre natürlich schöner, wenn das nicht nötig wäre...

Wäre schöner, wenn Micro$oft die friedliche Koexistenz mit Linux nicht ständig sabotieren würde.

Die Hunde wissen ganz genau, was deren Patches anrichten, schließlich gibt bei M$ seit über einem Jahrzehnt eine eigene Abteilung für Linux. Aber hilfreiche Tipps im Knowledge Base (KB3033929) sucht man vergeblich!