Warum Dualboot auf zwei Platten verteilen?

aRkedos schrieb:
Meine Frage ist eher: warum wird immer wieder empfohlen Linux und Windows auf getrennten Platten (sofern möglich) zu installieren?
Es ist wurscht!
Einschränkung: Wenn man es richtig macht.

Wenn 2 Platten da sind, trennt man es sinnvoller Weise. Ist zwar nicht nötig, aber sollte sich die Konfiguration Mal ändern, hat man halt weniger Arbeit. Desgleichen, wenn mal ein Datenträger die Grätsche macht oder eben das Wesen vor dem Rechner Unfug treibt.

MBR war gestern! Bzw. eh am Aussterben. Am besten erst gar nicht in Betracht ziehen bei Neuinstallation.
 
aRkedos schrieb:
Meine Frage ist eher: warum wird immer wieder empfohlen Linux und Windows auf getrennten Platten (sofern möglich) zu installieren?
Bei gescheiten Installation kann man jederzeit eine Platte ausbauen, und jedes OS startet ohne weiteren Probleme auf der einem installierten Datenträger.
 
Da ist ja auch erfüllt, wenn alle Systeme auf der selben Platte liegen.
Dass man jedes OS auf eine eigene Platte installiert, ist erst mit dem Aufkommen von SSDs in Mode gekommen, weil die anfangs relativ geringe Kapazitäten hatten. Deshalb hat man dann auch, zumindest in PCs, ein zusätzliches Laufwerk als Datenlaufwerk verwendet.
Früher(TM), d.h. als die Rechner nur eine Festplatte hatten, also so zu Windows 98 und XP Zeiten, hat man System und Daten auf verschiedenen Partitionen auf dem selben Datenträger gehabt und wenn man Multi-Boot verwendet hat, waren eben alle Systeme auf der selben Platte.
M.E. kann man das heutzutage auch wieder so machen, denn die üblichen Kapazitäten der SSDs sind groß genug um Platz für mehrere Systeme zu bieten ohne dass man irgendwelche Kompromisse eingehen muss.
 
SilenceIsGolden schrieb:
Da ist ja auch erfüllt, wenn alle Systeme auf der selben Platte liegen.
Nein, Du kannst dann nicht per Bios das Booten des jeweiligen OS wählen.
SilenceIsGolden schrieb:
Dass man jedes OS auf eine eigene Platte installiert, ist erst mit dem Aufkommen von SSDs in Mode gekommen, weil die anfangs relativ geringe Kapazitäten hatten.
Äh, nein? Mach ich schon seit Amiga Zeiten.
SilenceIsGolden schrieb:
Deshalb hat man dann auch, zumindest in PCs, ein zusätzliches Laufwerk als Datenlaufwerk verwendet.
Nein.
SilenceIsGolden schrieb:
Früher(TM), d.h. als die Rechner nur eine Festplatte hatten, also so zu Windows 98 und XP Zeiten
Nein, da waren auch schon mehrere Platten ohne weiteres möglich.
SilenceIsGolden schrieb:
, hat man System und Daten auf verschiedenen Partitionen auf dem selben Datenträger gehabt und wenn man Multi-Boot verwendet hat, waren eben alle Systeme auf der selben Platte.
Nein, es gab hier schon auch mehrere Platten und man konnte im Bios die Bootplatte auswählen.
SilenceIsGolden schrieb:
M.E. kann man das heutzutage auch wieder so machen, denn die üblichen Kapazitäten der SSDs sind groß genug um Platz für mehrere Systeme zu bieten ohne dass man irgendwelche Kompromisse eingehen muss.
Nein.

Dank SCSI und selbst ATA konnten mehrere Platten einbinden. Ich hatte schon immer mehrere Platten drin, angefangen beim Amiga 4000 per ATA und SCSI, später ebenso im ersten PC. Sorry all Deine Statements sind falsch.
 
Ponderosa schrieb:
Wenn du auf 2 Platten getrennt installierst, kannst du im Bios wählen was du starten möchtest.

Möglich ist vieles, jedoch habe ich seit jeher Linux und Windows auf zwei getrennten SSDs installiert.

Das wurde mir damals von einem freundlichen Menschen in einem Linux Forum ans Herz gelegt und hat sich als einfach und zuverlässig für mich bewährt. Jeweils eine 250GB SSD pro Betriebssystem nebst Programmen langen mir da immer noch völlig. Datensicherungen, Spielearchive, Video-/Musikarchive etc. befinden sich dementsprechend auf anderen Datenträgern. Speziell für Datensicherungen auf HDD kommen bei mir auch ein Wechselrahmen oder eine USB 3.0-Dockingstation zum Einsatz.

SSDs traue ich da immer noch nicht so recht in puncto "Langlebigkeit" der Daten, was mittlerweile vielleicht unbegründet sein mag. Obwohl im Keller aufbewahrt und Jahre nicht mehr benutzt, waren jedenfalls die Daten auf vier HDDs noch zuverlässig lesbar. Die hatte ich einfach nur aufgrund ihrer zu geringen Kapazität ausgemustert und aus Neugier mal wieder angeschlossen, ob darauf überhaupt noch was lesbar ist.
 
  • Gefällt mir
Reaktionen: Ponderosa
aRkedos schrieb:
warum wird immer wieder empfohlen Linux und Windows auf getrennten Platten (sofern möglich) zu installieren?
Disclaimer: Ich bin dieser Empfehlung nie gefolgt und hatte nie größere Probleme damit.

Auf MBR-Systemen ist die Koexistenz von Linux und Windows mit Aufwand verbunden, weil Windows gerne mal den MBR überschreibt und Linux dann nicht mehr startet. Umgekehrt macht das Löschen der Linux-Partition (wenn man wieder nur Windows will) GRUB kaputt, so dass der Rechner gar nicht mehr startet. Diese Probleme vermeidet man, wenn man Windows und Linux auf getrennte Laufwerke installiert. Seit UEFI ist das allerdings entschärft.

Daneben liest man gelegentlich Berichte, dass Windows Linux-Partitionen löscht. Das ist mir aber noch nicht passiert. Windows ist bekannt dafür, die Partitionierung bei Upgrades ohne Rückfragen zu verändern, also sind diese Berichte durchaus glaubhaft. Wer ganz sicher gehen will, hat Linux auf einem getrennten Laufwerk und stöpselt es bei den größeren Upgrades ab.
 
PHuV schrieb:
Nein, Du kannst dann nicht per Bios das Booten des jeweiligen OS wählen.
Das funktioniert doch mit UEFI problemlos. BIOS gibt es seit ~2011 nicht mehr, oder sagen wir: nur noch gaaanz vereinzelt in Spezialbereichen.
Wer heutzutage noch MBR-Installationen verwendet, dem ist eh nicht mehr zu helfen ;)

Dank SCSI und selbst ATA konnten mehrere Platten einbinden…
Richtig. Für SCSI mussten wir allerdings ein paar Wochenenden extra Arbeiten :D

Generell ist es wumpe, auf welcher Platte du was installierst. Du kannst frei Partitionieren und zuweisen, wie es dir beliebt. Ob das sinnvoll ist, bleibt dir überlassen. Falls deine EFI-Partition mal zu klein ist, legste halt wo anders ne größere an.
Ich persönlich teile Platten (eigentlich auch schon immer) in System(e) und Nutzerdaten ein. Geht auch innerhalb von „Linuxen“ bequem mit LVM, andere Systeme wie FreeBSD (oder Windows) bekommen ihre eigene Partition fürs System. Alle neu installierten Systeme tragen sich ins EFI-Menü ein. Wessen Boot-Menü du dann verwendest ist Geschmackssache und mit efibootmgr einstellbar. Ich mag systemd-boot (ehemals Gummiboot), weil es schön einfach ist, die meisten dürften wohl GRUB oder rEFInd verwenden.
 
Sommersocke schrieb:
Das funktioniert doch mit UEFI problemlos. BIOS gibt es seit ~2011 nicht mehr, oder sagen wir: nur noch gaaanz vereinzelt in Spezialbereichen.
Wer heutzutage noch MBR-Installationen verwendet, dem ist eh nicht mehr zu helfen ;)

Ich antworte mal etwas provokativ: wer Dualboot heute noch in Zeiten von VMs verwendet, dem ist nicht mehr zu helfen. ;)
 
fischfilet schrieb:
Ich antworte mal etwas provokativ…
Na, den Vergleich finde ich aber nicht sinnvoll. Dual-Boot kann sich definitiv lohnen, je nachdem was man mit den Systemen macht. Alles lässt sich nicht so einfach virtualisieren. Es bringt z.B. nur bedingt etwas mit passthrough zu arbeiten, wenn man sich einen angepassten Gerätetreiber zurechtfummelt — da braucht es schon mal das echte System. Und trotzdem möchte ich das nicht in meinem Hauptsystem machen. Dafür kenn ich mich zu lange :D
 
Sommersocke schrieb:
da braucht es schon mal das echte System. Und trotzdem möchte ich das nicht in meinem Hauptsystem machen. Dafür kenn ich mich zu lange :D
Manchmal geht das nicht, das stimmt, aber in vielen Fällen ist DB unsinnig.
 
Reicht schon, wenn man das Hauptsystem schützen will. Ich erinnere mich da an meine Versuche mit den modernen Tastaturen. Wenn du die in der VM in einen anderen Modus setzt, gilt das auch im Hauptsystem, dank des vollautomatischen USB-passthrough. Damit haste dann beide Systeme auf einmal unbedienbar gemacht.

Ansonsten bin ich ganz bei dir. Mir sind VMs auch lieber. Zum einen, weil ich die überall im Netzwerk verfügbar habe, zum anderen weil ich nicht alles Abspeichern, Aufräumen und wechseln muss; ganz zu Schweigen von der Bequemlichkeit eines Snapshots vor gefährlichen Experimenten. Bootloader im MBR sind aber eher was für Nostalgiker. Da gibt es keinen technisch sinnvollen Grund mehr, außer den selten vorkommenden Geräten ohne funktionierendes UEFI.
 
  • Gefällt mir
Reaktionen: fischfilet
fischfilet schrieb:
Ich antworte mal etwas provokativ: wer Dualboot heute noch in Zeiten von VMs verwendet, dem ist nicht mehr zu helfen. ;)
Ich antworte Mal ähnlich provokativ. Wer ein Produktivsystem in Abhängigkeit eines anderen OS betreibt, dem ist echt nicht mehr zu helfen. :)
 
@mo schrieb:
Wer ein Produktivsystem in Abhängigkeit eines anderen OS betreibt
Naja, dafür muss man nicht ständig rebooten um ins andere System zu kommen. Da kann ich das Fenster mit der Windows-VM einfach minimieren wenn Windows mit sich selbst beschäftigt ist und mit meinem "richtigen" OS weiterarbeiten :)
 
fischfilet schrieb:
Naja, dafür muss man nicht ständig rebooten um ins andere System zu kommen. Da kann ich das Fenster mit der Windows-VM einfach minimieren wenn Windows mit sich selbst beschäftigt ist und mit meinem "richtigen" OS weiterarbeiten :)
Klar!
Als Produktivsystem würde ich das trotzdem nie und nimmer machen. Ist ja durchaus möglich, dass man beide als solches benutzt.
Muss halt jeder selbst wissen. Ich halte die Dinge lieber schön getrennt, wenn es nicht unbedingt anders sein muss. Das bisschen Rebooten frisst kein Brot, und seit UEFI ist selbst das in 30-40 Sekunden (runter und hochfahren) erledigt
 
@mo schrieb:
Als Produktivsystem würde ich das trotzdem nie und nimmer machen.
Es steht ja nirgends geschrieben, dass ein Produktivsystem unbedingt virtuell sein muss. Aber gegenüber nativer Installationen hat man schon einige Vorteile. Deswegen hat sich ja im Serverbereich sowas wie VMWare ja auch schon längst durchgesetzt.
 
  • Gefällt mir
Reaktionen: @mo
Moin, ich möchte mich hier nochmal einklinken obwohl der letzte Beitrag im August 2021 geschrieben wurde.
Ich möchte aus einem bestehenden Dual-Boot-System, Win11 - LinuxMint auf NVMe, die LM-Partition auf eine eigene NVMe auslagern. Später sollte LM auf der ersten NVMe gelöscht werden Was ist zu beachten?
Gruß Teuti
 
Teuti schrieb:
Moin, ich möchte mich hier nochmal einklinken obwohl der letzte Beitrag im August 2021 geschrieben wurde.
Du, niemand verhaut dich, wenn du für eine neue und eigene Frage einen eigenen Thread aufmachst.

Prinzipiell hab ich mein Mint bisher umgezogen, indem ich den Inhalt der Root- und Home-Partition in die jeweils neuen Partitionen (bzw. btrfs-Subvolumes) kopiert habe, dann die neuen Partitionen in die /etc/fstab eingetragen habe und zuletzt mit chroot bzw. arch-chroot (kann man unter Mint mit dem Paket arch-install-scripts installieren) Grub in die neue EFI-Partition geschrieben habe.
 
Zurück
Oben