Neues MSI Notebook mit Dualboot

Hinweis: In dem Thema Neues MSI Notebook mit Dualboot gibt es 29 Antworten auf 3 Seiten. Der letzte Beitrag () befindet sich auf der letzten Seite.
  • Bei mir läuft Dualboot ohne Probleme, allerdings Windows 10 auf SSD und Leap 15.2 auf HDD. TW ist für mich noch keine Alternative.

    Die Rechtschreibfehler in diesem Beitrag sind nicht urheberrechtlich geschützt. Jeder der einen findet darf ihn behalten und in eigenen Werken weiterverwenden.

    Für den Inhalt des Beitrages 290974 haftet ausdrücklich der jeweilige Autor: Heinz-Peter

  • Was ist mit /boot/efi , wird die gebraucht?

    Windows hat bestimmt eine angelegt, oder?

    Wie groß ist die?

    Windows 10 legt üblicherweise 3 Partitionen an:


    1. Partition 100 MB = /boot/efi

    2. Partition 16 MB = keine Ahnung wozu Windows die braucht

    3. Partition 127 GB = die eigentliche Windowspartition


    Für Linux würde ich, wie bereits vorgeschlagen, die Windows-Partition um 40 GB verkleinern und dort die Root-Partition / installieren.

    Auf der HDD neben /swap (~3 GB) und /home (Rest der Kapazität***) noch eine weitere /boot/efi als FAT32 mit 512 MB hinzufügen.


    *** Falls noch ein weiteres Windows-Laufwerk benötigt wird, kann dieses hier sehr gut als weitere Partition untergebracht werden. Ich würde diese dann als NTFS formatieren, somit hast du bei Bedarf auch Zugriff von Linux aus.


    Ich habe früher immer eine gemeinsame /boot/efi gehabt, was auch grundsätzlich gut funktioniert, allerdings sind die von M$ veranschlagten 100 MB sehr wenig (openSUSE schlägt hier mindestens 256 MB vor), und ich hatte auch schon ein mal Trouble mit Grub2 nach einem Kernelupdate.

    Die Anzahl der vorhandenen /boot/efi-Partitionen im System ist im Übrigen beliebig.

  • So, jetzt bin ich wieder online, nach einer LANGEN Nacht.


    Mein Neffe war zufällig gestern Nachmittag in einem Computerladen und hat mir dann eine 1 TB NVME SSD mitgebracht. Er hat Erfahrung im Öffnen von Gehäusen, was mir sehr lieb war.

    Im Bios war zuerst eine SATA SSD mit 256 GB und die SATA HDD mit 1000 GB angezeigt. Nach dem Öffnen des Gehäuses waren wir allerdings verwundert, dass die SSD nun doch im PCIe steckt und kein weiterer mehr frei war. Trotzdem habe ich mir dann die 1 TB NVME eingebaut.

    Zuerst habe ich die Windowspartition mit Clonezilla auf die 1 TB HD geklont.


    Neustart - Booten von Clonezilla und zurückspielen von Windows. Es geht natürlich nicht, viele Versuche mit unterschiedlichen Optionen.

    Irgendwann im Bios dann herausgefunden, dass die neue SSD nun eben als PCIe - Karte eingetragen ist und die Reihenfolge der Festplatten verschieden war.


    Ok, Neuinstallation von Windows - läuft wunderbar - mit UEFI


    Installation von openSUSE - ärgerlich. Der Installer bietet keine Möglichkeit, Partitionen zu verkleinern, sondern nur zu löschen und neu anzulegen ! GRrRRRR


    Neugebootet mit gparted und die Partitionen angepasst.


    Neuinstallation von openSUSE. Läuft soweit bis der Installer sagt, die EFI Partition sei zu klein oder nicht vorhanden (128 MB Minimum). Windows legt natürlich nur eine mit 100 an.


    Reboot mit gparted um die Partitionen anzupassen. Damit kann Windows gar nicht umgehen. Windows lässt sich auch nicht installieren, wenn ich während der Installation alle Partitionen selber anlege. Neuinstallation mit einer EFI-Partition von 130 MB - ist für den Installer immer noch zu klein.


    Nocheinmal Neustart mit gparted - alle Partitionen gelöscht. Nur eine EFI Partition mit 256 MB angelegt, den Rest Windows überlassen.


    Nun mit der Windows Datenträgerverwaltung die Partition verkleinert und nochmal openSUSE installiert. Diesmal kein Murren - Gott sei Dank!


    Schön das nur Windows bootet - so wie vorhergesagt. Aber der Bootloader wurde richtig geschrieben.


    Nun noch schnell als Admin in der Eingabeaufforderung:bcdedit /set {bootmgr} path \EFI\opensuse\shim.efi


    Schön - es läuft.


    Danke für die Unterstützung und die Diskussionsbeiträge.


    Frage zum oben aufgeworfenen Thema:


    Wenn es immer wieder zu Problemen kommt, weil Grub aktuallisiert wird, kann man dann nicht Grub mal vorsichtshalber von den Aktuallisierungen ausschließen?

    Für den Inhalt des Beitrages 290984 haftet ausdrücklich der jeweilige Autor: glenturret

  • Wenn es immer wieder zu Problemen kommt, weil Grub aktuallisiert wird, kann man dann nicht Grub mal vorsichtshalber von den Aktuallisierungen ausschließen?

    Probleme gibt es nur bei Parallellbetrieb von Windows und Linux. Bei einem reinen Linux auf dem Rechner gibt es keine Probleme mit Grub. Und natürlich kannst du Grub von den Aktualisierungen ausschließen, wenn du das möchtest.

  • Nun noch schnell als Admin in der Eingabeaufforderung:bcdedit /set {bootmgr} path \EFI\opensuse\shim.efi

    Mich interessiert warum hast Du diesen Eintrag vorgenommen?

    Eventuell wo hast Du es gelesen?

    Die Rechtschreibfehler in diesem Beitrag sind nicht urheberrechtlich geschützt. Jeder der einen findet darf ihn behalten und in eigenen Werken weiterverwenden.

    Für den Inhalt des Beitrages 290987 haftet ausdrücklich der jeweilige Autor: Heinz-Peter

  • Mich interessiert warum hast Du diesen Eintrag vorgenommen?

    Eventuell wo hast Du es gelesen?

    Ich habe es geschrieben, weil vielleicht auch andere über diese Fallen stolpern und sich das vielleicht ersparen können.


    Zuerst habe ich den erwähnten Artikel auf https://de.opensuse.org/Dual-Installation_neben_Windows gelesen wie du erwähnt hast.

    Allerdings stimmen dort einige Sachen für Windows nicht, z.B. die Befehle um die Datenträgerverwaltung aufzurufen. Außerdem werden Sachen erwähnt wie die Vergabe eines Laufwerkbuchstabens für die EFI Partition usw. Das hat bei mir, vor allem in Kombination mit den falschen Kommandos für die Befehlszeile, mehr Verwirrung ausgelöst als es mir geholfen hat.


    Dann habe ich den Artikel


    http://www.jens-mueller.org/er…ot_opensuse422_win10.html


    gefunden.


    Er beschreibt im wesentlichen das selbe, bleibt in seinen Ausführungen aber sehr sparsam und verwirrt nicht mit Kommandos, die man nicht braucht. Der Artikel bezieht sich zwar auf Dualboot mit Leap 42.2 ist aber direkt auch für Leap 15.x oder Tumbleweed anzuwenden.


    Meine Ausführungen habe ich dazu geschrieben, weil vielleicht nicht alle wissen, das Windows eine zu kleine EFI-Partition für openSUSE anlegt oder dass der Installer sich so schwer tut mit Partitionsverkleinerungen.

    Natürlich hängt der Erfolg immer auch damit zusammen welches BIOS/UEFI mit welchen Einstellungsmöglichkeiten man hat.

    Bei mir gibt es nur Legacy oder UEFI und bei UEFI ist Secure Boot automatisch aktiviert, da gibt es auch keine Möglichkeit das auszuschalten. Vielleicht werde ich den Artikel für Dualboot auf openSUSE mit dem zweiten und meinen Erfahrungen mal in eine schöne Form bringen und den hier reinstellen.


    LG glenturret

  • Du hattest ja neben dem Thema der Dualboot-Installation auch danach gefragt, wie man Daten eines der Betriebssysteme vom jeweils anderen lesen kann. Von OpenSUSE aus hast Du ohne Weiteres Zugriff auf die Windows-Dateien, es muss nur jeweils die Windows-Partition, auf die zugegriffen werden soll, eingebunden werden. Von Windows aus bekommst Du Zugriff auf Dateien unter Linux per Diskinternals Linux Reader.

    Für den Inhalt des Beitrages 290999 haftet ausdrücklich der jeweilige Autor: matbhm

  • Es hat früher mal einen Treiber für ext3 gegeben, da konnte man von Windows problemlos auf die Daten auf Linux zugreifen. Wie schaut es da mit XFS aus. openSUSE schlägt ja vor, die Datenpartition mit XFS zu formatieren.

    Für den Inhalt des Beitrages 291005 haftet ausdrücklich der jeweilige Autor: glenturret

  • Bei ext3 ging das noch, nach meiner Erinnerung schon bei ext4 nicht mehr. Und der richtig ist, dass sich unter XFS die Dateien vollständig nur mit dem kostenpflichtigen LinuxReader Pro bearbeiten lassen. MIt dem einfachen Reader lassen sich die Dateien nur auslesen. Ich selbst nutze aus gutem Grunde ext4. Ist bewährt und für den Privatrechner völlig ausreichend.

    Für den Inhalt des Beitrages 291009 haftet ausdrücklich der jeweilige Autor: matbhm