<a href="https://forum.lowlevel.eu/index.php?PHPSESSID=0683502a796c8abe523c0344da527fad&amp;">Lowlevel

Naja, dann mach halt wie du möchtest.

Das versuche ich ja schon die ganze Zeit, nur leider will GRUB seit neuestem nicht mehr mitmachen, nachdem er jahrelang ordentlich dabei war.

Du kannst ein ext4-Dateisystem mit einem ext3-Treiber mounten.

Es reicht mir nicht wenn meine Notfall-CD noch ein paar Dateien runterkratzen kann (und selbst das ist mit einem ext3-Treiber von ext4 nur sehr eingeschränkt möglich), es ist mir hingegen auch sehr wichtig das fsck.* usw. ordentlich funktioniert. Ich muss im Notfall die Linux-System-Partition ordentlich warten können (z.B. einen neuen GRUB installieren).

Wenn du weder DOS, noch Windows, noch Linux in deinem MBR hast - wo kommt der denn dann her?

Das ist ne Eigenentwicklung. Der lädt einfach den Boot-Sektor (eigentlich lade ich immer gleich 4 Sektoren) der ersten als Startfähig markierten Partition. Falls das ne erweiterte Partition ist dann wird eben wieder neu gesucht, in der neu geladenen Partitions-Tabelle, solange bis eine nicht-erweiterte-Partition als bootfähig gefunden wird. Zum HDD-Zugriff werden nur die erweiterten INT13h-Funktionen benutzt, Kompatibilität zu sehr alten PCs ist mir für meinem MBR nicht wichtig. Bevor der Code in einem Boot-Sektor ausgeführt/angesprungen wird wird erst geprüft ob auch eine korrekte 0xAA55-Signatur drin ist, im Fehlerfall gibt es ne ordentliche Meldung. Da hatte ich mal geplahnt das im Fehlerfall der User eine Partition (per Ziffer 0..9) manuell bestimmen darf welche dann gebootet wird, das selbe auch im Fall das keine Partition als bootfähig markiert ist, aber mangels Notwendigkeit und Zeit habe ich dafür noch nichts programmiert. Platz währe aber noch etwas dafür, ich glaube knapp 100 Bytes sind noch frei in meinem MBR.

Ich vermute ja, es ist der Standard-DOS-MBR

Das war er auch, bis ich vor etlichen Jahren ein Problem mit der 8GB-Grenze hatte, da hab ich das gleich selber ordentlich gelößt. War ne schöne Abwechslung in x86-Assembler, vor allem weil ich mich bemüht hab auf jedes einzelne Byte an Platzbedarf zu achten.

wo der vorhandene Festplatteninhalt egal ist

Dann ist das einfacher aber mir sind die Daten nicht egal. Okay ich hab von allem ein Backup im Prinziep könnte ich die Platte komplett löschen aber hinter meinem Partitionierungsschema stecken auch ein paar Überlegungen.

Code: [Auswählen]

- SWAP (für Linux)
- LINUX[reiserfs/jfs]
- WINDOWS[ntfs]
- ERWEITERT
  - SPEZIAL[FAT16] (z.Z. als SWAP für Windows, da war aber auch schon was anderes drin)
  - DATEN[FAT32] (FAT als kleinster gemeinsamer Nenner ist mir am liebsten)
  - EXTRA[???] (hier war mal probehalber ein BSD drin und als nächstes will ich da QNX rein packen, ich möchte dessen Micro-Kernel näher kennen lernen)

Erweiterte Partitionen und logische Laufwerke nutze ich nicht mehr, seitdem mir die Teile mehrmals um die Ohren geflogen sind, inklusive Daten und der primären Partitionen auf der Festplatte. Gelernt, ab sofort vermieden.

Warum? Was hast Du denn gemacht?
Klar ist das Konzept mit den verketteten und verschachtelten erweiterten Partitionen nicht gerade toll aber es funktioniert. Das Problem ist das die Partitionan auch in der Reihenfolge in den Verwaltungsstrukturen drin sein müssen wie sie auf der Platte sind (bei nur primären Partitionen kann man zwar dagegen verstoßen aber viele Tools haben damit Probleme) so das die Partitionen die man nach hinten, in den langsamen HDD-Bereich, legen möchte automatisch eine erweiterte Partition sein müssen. GPT ist dagegen eine echt tolle Weiterentwicklung aber nicht jedes OS kann damit nativ umgehen.

Daher: Mach, wie du es für richtig hältst.

Das habe ich vor.
Ich habe mir noch mal das ISO für Kubuntu 9.10 runter geladen und werde damit morgen nochmal mit reiserfs und JFS testen, damit ich eine Referenz habe und weis welchen GRUB das Kubuntu 9.10 per default benutzt. Danach probiere ich mal Kubuntu 10.04 ohne Boot-Loader zu installieren und bastle den GRUB legacy hinterher, per Notfall-CD, dran. Wenn alles nicht geht dann versuche ich mal eine extra Boot-Partition.

Mit etwas Glück habe ich dann endlich wieder eine (einigermaßen) stabile Situation. Also drück mir die Daumen.

Grüße
Erik

erik.vikinger · « **Antwort #24 am:** 28. May 2010, 13:20 »

Hallo,

da http://ubuntu-install.blogspot.com/2010/05/chainloading-grub-legacy-to-grub2.html hat jemand ein vergleichbares Problem wie ich (GRUB 2 will sich nicht aus der Root-Partition starten lassen) und eine sehr interessante Lösung. Das könnte ich auch probieren, ich installiere einfach im Kubuntu 10.04 den GRUB 2, lasse diesen aber nicht den Boot-Sektor (oder gar den MBR) überschreiben und rufe ihn stattdessen per 'kernel /boot/grub/core.img' aus dem GRUB legacy herraus auf. Das hat den Vorteil das die grub.cfg bei Kernel-Updates automatisch gepflegt wird (der Linux-Kernel selber wird ja schließlich erst von GRUB 2 geladen) und ich trotzdem den funktionierenden GRUB legacy im Boot-Sektor der Linux-Partition habe.

Grüße
Erik

Svenska · « **Antwort #25 am:** 30. May 2010, 18:21 »

Ich hab mal ein paar richtig alte Systeme auf meine Platte losgelassen (namentlich XENIX bzw. AIX) und hab beim Qemu einmal die reale Platte (d.h. /dev/hda) dort sekundär eingebunden. Danach war die erweiterte Partition weg, inklusive Datenpartition (konnte die Daten aber wiederfinden und retten).

Ein andernmal hat sich Windows ne Auszeit genommen und die Partitionen komplett verwürfelt - hda2 war plötzlich zweimal da (hda2 und hda5), dafür fehlte hda5 komplett, hda6 & hda7 waren plötzlich primär(!) hinter der erweiterten Partition. Ich hatte in der Erweiterten vorher die Partitionen verschoben, um mehr Platz für Linux zu haben. Das biss sich dann wohl gewaltig mit der manuellen Laufwerksbuchstabenzuteilung unter Windows. Gab auch ne Menge Spaß, die einzelnen Partitionen wiederzufinden...

Seitdem habe ich vor dieser Struktur ein bisschen Respekt.

In meinem MBR lebt übrigens /usr/lib/syslinux/mbr.bin vom SYSLINUX-Projekt, der tut in etwa genau das, was dein MBR auch tut.

Naja, und GRUB ist mir grundsätzlich suspekt.

Gruß,
Svenska

erik.vikinger · « **Antwort #26 am:** 01. June 2010, 18:12 »

Hallo,

also ich hab am Wochenende einiges Probiert und ich bin mir ziemlich sicher das im GRUB 2 seit kurzer Zeit ein Bug drin ist. Der GRUB 2 von Kubuntu 10.04 (Version 1.98-1ubuntu6) lässt sich nicht in eine Partition mit reiserfs oder JFS installieren, der GRUB 2 von Kubuntu 9.10 (Version 1.97~beta4) dagegen schon. Ich habe Kubuntu 9.10 jeweils einmal mit reiserfs und einmal mit JFS jungfräulich neu installiert (+ alle verfügbaren Updates einspielen lassen) und den GRUB 2 gut getestet und ein paar mal neu gestartet, es lief alles völlig problemlos, anschließend hab ich in beiden Fällen ein Live-Update auf Kubuntu 10.04 durchgeführt (direkt im KDE mit KPackageKit) was in beiden Fällen in einem nicht startbaren System endete (es kam eine GRUB-Fehlermeldung und dann nichts mehr).
Mit XFS ließ sich weder Kubuntu 9.10 noch Kubuntu 10.04 installieren.
Kubuntu 10.04 habe ich dann mit JFS aber ohne Bootloader (hab ich im Installer abgewählt) neu installiert. Starten ließ sich diese Installation so natürlich nicht. Als nächstes hab ich dann von meiner Notfall-Linux-CD GRUB legacy installiert was auch problemlos funktionierte und ein startbares Kubuntu 10.04 ergab. Im Kubuntu gab es offiziell keinen GRUB und die menu.lst musste ich daher händisch erstellen. Beim ersten großen Update wurde (ohne das ich das gleich mitbekommen habe) auch GRUB 2 installiert (jetzt sind in /boot/grub/ die Dateien von beiden GRUBs drin), dieser hat aber nicht den GRUB legacy im Boot-Sektor meiner Linux-Partition beschädigt so dass das System weiterhin startfähig war. Aber es wurde nicht nur der GRUB 2 ordentlich konfiguriert sondern auch die menu.lst von GRUB legacy um einige Einträge erweitert. Nach dem nächsten Neustart hab ich dann die automatischen Einträge in der menu.lst wieder gelöscht und einen Chain-Loading-Eintrag für die core.img von GRUB 2 angelegt. Wenn ich jetzt starte bekomme ich immer als erstes das Menü von GRUB legacy angezeigt und kann dort entweder den Linux-Kernel direkt starten oder GRUB 2 laden welcher dann seinerseits den Linux-Kernel startet. Mit dieser Situation bin ich fürs erste recht zufrieden.
Ob beim nächsten Kernel-Update die menu.lst auch wieder automatisch mitgepflegt wird (zusätzlich zum GRUB 2) weiß ich jetzt natürlich noch nicht aber damit kann ich mich sicher arrangieren. Zumindest werde ich nach dem nächsten GRUB 2 Update einfach mal probieren diesen in den Boot-Sektor meiner Linux-Partition zu installieren, wenn das gut geht kann ich GRUB legacy wieder löschen (also dessen Dateien aus /boot/grub/, richtig installiert ist er ja nicht) oder ich muss GRUB legacy mit der Notfall-Linux-CD wieder korrekt einrichten.

Ich hab mal ein paar richtig alte Systeme auf meine Platte losgelassen (namentlich XENIX bzw. AIX) und hab beim Qemu einmal die reale Platte (d.h. /dev/hda) dort sekundär eingebunden. Danach war die erweiterte Partition weg, inklusive Datenpartition (konnte die Daten aber wiederfinden und retten).

Sowas macht man ja auch nicht. Zu unterschiedliche Generationen vertragen sich einfach nicht, so wie im realem Leben ja auch.
Um DOS von meiner realen Festplatte, im laufenden Windows, zu starten hab ich diese mal in VMware eingebunden, aber nur ReadOnly (also so das die Änderungen extra gespeichert werden und beim Beenden von VMware gelöscht/verworfen werden), und zum schreiben hab ich die DOS-Partition im Host-OS per Netzwerk freigegeben und das dann im DOS in der VM als Netzwerklaufwerk eingebunden (über IPX/NetBeui). So hat das super funktioniert und für die reale Festplatte gab es keine Gefahr.

Ein andernmal hat sich Windows ne Auszeit genommen und die Partitionen komplett verwürfelt [....] Ich hatte in der Erweiterten vorher die Partitionen verschoben, um mehr Platz für Linux zu haben. Das biss sich dann wohl gewaltig mit der manuellen Laufwerksbuchstabenzuteilung unter Windows. Gab auch ne Menge Spaß, die einzelnen Partitionen wiederzufinden...

Da hast Du eventuell das falsche Werkzeug benutzt, ich hab früher mal mit Partition-Magic gute Erfahrungen gemacht. Mit anderen/heutigen Tools dieser Kategorie kenne ich mich nicht so gut aus, muss mir mal das GParted näher ansehen. Ansonsten partitioniere ich meine Festplatten immer mit Taschenrechner und Diskeditor.

Seitdem habe ich vor dieser Struktur ein bisschen Respekt.

Das ist wie bei einem Pferd, wenn Du nicht gleich wieder aufsteigst wirst Du nicht nur Respekt sondern Angst haben.

Deshalb hab ich jetzt auch mit dem GRUB so lange experimentiert bis ich einen Weg hatte der meinen Wünschen entspricht und funktioniert.

In meinem MBR lebt übrigens /usr/lib/syslinux/mbr.bin vom SYSLINUX-Projekt, der tut in etwa genau das, was dein MBR auch tut.

Die meisten MBRs machen in etwa das selbe, der entscheidende Punkt sind die verwendeten Methoden und die daraus resultierende Zuverlässigkeit. Ich ignoriere z.B. komplett die CHS-Angaben und nutze nur die 32Bit-LBA-Werte, dafür benötige ich aber auch mindestens einen 386.

Zitat von: erik.vikinger am 01. June 2010, 18:12

Naja, und GRUB ist mir grundsätzlich suspekt.

GRUB ist Bestandteil ges Gesamtpaketes "Kubuntu", daher lasse ich ihn auch nur Kubuntu starten und wenn er Probleme macht dann ist das ein "Kubuntu-Problem" (zumindest in meiner naiven Sichtweise). Insgesamt erscheint mir persönlich GRUB viel zu riesig und aufgeblasen, LILO hat seinen Zweck auch zuverlässig erfüllt.

Etwas haben die letzten Wochenenden auf jeden Fall gebracht: ich kenne jetzt den Installer von Kubuntu komplett auswendig.

Muss aber auch sagen das er ziemlich lahm reagiert. Das konfigurieren der Installation (als bis ich dann auf den "jetzt installieren"-Knopf drücken konnte) hat mehr als 15 Minuten gedauert (das meiste davon hab ich diese lustige Doppel-Stern-Animation, also das KDE-Pendant zur Windows-Sanduhr, beobachten dürfen), die eigentliche Installation (Daten kopieren usw.) hat weniger Zeit benötigt. Außerdem nervt es das die Fenstergröße nicht verändert werden kann, insbesondere bei der Auswahl der Partitionen musste ich ständig die Scrollbalken benutzen, obwohl gut 90% des Monitors nur das Hintergrundbild gezeigt haben.

Grüße
Erik

kevin · « **Antwort #27 am:** 01. June 2010, 18:48 »

Insgesamt erscheint mir persönlich GRUB viel zu riesig und aufgeblasen, LILO hat seinen Zweck auch zuverlässig erfüllt.

Außer dass man ihn vorher konfigurieren musste statt das beim Bootem machen zu können und dass man damit ein Problem hatte, wenn man sich verkonfiguriert hat (z.B. einen kaputten Kernel eingetragen). Das macht ihn meines Erachtens völlig indiskutabel.

Svenska · « **Antwort #28 am:** 02. June 2010, 00:29 »

Es handelte sich um Partition Magic, damit habe ich lange gearbeitet. Nach diesem Zwischenfall arbeite ich nur mit GParted, wobei ich mit meiner jetzigen Partitionierung recht zufrieden bin.

Der SYSLINUX-MBR ist modern und zuverlässig, zumindest habe ich bisher nichts anderslautendes gefunden. Für Taschenrechner und Diskeditor bin ich zu schusselig (mal eine Null vergessen und alle Daten sind weg - das lass ich lieber).

Ich empfehle dir die textbasierte Installation von Ubuntu, den Debian-Installer. Der reagiert zügig und man kann LILO auswählen. Der ist dateisystemunabhängig, lässt sich in jedes Dateisystem installieren und wenn du mit den Kerneln aufpasst, dann funktioniert er auch gut.

Da du solche Probleme mit GRUB hast, die von deinem grundsätzlichen Konzept/Wunsch herrühren, empfehle ich dir, auf ihn komplett zu verzichten. Alternativen existieren, aber keine universellen wie GRUB.

Gruß,
Svenska

erik.vikinger · « **Antwort #29 am:** 02. June 2010, 13:08 »

Hallo,

Zitat von: taljeth am 01. June 2010, 18:48

Außer dass man ihn vorher konfigurieren musste statt das beim Bootem machen zu können und dass man damit ein Problem hatte, wenn man sich verkonfiguriert hat (z.B. einen kaputten Kernel eingetragen). Das macht ihn meines Erachtens völlig indiskutabel.

Du hast natürlich völlig recht. LILO ist starr und unflexibel. LILO kann ganz genau einen Kernel laden, nicht mehr und nicht weniger. Wenn man damit zufrieden ist dann kann man mit LILO glücklich werden, andernfalls muss man sich nach Alternativen umsehen (es gibt ja genug). GRUB ist ein Boot-Manager und LILO ein Boot-Loader, ein umfangreicher Manager bietet eben unendlich mehr Komfort als ein simpler und starrer Loader. Ich persönlich benötige in 99,99% aller Systemstarts nur einen simplen Loader, alles was darüber hinaus geht kostet aus meiner Sicht nur CPU-Zeit. Wenn es Probleme gibt ist es mir deutlich lieber diese mit einem vollwertigen Linux von CD oder USB-Stick lösen zu können als das ich in einem Boot-Manager-Menü hänge (vor 4 Wochen hat die Rescue-Console von GRUB 2 auch nichts genutzt, da finde ich das monolithische Konzept für die Stage 2 von GRUB legacy besser). Der Eintrag für memtest86+ im GRUB-Menü ist zwar nett aber der Speichertest geht auch von CD. Wie oft wird der wohl bei einem durchschnittlichen User aufgerufen?

Es handelte sich um Partition Magic, damit habe ich lange gearbeitet. Nach diesem Zwischenfall arbeite ich nur mit GParted, ....

Hm, ich bin entsetzt. Muss aber auch sagen dass das letzte Partition-Magic, welches ich benutzt hatte, noch aus dem Jahre 2000 stammte und mit einem Trick auf einer DOS-Boot-Diskette Platz fand. Ich hab mit Partition-Magic aber auch nur Partitionen verkleinert/vergrößert oder verschoben. Das Einrichten meiner Festplatten hab ich schon immer selber gemacht.

Für Taschenrechner und Diskeditor bin ich zu schusselig (mal eine Null vergessen und alle Daten sind weg - das lass ich lieber).

Mir persönlich sagt diese Methode am meisten zu, so kann ich mir sicher sein dass das Ergebnis auch wirklich ganz genau das ist was ich will. Es macht zwar Arbeit sich alles genau auf zuschreiben und aus zurechnen aber es lohnt sich und passiert ja nur alle paar Jahre mal. Die Gefahr für Datenverlust auch auch nur sehr gering, bevor ich eine Partition formatiere prüfe ich natürlich ob die wirklich da liegt wo sie soll. Man kann z.B. per Diskeditor in den ersten Sektor einer Partition einen bestimmten Text schreiben und nach einem Neustart im laufenden Linux per "dd if=/dev/sdXY bs=512 count=1" prüfen was drin steht, das geht auch mit dem letzten Sektor.

Ich empfehle dir die textbasierte Installation von Ubuntu, den Debian-Installer. Der reagiert zügig und man kann LILO auswählen.

Dafür benötige ich diese "Alternate CD", stimmts? Vielleicht hab ich demnächst mal Zeit diese auszuprobieren. Auch SYSLINUX ist wohl mal einen genaueren Blick wert. Ich muss mir also mal die Zeit nehmen mein Boot-Konzept zu prüfen, andererseits komme ich mit dem derzeitigen Konzept bestimmt noch bis EFI zurecht und dann ist sowieso alles anders.

Der ist dateisystemunabhängig, lässt sich in jedes Dateisystem installieren und wenn du mit den Kerneln aufpasst, dann funktioniert er auch gut.

Ich weiß, LILO hat bestimmt gut 10 Jahre auf meinen PCs zuverlässig gedient. Wenn es mal ein Problem gab dann musste eben die Installations-CD/Disketten ran und das Problem war innerhalb von maximal 30 Minuten erkannt und behoben. Das GRUB mich jetzt 5 Wochenenden gekostet hat und ich für 4 Wochen nur eingeschränkte Linux-Möglichkeiten hatte ist zwar sehr ärgerlich aber hoffentlich nicht der Normalfall. Immerhin hat GRUB (legacy und 2) vorher einige Jahre unauffällig seinen Dienst getan.