Archiv verlassen und diese Seite im Standarddesign anzeigen : Dual-Boot Mint/Windows 10 auf 1 oder 2 SSDs?
Plutos
2020-11-20, 18:27:48
Hallo,
sollte man o.g. Dual-Boot-System auf 1 SSD (entsprechend partitioniert) installieren oder auf 2 SSDs (Windows auf eine, Linux auf die andere)? Hat die Installation auf 1 SSD ggf. Vorteile beim späteren Umzug der Installation(en) in ein anderes PC-System oder lässt sich ein Dual-Boot-System auf 2 SSDs ähnlich problemlos auf neue Hardware umziehen?
Performance-Überlegungen spielen für mich eher keine Rolle, da ich hier 1. keine Beeinträchtigungen erwarte, auch wenn die Systeme auf derselben SSD liegen sollten, und 2. keine großen Datentransfers zwischen den beiden Betriebssystemen erfolgen werden. Ausreichend freier Speicherplatz stünde auch immer zur Verfügung. Mechanisch und elektrisch (Mehrverbrauch) auch alles kein Problem.
Hat einer der beiden Optionen entscheidende Vor- oder Nachteile, die mir nicht bewusst sind?
Is wurst.
Der einzige Vor/Nachteil ist die etwas schwierigere Trennung des Boot-Machanismus, falls Du das überhaupt hinbekommst, wenn Du es auf einer SSD veranstaltest.
Mache finden das ja toll, ein Startmechanismus für zwei OS zu haben, der beide OS unbenutzbar macht, wenn man ihn zerhackt. Deshalb hab ich es so formuliert.
Gebrechlichkeit
2020-11-20, 19:25:31
installier beide extern via hotswap device bzw. 2.5" case. stoepsel die ssd rein die grad gebraucht wird. habe ich so gemacht und mir den quark mit macrium reflect boot menu, linux boot manager und dem w10 erspart.
installier beide extern via hotswap device bzw. 2.5" case. stoepsel die ssd rein die grad gebraucht wird. habe ich so gemacht und mir den quark mit macrium reflect boot menu, linux boot manager und dem w10 erspart.
Wäre auch meine erste Wahl, da kein BS überhaupt erst die Möglichkeit hat, das andere BS zu zerschießen.
Wenn das keine Option ist, beide anschließen und F11 (oder ähnlich) Bootselect nutzen.
Plutos
2020-11-20, 19:37:21
Daran habe ich in der Tat auch schon gedacht, das wäre mir eigentlich am allerliebsten, wenn ich mich mit zusätzlichen Bootmanagern etc. gar nicht erst beschäftigen muss. Verstehe ich das richtig: bei der Installation stecke ich nur die SSD an, auf die installiert werden soll; nachdem beide OSe auf beiden SSDs installiert sind, stecke ich beide dauerhaft an und kann per Boot-Reihenfolge im BIOS/UEFI (oder eben über das Bootmenü "vom Mainboard") dann das eine oder das andere System booten?
Ein tatsächlicher physischer Wechsel der beiden SSDs i.s.V. Hot Swapping ist eher schlecht möglich, ich hätte schon gerne beide SSDs (nach einmaligem Setup) dauerhaft gleichzeitig angeschlossen.
Zu 95%+ wird eh Mint genutzt werden, insofern wäre es natürlich sehr elegant, für die seltenen Windows-Boots im BIOS das entsprechende Boot Device zu wählen.
Genau so isses. Du stellst das OS, das Du häufiger benutzt im Bios fest ein. Und wenn das andere starten soll, drückst Du zum Post die Quickboot-Select-Taste.
Das ist der Weg wenn man die Bootmanager trennt, egal ob nun auf 2 SSDs (der einfache Weg) oder mit Hilfe von 4 Partitionen auf einer SSD (der Aufwendige Weg).
Gebrechlichkeit
2020-11-20, 19:47:16
Clover EFI bootloader
https://sourceforge.net/p/cloverefiboot/wiki/Home/
The rEFInd Boot Manager
http://www.rodsbooks.com/refind/
Damit rumspielen, evtl. sind die besser als der von Windows.
Plutos
2020-11-20, 19:47:31
Genial, dann werde ich die bootmanagergetrennte 2-SSD-Installation so umsetzen, merci! :ulove:
Berniyh
2020-11-20, 20:09:12
bzgl. Migration ist das nur von Vorteil, wenn man die Installationen in getrennte Systeme überführen will, ansonsten ist es eher egal.
Und die Partitionierung, bzw. – falls später notwendig – Repartitionierung, ist etwas einfacher.
Is wurst.
Der einzige Vor/Nachteil ist die etwas schwierigere Trennung des Boot-Machanismus, falls Du das überhaupt hinbekommst, wenn Du es auf einer SSD veranstaltest.
Mache finden das ja toll, ein Startmechanismus für zwei OS zu haben, der beide OS unbenutzbar macht, wenn man ihn zerhackt. Deshalb hab ich es so formuliert.
Das stimmt so nur für Legacy Boot (was ich persönlich auch unter anderem deshalb bevorzuge).
Für UEFI stimmt das so ohne weiteres nicht mehr.
Wäre auch meine erste Wahl, da kein BS überhaupt erst die Möglichkeit hat, das andere BS zu zerschießen.
Stimmt für UEFI leider nicht so ganz, da kann ein Windows auch eine Linux Installation abschießen.
Tatsächlich kann das leider sogar ein BIOS (bzw. UEFI) Update. Selbst leider erst vor kurzem erlebt.
Der Vorteil von Linux ist da, dass es relativ einfach ist das wieder zu beheben, solange man einen USB Stick mit Live System hat.
Unter Windows (auch das habe ich leider schon hinter mir, allerdings Windows 7) ist das wesentlich aufwendiger und die Infos im Netz dazu sind sehr widersprüchlich und teilweise auch falsch.
Am Einfachsten und entspanntesten geht es ganz klar mit Legacy Boot.
Ich hab aber keine Ahnung, ob das mit Windows 10 noch geht.
Plutos
2020-11-20, 23:31:34
Also im BIOS kann ich die Legacy Boot Geschichte schon einstellen. Hatte das bei meinem bisherigen PC mit nur Windows 10 IIRC auch so, Windows 10 hatte damit kein Problem.
Macht es bzgl. Boot-Geschichten einen Unterschied, ob MBR oder GPT? Alle SSDs sind einzeln jeweils <= 2TB.
MBR ist uralt, nutze bitte GPT (UEFI) (Mein neun Jahre altes Notbebook nutzt schon UEFI)
Argo Zero
2020-11-22, 10:02:16
Ist zwar meine Mac Erfahrung (Hackintosh): Nimm getrennte Festplatten.
Es kann dir bei einem Win Update das EFI „zerschießen“ und es bootet am Ende nur noch Windows.
Ist mir selbst mal passiert und seitdem gibts nur noch physikalische Trennung. Im EFI Ordner sind teilweise schon Einträge, welche Treiber geladen werden und das beißt sich.
Geht sicherlich auch fixen aber ich möchte meine Freizeit nicht für so einen Krams opfern.
Berniyh
2020-11-22, 19:59:55
Macht es bzgl. Boot-Geschichten einen Unterschied, ob MBR oder GPT? Alle SSDs sind einzeln jeweils <= 2TB.
Soweit mir bekannt ist gibt es bei Windows nur die Kombinationen MBR und dann Legacy Boot und GPT und dann UEFI Boot. Ansonsten zickt es rum.
Bei Linux ist es im Grunde egal was du da nimmst. Spricht nicht wirklich was gegen GPT, insofern …
Plutos
2020-11-23, 23:09:33
Okay, dann bleibe ich bei Legacy Boot und MBR, für beide Systeme. Hat sich ja lange bewährt, und ich erkenne (bei meinen Massenspeichergrößen) keinerlei Vorteil an einer Änderung/Umstellung hin zu GPT (sorry Dorn, aber "uralt" ist für mich kein (Gegen-)Argument, solange es ohne Nachteile funktioniert ;)). :smile:
Gebrechlichkeit
2020-11-23, 23:19:29
Oder man installiert Linux (Host) und sofern das mobo es unterstuetzt (und die cpu), Windows10 "durchschleifen" bzw. GPU. Oder umgekehrt.
ID3dlVHDl0c
Benutzername
2020-11-23, 23:31:59
Ist zwar meine Mac Erfahrung (Hackintosh): Nimm getrennte Festplatten.
Es kann dir bei einem Win Update das EFI „zerschießen“ und es bootet am Ende nur noch Windows.
Ist mir selbst mal passiert und seitdem gibts nur noch physikalische Trennung. Im EFI Ordner sind teilweise schon Einträge, welche Treiber geladen werden und das beißt sich.
Geht sicherlich auch fixen aber ich möchte meine Freizeit nicht für so einen Krams opfern.
Ja. Dieses. Windows ist solipsistisch und geht davon aus, daß es allein im Universum ist und schreibt auch mal einen MBR oder EFI Partition neu bei einem Update. Auch andere parallele Windowsisntallationen verschwinden auch mal. Klar, kann man wieder hinbiegen mit zB einem Linux auf einem USB STick und dann GRUB wieder installieren. Aber wenn man zwei Physisch getrennte Datenträger hat ist das Risiko geringer. Man kann ja über das UEFI auswählen.
Disconnected
2022-10-11, 19:39:38
Ich hijacke diesen Thread mal. Ich hatte vor Jahren ein ähnliches Setup, wo ich die Bootreihenfolge auch über das BIOS festgelegt hatte. Mir wäre das bei meinem Setup aber mittlerweile zu umständlich, weswegen ich Grub bevorzugen würde. Installiert ist eine SSD mit Windows 7. Hinzukommen soll eine zweite für Linux, evtl. Mint. Wichtig ist für mich, dass ich die Installationen wieder trennen kann, d.h. kein OS irgendetwas auf dem jeweils anderen Datenträger zu suchen hat.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.