FreeBSD auf gleicher Festplatte wie OpenSolaris?

[Gerry1]

Hallo!

Ist es möglich auf einer Festplatte in verschiedenen primären Partitionen FreeBSD und OpenSolaris zu installieren?

Ich setze gerade ein Multi-Boot-System auf:

In der ersten primären Partition ist Windows Vista installiert,
in der zweiten primären Partition ist Open Solaris 2008-05 XXL ct-Edition installiert,
die dritte primäre Partition ist noch frei (sie wurde bereits angelegt, aber noch nicht mit einem Dateisystem versehen),
bei der vierten primären Partition handelt es sich um eine erweiterte Partition, in der z.Zt. Linux Swap sowie Open Suse 11.0 und Ubuntu 8.04 installiert sind.

Ich würde nun gerne FreeBSD 7.0 in die dritte primäre Partition (ca. 40 GB) installieren.

Muß ich da mit Problemen rechnen oder vertragen sich FreeBSD und OpenSolaris nebeneinander auf der gleichen Festplatte?

Ich stelle diese Frage vorsichtshalber, da ich durch Zufall erfahren habe, dass beispielsweise eine Installation von zwei Solaris-Systemen auf einer Festplatte nicht möglich ist und ich nun Angst habe, dass sich FreeBSD und Open Solaris nebeneinander auf der gleichen Festplatte ebenfalls stören könnten.

Zusätzlich würde ich gerne noch wissen, ob es sinnvoll ist, die für FreeBSD vorgesehene primäre Partition vor der Installation mit einem Dateisystem zu versehen (und wenn mit welchem), oder ob dies dem Installer von FreeBSD überlassen werden kann?

Vielen Dank schon mal im Voraus!
M.f.G. Gerry1

[Daemotron]

FreeBSD benutzt für seine Slice einen anderen Typ als OpenSolaris. OpenSolaris kommt aus dem Tritt, wenn es auf einem Block Device zwei OpenSolaris-Slices findet (genauso wie FreeBSD's Bootloader keine zwei FreeBSD-Slices mag). FreeBSD und OpenSolaris sollten also nebeneinander funktionieren. Ich bezweifle aber, dass der FreeBSD Bootloader derzeit in der Lage wäre, OpenSolaris zu booten. Hier müsstest Du wahrscheinlich auf Grub zurückgreifen, das von OpenSolaris ja auch als Standard verwendet wird.

[typecast]

Zitat von Ogion

FreeBSD benutzt für seine Slice einen anderen Typ als OpenSolaris. OpenSolaris kommt aus dem Tritt, wenn es auf einem Block Device zwei OpenSolaris-Slices findet (genauso wie FreeBSD's Bootloader keine zwei FreeBSD-Slices mag).

Was genau meinst du mit zwei Slices auf einem Block-Device? Zwei Partionen die den Typ 165 haben, zwei FreeBSD-Labels innerhalb einer Partition oder etwas ganz anderes? Mit dem ersteren habe ich bisher keine Probleme gehabt. Ist das zweite das Problematische? Wenn ja: Warum?

FreeBSD und OpenSolaris sollten also nebeneinander funktionieren. Ich bezweifle aber, dass der FreeBSD Bootloader derzeit in der Lage wäre, OpenSolaris zu booten. Hier müsstest Du wahrscheinlich auf Grub zurückgreifen, das von OpenSolaris ja auch als Standard verwendet wird.

Kann man da nicht den normalen Loader im MBR lassen und den Grub in den Boot-Record der Partition schreiben?

[Daemotron]

Zitat von typecast

Zwei Partionen die den Typ 165 haben

Ist mir um die Ohren geflogen. Der FreeBSD Bootloader mochte das ganz und gar nicht haben (frag mich nicht warum...). Bei OpenSolaris kann ich das konkreter benennen: OpenSolaris verwendet einen gepatchten Grub. Der krallt sich einfach die erste Partition, die er mit Solaris assoziiert (deswegen darf z. B. auch keine Partition vom Typ 82 (Linux Swap, aber auch altes Solaris) vor der eigentlichen Solaris-Partition liegen). Hast Du jetzt zwei Partitionen gleichen Typs auf der Platte, würde immer von der ersten, aber nie von der zweiten gebootet.

Zitat von typecast

Kann man da nicht den normalen Loader im MBR lassen und den Grub in den Boot-Record der Partition schreiben?

Du kannst es versuchen, aber im OpenSolaris-Setup hast Du nicht die Möglichkeit explizit festzulegen, wohin grub installiert wird. Wenn Du vorher eine Partition vom Typ 0xbf anlegst und ihr das Bootflag mitgibst, packt der Installer grub nur in Bootsektor der Solaris-Partition. Ist die Partition aber nicht als aktiv markiert, landet er sowohl dort als auch im MBR.

[Endorphine]

Mal ernsthaft ... warum sich mit dieser Thematik überhaupt noch herumschlagen? Das Problem kann quasi als gelöst angesehen werden.

Die Realität ist doch, dass man mehrere Betriebssysteme direkt auf dem Blech installiert hat, um neben dem Haupt-OS, welches man >90% der Zeit nutzt noch weitere OS im Testbetrieb oder für andere weniger oft gebrauchte Funktionen zu haben.

Man kann sich das Leben aber deutlich leichter machen, in dem man einfach Betriebssystem-Virtualisierung unter dem Haupt-OS benutzt. Dann kann man die Neben-Betriebssysteme bei Bedarf ohne Neustart starten und auch wieder herunterfahren und damit herumspielen.

Den Sinn für Multi-Boot sehe ich heutzutage nur noch für wenige Spezialfälle (z. B. etwas unixoides als Hauptsystem und 1x die Woche 3d-beschleunigte Spiele auf dem selben Rechner unter Windows).

Gerade wenn zuerst Vista installiert wurde und dann ein bunter Reigen an Alternativen wie OpenSolaris, FreeBSD und Linux riecht das für mich sehr stark nach Testsystemen. Das geht viel einfacher mit Virtualisierung.

[Yamagi]

Wenn man wirklich zwei Systeme parallel haben will, würde ich immer die Methode "eine Platte pro System" bevorzugen. Einfach eine dedizierte festplatte für das neue System einbauen, es darauf installieren und bei Bedarf von dieser booten. Da kommt sich wenigstens nichts in die Quere und es ist heutzutage recht schmerzfrei, weil quasi alle modernen BIOSe ein Bootmenü zur Auswahl des Bootmediums bieten. Liegt meist auf "F8".
Ansonsten halt wie Endorphine sagt, virtualisieren um zu testen. Seitdem die Kombie "qemu + kqemu" auch unter FreeBSD/amd4 sauber laeuft, gibt es für die FreeBSD-Plattform zumindest einen benutzbaren Virtualisierer, für Linux, Windows und OS X ist die Auswahl viel größer. Dazu kommen die betriebssystemunabhängigen Produkte..

[menhir]

Entschuldigt und mit Verlaub und jedem Respekt und so
ABER
die meisten labern hier einfach so daher. Ist so. Punkt

erstens:
Eines meiner Hobbies ist Distro-Hopping.
Für Gerry1 : Hier habe ich meine Partitionstabelle

Platte /dev/sda: 81.9 GByte, 81964302336 Byte
255 Köpfe, 63 Sektoren/Spuren, 9964 Zylinder
Einheiten = Zylinder von 16065 × 512 = 8225280 Bytes
Disk identifier: 0x000ae2fa
   Gerät  boot.     Anfang        Ende     Blöcke   Id  System
/dev/sda1               1         913     7333641    7  HPFS/NTFS
/dev/sda2             914        1826     7333672+  a5  FreeBSD
/dev/sda3   *        1827        2739     7333672+  a6  OpenBSD
/dev/sda4            2740        9964    58034812+   5  Erweiterte
/dev/sda5            2740        3652     7333641   83  Linux
/dev/sda6            3653        4565     7333641   83  Linux
/dev/sda7            4566        5478     7333641   83  Linux
/dev/sda8            5479        6573     8795556   83  Linux
/dev/sda9            6574        6817     1959898+   c  W95 FAT32 (LBA)
/dev/sda10           6818        7912     8795556   83  Linux
/dev/sda11           7913        9842    15502693+  83  Linux
/dev/sda12           9843        9964      979933+  82  Linux Swap / Solaris

Die Partitionen habe ich damals mit der Slackware 11 CD erstellt - mit fdisk -.
Alle BSDs kommen super mit den Partitionen klar. Gar keine Probleme.
Installiert als Bootloader ist Grub - auf das MBR -, das mit meinem Ubuntu System installiert wurde. Da knallt gar nix. Alles funktioniert wunderbar. WinXP, FreeBSD, NetBSD, Ubuntu, Slackware, und auch OpenSolaris.
@Gerry1: Wenn du die Grub Befehle wissen willst, dann kann ich dir sie per PM schicken.

Zweitens:
Auf Virtualisierung würde ich als Testsystem verzichten.
WEIL
a)
Wenn ich FreeBSD testen will, dann will ich mal spielerisch von 6.3 auf 7.0 updaten mit der buildworld Prozedur.

Ich habe mir auf Ubuntu Qume mit KQemu installiert und da drin dann FBSD6.3.
Das buildworld hat 5 Stunden - nicht auf die Minute genau, aber so über den Daumen gepeilt - gedauert.

Buildworld auf dieser gleichen Maschine mit nativer Installation - also direkt auf Platte - dauert etwas weniger als 2 Stunden.

Wenn man Produktiv ein Entwicklungssystem aufsetzen will, wo man auf FBSD und NBSD und OBSD testen will, dann nimmt man auch eine richtig mächtige Maschine, wo dann das Host 4GB hat, und jedes der virtuellen Gäste knapp 1GB bekommen, was bei BSDs vollkommen ausreicht, besonders, wenn man die Gäste nur auf der Konsole bedient.

b) Nicht alle BSDs kommen mit KQemu klar. Ihr glaubt mir nicht? Dann kann ich euch Screenshots schicken, was NetBSD und OpenBSD beim Booten in der virtuellen Maschine mit KQemu anzeigen bzw. machen.
Damit - weil man ohne KQemu fahren muss - wird es noch langsamer.

c) Man will auch mal testen, was an eigener HW von den getesteten Betriebsystemen unterstützt wird - und auch mal einen eigenen Kernel für die eigene HW backen -. Das kann man nicht in einer virt. Umgebung.

Also Virtualisierung als Produktivsystem, ja klar. Aber als Testsystem, niemals.


Und wo man die Unix-artigen Systeme vollkommen problemlos nebeneinander installieren kann, braucht man auch gar keine drei oder vier oder fünf Platten.
Auch das wäre nur etwas für produktive Systeme so für RAID und ähnliches.

[Endorphine]

Zitat von menhir

Also Virtualisierung als Produktivsystem, ja klar. Aber als Testsystem, niemals.

In der Realität ist es nach meiner Erfahrung genau umgekehrt. Wo man früher massenhaft die meiste Zeit leerlaufende Test-/Entwicklungssysteme als physikalische Büchsen herumstehen hatte, werden heute VMs aufgebaut. Zum Beispiel um im Großmaßstab in einem ESX-Cluster Kosten zu sparen und die Flexibilität zu erhöhen oder im Kleinmaßstab, wo Software-Entwickler auf ihren gut ausgebauten Desktops lokal zusätzlich VMs laufen haben. Es gibt auch Szenarien, wo man z. B. eine VM jemandem anderen als komprimiertes Archiv auf DVD brennt, Arbeiten irgendwo anders daran vornimmt und dann wieder zurückbekommt (wahlweise auch via Netzwerk).

Produktivsysteme in x86-VMs sind dagegen meiner Meinung nach immer noch problematisch. Ernsthafte Anwendungen brauchen so viele Ressourcen, dass es keinen Sinn mehr hat, x86-Virtualisierung anzuwenden zu wollen. Und bei kleinen Systemen muss man auch abwägen, ob man einen Zustand möchte, wo z. B. ein zentraler ESX-Cluster insgesamt ein Problem hat und deshalb dann nicht nur ein paar Rechner ausfallen, sondern gleich potenziell der halbe Produktivbetrieb.

[FreeBSDuser]

Dualboot ist was feines.

FreeBSD + Windows aufm Desktop
und
FreeBSD + Ubuntu + Windows aufm Notebook

wer das unsauber findet kann ja bochs benutzen, denn der virtualisierungskram von VirtualBox, WMware VirtualPC und dem Qemu kram is eh alles riesengroßer Strickzauber, gefrickel ohne ende.

EDIT: Kann ich bestätigen, Grub ist wirklich gut, wenn mal was durcheinanger gerät. Einfach in die Grub console und FreeBSD per hand starten.

[menhir]

@Endorphine:
Du hast recht, aber bitte beachte doch, was das für Maschinen sind in den ESX-Clustern. ABER ...

Wir sollten nie aus den Augen verlieren, dass wir hier diskutieren, um für Gerry1 eine gute Lösung zu finden! Das ist der Sinn und Zweck dieser Diskussion.

Und ich kann mir vorstellen, dass er bei sich eine nicht so starke Maschine hat, aber trotzdem mal verschiedene OSe ausprobieren will.

Nach meiner inzwischen langjährigen Erfahrung als Distrohopper lohnt sich aus den von mir genannten Gründen nur eine native Installation
UND
man braucht keine verschiedenen Festplatten
UND
eine Installation auf primären Partitionen mit einem Grub als Bootloader funktioniert einfach.

Diese Punkte wollte ich einfach mal herausstellen, damit Gerry1 aus diesem Thread "klüger" rausgehen kann, während einige Diskutanten alles komplizierter machen, als es nötig ist.

[Yamagi]

Also, um mal wieder zum Thema zurückzukommen. Gerry möchte auf einer Platte mehrere Systeme installieren. Wenn er das machen möchte, muss ihm jedoch klar sein, dass die heute verwendeten DOS-Partitionstabellen eher bescheiden sind. In ihren Bezeichner inkonsistent, was gern mal Programme verwirrt. Auf vier Einträge begrenzt, was man durch ein übelstes Gefummel in den Griff bekommt, man verkettet sie einfach. Davon das irgendwie jedes Programm die Spezifikation der Tabelle anders interpretiert (wer schon mal versucht hat eine unter Windows partitionierte Platte mit FreeBSDs boot0 zu starten weiß wo von ich rede). So, nachdem nun die Probleme genannt wurden, gibt es drei Möglichkeiten:

1. Man nimmt einzelne Platten. Jetztendlich am schmerzfreisten, dafür relativ teuer.

2. Man nimmt GPT-Tabellen. Löst die Probleme der DOS-Tabellen, da sie viel mehr Einträge zulassen und vor allem dafür konstruiert wurden, auch größer geändert zu werden. Zumindest Solaris, Linux und FreeBSD (ab aktuellem 7-STABLE) haben damit keine Probleme mehr. Ärger machen wird da Windows, da Microsoft auch in Vista es mit der GPT-Unterstützung nicht wirklich geschafft hat. Keine Ahnung, wie dort die weiteren Pläne sind, es hieß mal, sie wollen nun vielleicht per Service Pack nachrüsten, auch in Hinblick auf die in absehbarer Zeit kommenden Platten von >2TiB, die DOS-Tabellen nicht mehr verwalten können.

3. Man akzeptiert die Limitierungen der DOS-Tabellen. In diesem Fall muessen oder sollten einige Dinge beachtet werden. Normalerweise startet FreeBSD so: boot0/mbr -> boot1 -> boot2 -> loader -> kernel, wobei boot1 und boot2 immer zusammen gesehen werden. Diese Kette ist tendetiell anfällig, da gerade boot1/boot2 recht dumm sind. Daher wirft man sie am besten raus und realisiert stattdessen folgendes: grub -> loader -> kernel. Geht problemlos. Aber auch dort muss der Kernel in einer primären Partition liegen und idealerweise ist es auch die erste Partition mit dem dezimalen Typ 165. Zusätzlich sollte man sich dringend glabel(8) zu Gemüte führen, um sie das Leben nicht noch schwerer zu machen, als man es eh schon gemacht hat. Und zum Schluss die Warnung: Wenn die Kiste nicht mehr bootet oder sich die Diplomarbeit ins Nirvana verabschiedet hat, weil sich irgendwelche Partitionsprogramme daneben benommen haben, selbst schuld.

[Endorphine]

Zitat von menhir

Diese Punkte wollte ich einfach mal herausstellen, damit Gerry1 aus diesem Thread "klüger" rausgehen kann, während einige Diskutanten alles komplizierter machen, als es nötig ist.

Kannst du mal die persönlichen Angriffe sein lassen? Hier gehts um Technik, nicht um Persönliches. Danke.

Im Übrigen habe ich ja gerade die Empfehlung zur Virtualisierung dieser Testsysteme gegeben, eben weil dann das Problem des Threads gar nicht mehr existiert und sich Vorteile ergeben wie Parallelbetrieb, keine Notwendigkeit zum Reboot mehr gegeben ist, man beim Ende des Tests dann nicht die Bootmanager und Partitionierung aufräumen muss etc.

Was der Threadersteller mit den Empfehlungen macht ist dann seine Sache.

Zum Thema: ich würde aus Kompatibilitätsgründen momentan nur klassische Partitionen verwenden, wenn es denn unbedingt noch Multi-Boot sein soll. Gerade wenn mehrere OS auf die Partitionstabelle schreiben hätte ich ein besseres Gefühl, wenn die Technik dazu alt und überall verstanden ist.

[Gerry1]

Lieber Ogion und menhir!

Vielen Dank für Eure Beiträge!

Bin leider erst heute dazu gekommen, mich wieder mit dem Thema zu beschäftigen.

Freue mich nun schon darauf, auch FreeBSD in mein Multi-Boot-System zu integrieren.

Grüße!
Gerry1