[gelöst- Danke] boot-Partition

[MonDa]

Hallo,

zur boot-Partion habe ich zwei Hinweise hier im Forum in zwei unterschiedlichen Beträgen gefunden, zu denen ich noch Fragen habe - dehalb mache ich ein neues Thema auf.

Thema: Re: Debian (Squeeze) - Ein paar allgemeine Fragen
(kann ich auch zu einem anderen Thema verlinken? - editiere hier noch gerne nach falls es das übersichtlicher macht - bitte schreibt mir eine PM wie, damit der Beitrag nicht so unübersichtlich wird)

Wenn du weitere Betriebsystem installieren möchtest, brauchst du min. 1 primäre Partition um davon booten

Das ist aber jetzt schon wirklich lange Geschichte...

1.
Liegt jetzt hier die Betonung auf "weitere Betriebssysteme" oder gilt das auch für mehrere - ev. sogar gleiche Debianversionen - um updates oder neu eingespielte Pakete zu testen und gleichzeitig noch ein unberührtes System zu habe?

2.
worauf bezieht sich "Das ist aber jetzt schon wirklich lange Geschichte ..."
wie alt ist das - ist das nun gelöst?

hierzu möchte ich noch "Re: "Unable to install GRUB" bei Debian Erstinstallation" zitieren

Nein das bringt nichts, grub2 (grub-pc Paket) hat mit ext4 keine Probleme, das ist nur bei grub-legacy der Fall.

Die Version aus Squeeze lässt sich nicht in eine logische Partition installieren. Auch wenn der grub-install Befehl durchläuft und am Ende sagt "no errors reported" wird der Bootsektor nicht geschrieben. Siehe bugreport: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=611463

Du kannst also entweder grub-legacy mit einer ext3 boot-Partition benutzen oder du aktualisiert grub-pc auf die Version in testing. Oder du erstellst die boot-Partition als primäre Partition. Oder du verzichtest auf deinen Windows-Bootloader.

Welchen Weg willst du gehen?

Hier habe ich den Link " http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=611463" genutzt - verstehe aber wohl noch nicht den Umgang mit bugs in Debian -heißt der Kommentar

tag 611463 fixed-upstream
thanks

das der Fehler gefixt ist und in den Installations-DVD's von Debian 6.0.4 (das ich heruntergeladen aber noch nicht installiert habe) nicht mehr existiert?

Danke

[owl102]

Debian Squeeze ist definitiv auch in einer nicht-primären Partition (problemlos und geradeaus) installierbar. In solch einem Falle muß dann aber der GRUB2 in den MBR, was aber sowieso bei den meisten Installationen gewünscht sein sollte, und auch der default ist.

Möchte man hingegen zum Beispiel den Windows-Bootmanager nutzen, und von diesem auch Linux booten, dann muß ja der GRUB2 in die Boot-Partition (da der Windows-Bootmanager Linux nicht selber direkt booten kann) und die muß (aufgrund des von dir erwähnten Fehlers) dann zwingend eine primäre Partition sein. (Oder man nimmt in diesem Falle alternativ Grub-legacy, oder Grub2 aus testing, oder LILO oder... Da in diesem Falle der Linux-Bootmanager nur dazu dient, um dem Windows-Bootmanager das Booten von Linux zu ermöglichen, ist es in diesem Falle wohl sekundär, welchen Linux-Bootmanager man denn dafür verwendet. Der Bug läßt sich also problemlos und ohne Nachteile umgehen.)

das der Fehler gefixt ist und in den Installations-DVD's von Debian 6.0.4 (das ich heruntergeladen aber noch nicht installiert habe) nicht mehr existiert?

Laut

http://packages.debian.org/changelogs/p ... /changelog

ist der Bugfix noch nicht bei Squeeze angekommen.

[wanne]

2.
worauf bezieht sich "Das ist aber jetzt schon wirklich lange Geschichte ..."
wie alt ist das - ist das nun gelöst?

Keine Ahnung, irgend wann ist mir mal aufgefallen, dass Mandriva automatisch auf ne erweiterte installiert. (Das war so ca. 2009) Und seither weiß ich dass es geht.
Das gilt Ausdrücklich auf für eine Installation in die ersten Sektoren der erweiterten Partition. (Wobei man dann einen Grub braucht, der an die changeloaded.)

Nein das bringt nichts, grub2 (grub-pc Paket) hat mit ext4 keine Probleme, das ist nur bei grub-legacy der Fall.

Auch das ist mehr oder weniger falsch:
GNU will den Grub2 durchdrücken und schreibt deswegen seit Jahren keine Upgrades für grub-legacy mehr. => Der Grub von upstream hat keinen ext4 Support weil es länger keine updates gibt, als ext4 existiert.
Nutzt man allerdings die weitergepatchten Versionen der verschiedenen Distros haben die meisten ext4 Support. (Und das schon länger als ext4 als stabiel gilt.) Konkret weiß ich das von denen von Mandriva Gentoo und Fedora. Den von Debian hab ich nie genutzt.
Problematisch wird grub-legacy nur mit UEFI.

[MonDa]

Hi,

Danke für die Hinweise.

Vielleicht erkläre ich erst einmal mein Ziel:

Ich habe eine 160 GB Sata-Platte - zugegeben alt - aber zum spielen riesig .

Ich möchte nur Debian installieren (ev. in einem jetzt noch nicht denkbaren Fall auch mal ne andere Distri um was auszuprobieren). Außerdem möchte ich sogar die gleiche Version mehrmals (auf verschiedenen Partitionen installieren). Der Zweck z.B. den ersten Update nach der Installation auszuprobieren - aber noch ein Vergleichssystem zu haben, für den Fall dass Probleme auftauchen.

Außerdem, noch ein Grund, warum ich meine mehrere Installationen zu brauche, ist:
Ich will verschiedene Anwendungen im Bereich Projektmanagement/Termin- u. Zeitplanung ausprobieren.
Wenn irgendetwas bei einer Anwendung nicht funktioniert und ich nicht weiß, ob sich die Pakete beeinflussen, jedes Anwendungspaket auf einer separaten Installation zu testen.

Hatte irgendwas gelesen, dass eine Systempartition so 10 GB haben sollte.

Also würde ich ja viele Systeme auf die Platte bekommen - wenn da nicht die Grenze der nur 4 primären Partitionen wäre - was ja scheinbar doch kein Problem ist. So wie ich die Antwort von owl102 verstehe, sollte man ja auch in noch mehreren logischen Partitionen Systeme installieren können.

Fragen:
Gibt es da eine Grenze der Anzahl möglicher Debian-Systempartitionen ausser dem Platz den man auf der Platte hat?
Ist das korrekt, wenn ich davon ausgehe, dass ich beliebig viele logische Partitionen als Systempartition nehmen kann?
Wieviele Einträge unterstützt eigentlich Grub2? - sind da Probleme absehbar.

Mein Ding ist schon der Weg von owl102.

Debian Squeeze ist definitiv auch in einer nicht-primären Partition (problemlos und geradeaus) installierbar. In solch einem Falle muß dann aber der GRUB2 in den MBR, was aber sowieso bei den meisten Installationen gewünscht sein sollte, und auch der default ist.

Denn ich verstehe es ganz gut, dass man von der Entwicklerseite versucht, eine Schiene zu fahren und nicht zwei Versionen ewig zu pflegen - auch wenn ich natürlich auf open source stehe, weil man da sämtliche Freiheiten hat zu tun was man will - also auch selbst den Source code für seinen Zweck anpassen kann.

Jedoch möchte ich nicht den Preis zahlen, dass ich wenn ich Hilfe benötige allzuweit vom Standard entfernt bin. Deshalb sind die Vorschläge noch mit grub Standard rumzubasteln nicht so mein Ding.

Übrigens - das verstehe ich nicht - einerseits sagt owl102 - das geht andererseit sagt er

Laut

http://packages.debian.org/changelogs/p ... /changelog

ist der Bugfix noch nicht bei Squeeze angekommen.

Wieso da meldet doch jemand "fixed" und sagt "thank you" oder bezieht sich das

tag 611463 fixed-upstream
thanks

auf ein anderes Problem?

??? - Verzweiflung, das mit meinem Wunsch, Software ist klar und deutlich - eine Anweisung tut immer etwas bestimmtes - ein Bit ist gesetzt oder nicht - also ist immer alles eindeutig - trifft wohl nicht immer auf den organisatorischen Teil - und schon gar nicht auf die Erfahrung die man braucht um etwas sicher in der Doku zu finden zu.

PS:
@wanne
Bitte sei mir nicht böse, dass ich mit Deinem Vorschlag hier nicht so recht etwas anfangen kann. Ich möchte aus obigen Gründen keine "weitergepatchten Versionen der verschiedenen Distros" für Debian verwenden.
Ich möchte Dir ausdrücklich für Deine Mühe der Erläuterung danken.

Irgendwie finde ich es nicht ganz unberechtigt, wenn ein Projektteam sich entscheidet eine alte Version nicht mehr zu pflegen.
Hier entwickeln Leute Software ja freiwillig und kostenlos(bzw. ohne direkten Preis für die Nutzung) und wenden hierfür Zeit auf. So entscheiden natürlich auch diese Leute wie viel Zeit Sie in die Pflege von alten Versionen stecken - denn wenn ich freiwillig etwas gebe kann ja gerne jeder offiziell daran weiterentwickeln, wenn er sich mit dem Projekt abspricht - solange ich die Arbeit damit nicht habe.
Aber selbst ein Projekt (bzw. eine alte Projektversion) weiter organisatorisch zu betreuen ist ja schon Aufwand, das heißt man müsste klären ob das die neue Person auch mit übernimmt.
Für ein Gesamtprojekt bedeutet ein branch natürlich, dass sich die eingesetzte Energie auf zwei Projekte verteilt - ist auch nicht immer so toll - gehört aber zur Freiheit.
Ich persönlich weiss ja vorher nicht wie lange ich wie viel weitere Zeit investieren kann/will, so wollte ich mir dieses Recht auch immer vorbehalten.

Nochmals Danke an Alle.

[wanne]

Bitte sei mir nicht böse, dass ich mit Deinem Vorschlag hier nicht so recht etwas anfangen kann. Ich möchte aus obigen Gründen keine "weitergepatchten Versionen der verschiedenen Distros" für Debian verwenden.

Ich nehme mal an dass es bei der debian Version ähnlich ist (Kann das aber nicht mit sicherheit sagen). Aber bei Grub-legacy handelt es sich ja nicht wirklich um einen integrierten Teil der Distribution. Man kann sich problemlos den Bootloader von Getoo ziehen auf einer Partition entpacken in den MBR schreiben (mit Debian oder ner LiveCD oder sonst irgend was) und schon hat man den Bootloader von Gentoo mit einem Debian System. Das ist nicht wie bei irgend welcher Software wo man Abhängigkeiten oder so hat.

Irgendwie finde ich es nicht ganz unberechtigt, wenn ein Projektteam sich entscheidet eine alte Version nicht mehr zu pflegen.

Ja, klar aber da er nichtmehr bei GNU gepflegt wird ist es nicht sinnvoll GNU als Quelle für die Funktionalität anzugeben.

denn wenn ich freiwillig etwas gebe kann ja gerne jeder offiziell daran weiterentwickeln, wenn er sich mit dem Projekt abspricht - solange ich die Arbeit damit nicht habe.

RedHat hatte die patches das GNU Projekt wollte sie net.

Aber selbst ein Projekt (bzw. eine alte Projektversion) weiter organisatorisch zu betreuen ist ja schon Aufwand, das heißt man müsste klären ob das die neue Person auch mit übernimmt.

Genau das ist passiert nur das es nicht eine übernommen hat sondern jede Distro für sich...

Ist das korrekt, wenn ich davon ausgehe, dass ich beliebig viele logische Partitionen als Systempartition nehmen kann?

Nein, neuere Kernel (Also überall da wo die HD irgendwas mit sdxX heißt können nur noch mit einer recht begrenzten Anzahl von logischen Partitionen umgehen. (Ich glaube 7 oder 8 oder so.)

[schwedenmann]

Hallo

st das korrekt, wenn ich davon ausgehe, dass ich beliebig viele logische Partitionen als Systempartition nehmen kann?

IDI Platten 3x primäre und 60 (oder 61) log.
SATA max. 15 Partitionen

Linux muß nicht in eine primäre Partiton, wie Win, installiert werden, um davon zu booten.



mfg
schwedenmann

[wanne]

IDE Platten 3x primäre und 60 (oder 61) log.
SATA max. 15 Partitionen

Seit der sata-Treiber auch für IDE-HDs zuständig ist gelten für IDE die gleichen Einschränkungen, wie für sata. => Auch 15 Partitionen (Und ich dachte 12 muss ich mich geirrt haben...)

[MonDa]

Hallo,

erst einmal danke an wanne (für die Erklärung) und an Schwedenmann.

Muß mich wohl für meine Frage entschuldigen - da im normalen wikipedia unter "Partition (Informatik)" Absatz "Zugriff und Nutzung" unter "UNIX" genau das was schwedemann mir erklärte beschrieben ist.

Hallo

st das korrekt, wenn ich davon ausgehe, dass ich beliebig viele logische Partitionen als Systempartition nehmen kann?

IDI Platten 3x primäre und 60 (oder 61) log.
SATA max. 15 Partitionen

Bei dieser alten Platte stört mich die Begrenzung auf 15 Partitionen nicht.

Jedoch wollte ich wenn ich etwas Erfahrung habe eine neue Platte anschaffen. Leider bekommt man ja nur noch riesengroße Platten.

Nun bin ich schon etwas enttäuscht, dass man dann auch noch nur 15 Partitionen anlegen kann. Etwas naiv war ich aus der immer größer werdenden Plattenkapazitäten am folgern, dass natürlich eher mehr als weniger Partitionen unterstützt werden.

Aber hier geht man wohl davon aus, dass sowieso mit LVM gearbeitet wird.

Was natürlich eine Nutzung wie ich diese gerade plane (viele Systeminstallationen nebeneinander) ausschließt.

Futsch der Traum, wenn meine kleine Platte nicht für das testen verschiedener Projektmanagementsystem ausreicht, weil z.B. eine Datenbank benötigt - oder so richtig viele Daten Platz haben sollen egal ob mit oder ohne Datenbank - man ja zum Testen beim selbst programmieren eine Schnittstelle verwendet, die sowohl in einer Datenbank als auch noch anderweitig die Daten speichert (zur Sicherheit vor Falschbedienung der DB) und um hin- und wieder die Daten automatisiert zu verifizieren. Ja da würde dann die Zahl der möglichen Partitionen schon knapp.

Nun ja kommt Zeit, kommt Rat - als erstes arbeite ich mit der kleinen Platte. Ich hoffe dass, bis ich eine grosse Platte mit dem geschilderten Problem brauche, auch andere dieses Problem schon hatten und es eine komfortable Lösung gibt.

PS:
Ich bin nun einmal eher Minimalist:
Bisher habe ich eigentlich immer eher 2 kleinere Platten einer sehr großen vorgezogen (die Überlegung um so dichter die Daten geschrieben werden, um so unsicherer - so denke ich und außerdem wenn eine Platte defekt ist betrifft das nicht gleich alles).
Das enttäuscht mich nun ein bischen, da ich davon ausgegangen wäre

Nochmals Danke.

[Cae]

Aber hier geht man wohl davon aus, dass sowieso mit LVM gearbeitet wird.

Was natürlich eine Nutzung wie ich diese gerade plane (viele Systeminstallationen nebeneinander) ausschließt.

Naja, wenn alle oder die meisten verwendeten Systeme mit LVM zurecht kommen, kann man das doch weitgehend anstelle von Partitionen verwenden? Man muss beim Installieren halt verflixt aufpassen, dass man sich nix zerschießt. Könnte man aber aus dem laufenden System mit debootstrap oder ähnlichen Methoden umgehen.

Gruß Cae

[wanne]

Naja, Du brauchst nicht für jede installation eine Partition:
Dir reicht ein /boot Partition, die alle Kernel (also die aller Distributionen) und einen grub enthällt und alles andere kann in den LVM.
Da muss man dann halt ein bisschen selbst Hand anlegen, weil die Autokonfiguraton von Grub wahrscheinlich nicht mehr funktioniert.
Aber ich hatte schon mehrer Distros mit einer /boot partition das ist im Prinzip kein Problem. Wenn man verschieden Distros hat, dann bekommt man das wahrscheinlich sogar hin ohne grub nach jeden Kernelupdate zu konfigurieren.
Bei mehreren gleichen Distros mit unterschiedlichen kernels werden die Scripte etwas komplizierter, die man nach jedem Kernel update ausfühen muss.

[MonDa]

Danke.

Nun gebe ich erstmal Ruhe und probiere mit der kleine Platte und einfachen Partitionen.

Vielleicht habe ich das vergessen zu sagen - ich bin ein ziemlich blutiger Linux-Anfänger und verfüge bezüglich Linux nur über etwas Knoppix-Erfahrung und allgemeines IT-Wissen, Grundlagen Betriebssystem und etwas Programmierung - also gerade genug um halbwegs qualifizierte Fragen zu stellen.

Mehrere Bücher die ich in der Hand hatte, rieten Anfängern von LVM eher ab.

Ich möchte eigentlich auch keine Installation "Man muss beim Installieren halt verflixt aufpassen, dass man sich nix zerschießt. "

Irgendwie bestätigt sich bei mir immer die Aussage "Der Mensch ist ein wechselintelligentes Wesen" - ich bin nicht immer gleich gut drauf - muss aber manchmal trotzdem eine Arbeit voranbringen - dann ist eine Umgebung mit "verflixt aufpassen" nicht effektiv.

@wanne
irgendwie bin ich noch im Zweifel, ob ich überhaupt eine separate bootpartiition brauche. Wahrscheinlich weil man die für die Verwendung von logischen Partitionen als Systempartition braucht.

Denn mein schlauer keep it simple - Kofler - meinte dass grundsätzlich, wenn man mehrere Systeme installiert für jedes System eine eigene bootpartition das ganze ziemlich unübersichtlich macht.

Andererseits scheint mir nur eine bootpartition und diese fortwährend anpassen wie wanne schreibt auch nicht so, dass ich mir das zutrauen.

Habe aber auch gelesen dass /boot die Kerneldatei vmlinuz* enthält.
So kann ich mir nicht so richtig vorstellen, wenn die Kerneldatei die ja wohl den Systemkern darstellt, nicht getrennt für jedes System existiert, wo dann der Witz liegt, wenn ich versuche für eines der Systeme testhalber einen Update einzuspielen (und dabei das andere System nicht berühren will) - wobei ja vielleicht auch Korrekturen im Kernel stattfinden - oder war da etwas dass man zwischen einem "Kernelupdate" und einem "update" unterscheidet?

Ihr merkt schon - Memory-Overflow - meine Gedanken drehen sich nur noch im Kreis

Für heute verabschiede ich mich dann.

[wanne]

irgendwie bin ich noch im Zweifel, ob ich überhaupt eine separate bootpartiition brauche. Wahrscheinlich weil man die für die Verwendung von logischen Partitionen als Systempartition braucht.

Seperate boot partition ist immer dann muss, wenn man eben nicht von der root Partition booten kann. (z.B. weil sie gecryptet ist - oder wie in deinem Beispiel im LVM liegt (Oder kann Grub auch LVM?))
Ich persönlich halte es aber für sinnvoll zumindest eine Seperate Parition zu haben, auf der der Bootloader derim MBR sitzt liegt. Wenn das ein Grub-legacy ist kann der da liegen bleiben egal wie viele Distros dahinter kommen oder gehen.

Habe aber auch gelesen dass /boot die Kerneldatei vmlinuz* enthält. So kann ich mir nicht so richtig vorstellen, wenn die Kerneldatei die ja wohl den Systemkern darstellt, nicht getrennt für jedes System existiert, wo dann der Witz liegt, wenn ich versuche für eines der Systeme testhalber einen Update einzuspielen (und dabei das andere System nicht berühren will) - wobei ja vielleicht auch Korrekturen im Kernel stattfinden - oder war da etwas dass man zwischen einem "Kernelupdate" und einem "update" unterscheidet?

Nu hast das * ignoriert: Das 2 unterschiedliche Kernel exakt den gleichen namen haben ist sehr unwahrscheilich. (Im normalfall steckt die Kernelversion und Architektur im Namen und die einzelen Distros haben verschiedene Namensschemen.) Und wenn du einen Kernel durch exakt den gleichen erxsetzt ist das auch kein Problem. (nie initrd wird das etwas verwirren aber wenn man über grub die richtigen Parameter mitgibt passt das schon irgen wie.)
Problematisch wird das nur, wenn man einen Kernel im einen OS entfernt, der im andren noch genutzt wird. Aber auch da kann man aufpassen und den vielleicht noch nicht deinstalliern. Aber all die Probleme gibt's nur wenn es wirklich Betribssysteme exakt den gleichen Kernelnamen nutzen. Bei unterschiedlichen Betribsystem eher unwahrscheinlich.
=>
- Im normalfall heißen alle kernel anders => kein Problem.
- Kommt es doch zu 2 Kernel mit gleichem namen sind sie im Normalfall gleich => Man muss ein bisschen aufpassen aber auch kein Problem.
Erst wenn 2 unterschiedliche Kernel den gleichen namen haben wird das Problematisch.

[schwedenmann]

Hallo

Nun gebe ich erstmal Ruhe und probiere mit der kleine Platte und einfachen Partitione

n.

Das Problem bei den großen Platten, sind die hohen Preise seit Oktoiber 8Überschwemmung in Thailand) letzten Jahres, das wirkt immer noch nach.

Du kannst mit LVM arbeiten, brauchst es aber nicht. Wenn du in etwa abschätzen kannst, für was du die Systeme benötigst und welchge porogramme (und damit wieviel Platz) du benötigst, steht doch normalen Partitionen nichts im Wege.

Ich z.B. habe eine 1TB Platte als Systemplatte mit einem Hauptsystem (LVM + Luks), daneben dann noch 2x Debian, 1x Arch und 1x Sabayon die / für alle Systeme gehen von 4-25GB .

mfg
schwedenmann

[MonDa]

Danke für die Aufklärung, über den Bennungsschema von vmlinuz* .

Das war was mir gefehlt hat. Es ist toll Informationen zu bekommen, ohne erst einmal installierten und selbst ausprobieren zu müssen.

Aber all die Probleme gibt's nur wenn es wirklich Betribssysteme exakt den gleichen Kernelnamen nutzen.

Genau das habe ich ja vor - das gleiche System mehrmals haben - z.B. um zu testen ob verschiedene Pakete gleichzeitig installiert Fehler verursachen, die wenn das Paket einzeln installiert ist nicht auftreten.

Seperate boot partition ist immer dann muss, wenn man eben nicht von der root Partition booten kann. (z.B. weil sie gecryptet ist - oder wie in deinem Beispiel im LVM liegt (Oder kann Grub auch LVM?))

Ich glaube hier liegt ein Mißverständnis vor.
ich habe mich bezüglich meiner aktuellen 160 GB Platte dafür entschieden kein LVM zu verwenden. Zwischenschichten erweitern die Menge von Code der Fehlerursache sein kann (Fehler die nur in einer ganz seltenen bestimmten Konstellation vorkommen fallen manchmal lange nicht auf - und Linux-Systeme sind ja sehr individuell - n verschiedene Kombinationsmöglichkeiten ergibt ... verschiedene Konstellationen) - machen das ganze mit Sicherheit nicht schneller - für die kleine Platte reichen wohl 15 Partitionen.

Debian Squeeze ist definitiv auch in einer nicht-primären Partition (problemlos und geradeaus) installierbar. In solch einem Falle muß dann aber der GRUB2 in den MBR, was aber sowieso bei den meisten Installationen gewünscht sein sollte, und auch der default ist.

Also owl102 hat eigentlich nicht gesagt, dass dies nur mit LVM ginge - er hat gesagt dass man GRUB2 im MBR haben muss. Natürlich arbeite ich dann in der Bootpartition auch mit GRUB2 (dann muss ich mich im Moment nur mit dieser Version beschäftigen - das reicht mir - und ich hoffe, das ist möglich).

Oder setzt GRUB2 LVM voraus? In meinem Buch stand glaube ich nur, dass GRUB2 das nun auch direkt unterstützt. - Ich habe verstanden dass Du, wanne, lieber mit dem alten Grub-legacy arbeitest, deshalb hast Du mit GRUB2 ja vielleicht nicht die Erfahrung um mir das sagen zu können. Vielleicht sagt mir das dann ja jemand anderes.

Was ich nicht verstehe:

Ich persönlich halte es aber für sinnvoll zumindest eine Seperate Parition zu haben, auf der der Bootloader derim MBR sitzt liegt. Wenn das ein Grub-legacy ist kann der da liegen bleiben egal wie viele Distros dahinter kommen oder gehen.

Wieso "zumindest" ?
ich dachte ja auch darüber nach, für jede Systeminstallation auch bzw. gerade weil es um die gleiche Version gehen wird - für die ich dann eine updaten will und eine nicht.
Vielleicht wäre es dann das 100% sichere 2 Bootpartitionen zu haben. Dann braucht man beim Löschen auch nicht aufpassen.

Problematisch wird das nur, wenn man einen Kernel im einen OS entfernt, der im andren noch genutzt wird. Aber auch da kann man aufpassen und den vielleicht noch nicht deinstalliern.

[/quote]
Man löscht ein System und eine Bootpartition und aller Rest ist noch da - so denke ich mir das?
Zuerst dachte ich mir "es ist ja vielleicht gar nicht so unübersichtlich, wie mein Buch schreibt, man erkennt ja am Dateinamen von vmlinuz* zu welchem System die jeweilige Bootpartition gehört", das ist aber ja genau falsch, da gleiche Systeme natürlich auch die gleiche vmlinuz benutzen. (vielleicht installiere ich ja gar nicht 2x sondern kopiere nur mit dd - hierfür möchte ich ein separates Thema im Forum aufmachen)
wie Du ja auch schreibst

Frage:
Hierzu stellt sich die Frage - ob auch Bootpartitionen logische Partitionen sein können.

Nun werde ich mal Frühstücken - habe auch gesehen dass Schwedeman während ich hier schreibe geantwortet hat - das lese ich später - hoffe dass sich damit meine Aussagen hier nicht überflüssig werden.

[schwedenmann]

Hallo

Hierzu stellt sich die Frage - ob auch Bootpartitionen logische Partitionen sein können.

Es gibt afaik nur 2 Linuxe, die explizit eine primäöre Partition benbötigen, debian, Suse, Mandrake, Archlinux z.B. zählen nicht dazu, wo bei diesen aufgezählten Distris, die /boot liegt, ist wurscht !, du kannst /boot auf sda8 und / auf sda1 legen.

mfg
schwedenmann

[Cae]

Oder kann Grub auch LVM?

Ja, kann er, zumindest der GRUB2. Ich hatte hier mal ein komplett-LVM zusammengespielt, da lag /boot bzw. / im LVM drin und es hat anstandslos gebootet. Imho steckt GRUBs Treiberkrempel nach dem MBR und vor der ersten Partition, da ist auch für einen LVM-Treiber genug Platz.

Gruß Cae

[MonDa]

Hallo,

Danke an schwedenmann.

Für diese Diskussion zum Platzbedarf habe ich ein neues Thema aufgemacht - um Euer Forum nicht ganz unübersichtlich zu machen.

Platzbedarf für die Systempartition einschätzen.

Das Thema boot-Partition ist soweit für mich geklärt - Danke an alle.