ubuntuusers.de

Hallo Ubuntuianer,

hatte mit clonezilla 1.2.2-31 (für Karmic) sdb1 bis 7 zurückgeschrieben. Der Grub2 sitzt auf sda1 (HD 0).

Anschließend war Grub weg und nur windows ließ sich mit der Grub2 supergrub 1.2.1 cd booten. Ubuntu nicht!

Kann das sein, dass es daran liegt, das Ubuntu auf einer anderen Festplatte (interne) liegt. Ubuntu an sich ist zurückgeschrieben worden, der Grub nicht. Hat jemand eine Idee?

Gruss Ria

Hallo Ria,
sehe ich das richtig, Du hast bei der Installation Grub2 nicht in den MBR sonder in den Bootsektor der Partition sda1 geschrieben? Wenn ja, dann sollte eigentlich eine Neuinstallation in die Partition die Lösung sein.

Saludos de Chile

Hallo RapaNui,

also, verstehe Dich wohl auch nicht so richtig, deshalb noch mal was genauer. Ich hatte normal installiert!! Da ist doch HD 0 als Standard Angabe drin. Das ist auf der ersten physikalischen Festplatte, wo windows drauf ist.

Das funktionierte ja auch erst mal alles korrekt! (Inzwischen habe ich ganz neu installiert und jetzt passiert ganz was neues, Grub2 braucht 4 Minuten, bis sein Auswahlfenster erscheint)

Das soll, bzw. war aber jetzt nicht das eigentliche Thema. Ich hatte die große Festplatte wo alles funktionierte ausgebaut, auf der befindet sich eine partitionelle Sicherung der Ubuntu Partitionen. Diese Platte ist nun die externe Sicherungs- (backup) Platte geworden.

Nun habe ich eine andere leere Festplatte eingebaut, dort ein Basis-Ubuntu installiert und nun den Test gemacht, mit clonezilla CD die Ubuntu Partitionen von der jetzt externen Festplatte zurückgeschrieben.

Jetzt gibt es 6 Möglichkeiten warum der Grub2 weg war:

1. die neue clonezilla Cd kann den Grub2 nicht rücksichern, hat also noch einen Bug.

2. man sollte besser noch die Finger von Grub2 lassen.

3. befindet sich der Grub2 auf der HD 0 einer anderen physikalischen Festplatte geht ein Backup mit dem Grub deswegen grundsätzlich nicht, weil ich beide Festplatten zusammen sichern müsste(wegen Grub2).

4. ich habe einen Bug im Kopf und übersehe eine clonezilla Einstellung im restore Fenster.

5. und warum konnte Grub2 supergrub 1.2.1 CD nicht helfen, bzw. wieso kann der Grub2 überhaupt kaputtgehen, wenn der sich auf einer anderen physikalischen Festplatte befindet.

6. meine "neue" Festplatte hat einen Knacks.

Es geht also erst mal nicht darum, wie repariere oder erstelle einen neuen Grub2, sondern wo liegt der Fehler im Sicherungsvorhaben? Was nützt mir Ubuntu, wenn ich den notwendigen Grub nicht, in einem Rutsch, mitsichern kann.

Gruss Ria

Also ich verstehe es richtig: Du hast ein Backup von sdaX zurückgeschrieben, Ubuntu befindet sich auf sdbX und war früher mal ein 9.04 (hatte also ein Grub Legacy) und due hast auf Grub2 geupdatet?

Dann is es klar, dass dein backup nicht funktuioniert. Im MBR steht nur der Ladecode und Sprungbefehl zur nächsten Stufe von grub. uIn dem von mir beschriebenen Szenario hast du den alten Ladecode zurückgespielt, der an einen Stelle der Festplatte springen wollte, wo jetzt (nach Update auf grub2) nichts mehr gültiges steht.

Hallo redknight,

und due hast auf Grub2 geupdatet?

Geupdatet? nun die Sicherung ist auch bereits die 9.10 Version, die ja auch bereits mal in Betrieb war, als ich die Festplatte noch nicht als externe laufen hatte. Davor war mal 9.04 auf der Kiste mit dem alten Grub. Aber der war ja schon durch die Neu-Installation überschrieben und die Sicherung ist von der 1 Neu-Installation, der 9.10.

Gruss Ria

@ria,

hatte mit clonezilla 1.2.2-31 (für Karmic) sdb1 bis 7 zurückgeschrieben. Der Grub2 sitzt auf sda1 (HD 0 bzw. sda).

Kenne zwar 'Clonezilla' nicht, kann aber evtl ein paar Anregungen geben. Zunächst zum Grub: der Grub besteht aus mehreren Teilen. Ein Teil (der s.g. Grub-Bootloader) befindet sich im MBR (Master Boot Record) der Festplatte (hd0), der zweite Teil (Stage 1.5 bei Grub-Legacy) in dem Bereich bis Sektor 62 der Platte (hd0 bzw. sda). Der Rest (Stage 2, menu.lst etc.) befindet sich in der Partition (Z.B. sda1 im Verzeichnis /boot/grub).

Anschließend war Grub weg und nur windows ließ sich mit der Grub2 supergrub 1.2.1 cd booten. Ubuntu nicht!

Grub war weg ?. Gibt es irgendeine Meldung beim Booten die darauf hindeutet, z.B. 'No Bootloader found' oder bringt Grub eine Meldung ?

Kann das sein, dass es daran liegt, das Ubuntu auf einer anderen Festplatte (interne) liegt. Ubuntu an sich ist zurückgeschrieben worden, der Grub nicht. Hat jemand eine Idee?

Hängt davon ab, wie Du die vorherige Frage beantwortest. Grundsätzlich kann gesagt werden, das bei einer Partition-Erstellung und anschliessender Formatierung eine neue UUID vergeben wird. Diese UUID wird z.B. von Grub benötigt und ist in der /boot/grub/menu.lst (bei Grub) bzw. in der /boot/grub/grub.cfg (bei Grub2) anzupassen. An dieser Stelle kommt natürlich die Frage auf, wie 'Clonezilla' arbeitet: wird von Clonezilla ein Backup auf Dateisystem-Ebene oder auf Partition-Ebene (Cloning) durchgeführt ?

Beim clonen einer Partition werden auch die Partition Informationen wie UUID und Partition-Table gesichert. Zusammefassend kann bislang gesagt werden:

1.) Eine Sicherung der Partitions sda1 .. sda7 sichert nicht den MBR und die Partitiontable. (Muss extra gesichert werden !)

2.) Wichtig ist, die Eigenschaft des jeweiligen Backup/Restore Programms zu kennen. (Backup/Restore auf Datei-Ebene oder Partition-Ebene)

3.) Die Arbeit mit Grub2 setzt eine große Lernbereitschaft voraus wenn irgendwelche Dinge von Hand angepasst werden sollen. (Empfehlung: Grub-Legacy benutzen)

Hoffe ein paar Anregungen gegeben zu haben.

Gruß Topaz

Hallo topaz, @ ALL

auch Dir, wie allen Anderen, besten dank für die Mühe! Inzwischen habe ich die Ubuntu und die externe USB-Festplatte formatiert und Ubuntu neu Installiert.

1. Zum Grub: Nach der Installation kommt ja die Aktualisierungsverwaltung und will ca. 107 Dateien (oder Pakete) aktualisieren. Da kommt dann auch "Wie wollen Sie mit Grub verfahren?" Diesmal habe ich NICHT die "Version des Paketbetreuers gewählt", sondern "aktuell installierte Version behalten". Gehe ich an der Stelle auf die Hilfe kommt u.a."die installierte Version wurde verändert".

Das kann ja nur bedeuten, ich habe bei der Installation davor den Grub bereits upgedatet gehabt. Denn 1.9.7 beta 4 ist ja bereits Grub2.

Wähle ich hier die Version des Paketbetreuers, war es zumindest bei mir aus mit lustig, denn Grub2 brauchte anschließend anstelle, jetzt 9 Sekunden, 4 Minuten. Jetzt ist also alles wieder normal.

1b. Es könnte natürlich noch ein Störfaktor im Spiel gewesen sein, auf der externen USB Sicherungsfestplatte befand sich noch das komplette 1 Ubuntu 9.10 drauf (ich wollte dies ursprünglich zusätzlich bootfähig machen), das habe ich inzwischen runtergeputzt.

2. Zu clonezilla: dies kann einmal ganze Festplatten und einzelne Partitionen bzw. alle ausgewählten Partitionen. Clonezilla klont also auf Partitionsebene. Da hatte ich aber nur die Ubuntu Partitionen sdb1 bis 8 ausgewählt u. gesichert und zurückgeschrieben. Das war aber alles inzwischen auf der (USB) 3 physikalischen Festplatte. Der Grub2 befindet sich aber auf der 1 Physikalischen Festplatte. Der hätte eigentlich unversehrt bleiben müssen.

Das werde ich aber nochmals neu austesten und die Frage wäre noch, kann ich den Grub nur dann mitsichern, wenn ich die 1 Festplatte auch komplett mitsichere und zurückspiele. Das will ich im Moment noch nicht, die Windowsfestplatte mache ich zur Zeit noch extra, mit einem anderen Programm (Ghost).

Ideal wäre den Grub2 einzeln sichern und einzeln zurückspielen zu können. Das ginge mit Remastersys, aber anscheinend läuft das nicht mit der 9.10! Gibt es für den Grub2 was anderes?

(ansonsten war ich fast so weit den MBR zu fixen und wieder zurück nach Ubuntu 9.04 zu gehen.)

Gruss Ria PS:

Grub war weg ?. Gibt es irgendeine Meldung beim Booten

hmm, find die Notiz nicht mehr, irgendwas mit "no Kernel" aber keine normale Error Anzeige mit ner Nummer.

@Ria,

zu Backup/Restore gibt es Möglichkeiten wie Sand am Mehr und zu Backu-Strategien ebenso ... Man kann eigentlich immer nur Empfehlungen aus der eigenen Erfahrung geben:

1.) Backup/Restore sollte man nach Möglichkeit mit 'Bordmitteln' (Z.B. 'rsync') durchführen können.

2.) Ein Partition-Backup/Restore ist immer mit Vorsicht zu geniessen weil die Partition-Table und UUID mitkopiert werden. (Restore große auf kleine Partition o. umgekehrt, doppelte UUID's etc)

3.) Inkrementaler Backup auf Filesystembasis bringt Vorteile beim Zeitaufwand und Restore auf verschiedene Partitions (ext2,ext3 o. ext4, verschiedene Grössen etc)

Zur Grub Sicherung:

Eine komplette Sicherung der ersten 63 Sektoren der Festplatte (hd0 bzw. /dev/sda) führe ich wie folgt durch:

dd if=/dev/sda bs=512 count=63 of=/boot/sicherung/sicherung_63_sda_vom_datum

D.h. In /boot/sicherung/sicherung_63_sda1_.. befinden sich der MBR incl. Grub-Bootloader, die Partitiontable von SDA1 und der zweite Teil von Grub.

Der Restore:

dd if=/boot/sicherung/sicherung_63_sda_vom_datum bs=512 count=63 of=/dev/sda

Ferner habe ich eine eigene Boot-Partition eingerichtet (/dev/sda1) in der sich Grub-Legacy und mehrere Kernel und Initrd's für verschiedene Systeme befinden. Diese Partition wird von den verschiedenen Systemen nach /boot gemounted. Die Größe kann relativ klein gehalten werden (Muss alle Kernel, Initrd's und Grub Ordner enthalten. Dadurch ist ein Backup/Restore relativ schnell und einfach durchgeführt. Die Einträge in der Grub menu.lst pflege ich von Hand. Die 'Automaten' (Update-Grub etc.) versagen bei komplexeren Systemen. Wichtig ist nur bei Grub-Legacy, dass die 'Boot'-Partition mit ext3 formatiert ist. (Bei Grub2 geht auch ext4).

Bei Fragen zu 'rsync' (Backup/Restore) stehe ich gern zu Diensten.

Gruß Topaz

Hallo

sorry, hat alles etwas länger gedauert. Natürlich wollte ich erst mal neu testen ob die ursprünglichen Programme, also remastersys und clonezilla es jetzt tun. Eindeutiges ja!

Der Fehler von mir war, ich hatte Karmic Koala mit ext3 formatiert, die Programme waren bzw. sind deklariert für explizit Karmic Koala. Hier wird wahrscheinlich für Karmic Koala ext4 vorausgesetzt. Nachdem ich also, schweren Herzens dann doch die Neuinstallation mit ext4 vorgenommen habe, funktionieren jetzt auch die Backups!

Die Geschwindigkeit ist hoch und der Grub2 auf hd0,1 (heißt jetzt für den Grub2 nicht mehr hd0,0) wurde auch mitgesichert (beide Programme). Gibt es keine negativen Erkenntnisse, ich habe keine, dann ist der Komfort so, dass ich auf diesen ungern verzichten möchte(von klicki bunti, wäre übertrieben zu sprechen).

Zudem ist mir bei beiden Programmen sympathisch von CD aus operieren zu können, denn wenn nichts mehr geht, habe ich auch keinen Terminal mehr, den ich hier nicht brauche.

@ topaz

vilen Dank nochmals, 'rsync' stelle ich nochmals zurück. Die Einzelsicherung von Grub2 sehe ich mir trotzdem nochmal genauer an.

FRAGE AN ALLE: das Zusatztool von 'remastersys' für den Grub2 war in meinem Download nicht dabei, gibt es das nicht mehr, oder muss man dies extra downloaden und wenn ja, hat einer einen Link für Grub2 wohlgemerkt?

Gruss Ria

@Ria,

Der Fehler von mir war, ich hatte Karmic Koala mit ext3 formatiert, die Programme waren bzw. sind deklariert für explizit Karmic Koala. Hier wird wahrscheinlich für Karmic Koala ext4 vorausgesetzt. Nachdem ich also, schweren Herzens dann doch die Neuinstallation mit ext4 vorgenommen habe, funktionieren jetzt auch die Backups!

Einspruch: Kein Fehler von Dir ext3 zu benutzen. Stell dir vor, ein Backup/Restore Program entscheidet durch die Vorgabe von ext4, das Deine 'Unternehmenskritische Datensicherung' nicht auf einen System zurückgespielt werden kann wo z.B. ext3 oder ext2 oder weiss ich was installiert ist, oder wo statt 'Karmic Koala' sagen wir mal 'debian' oder 'Suse' als Betriebssystem arbeitet. Ausserdem werden z.B. bei einem Update von 9.08 nach 9.10 nicht auch zwangsläufig das Filesystem ext4 benutzt.

Die Geschwindigkeit ist hoch und der Grub2 auf hd0,1 (heißt jetzt für den Grub2 nicht mehr hd0,0) wurde auch mitgesichert (beide Programme). Gibt es keine negativen Erkenntnisse, ich habe keine, dann ist der Komfort so, dass ich auf diesen ungern verzichten möchte(von klicki bunti, wäre übertrieben zu sprechen).

Akteptiert: Aber bitte dran denken, dass Grub auch auf hd0 liegt und warscheinlich extra gesichert werden muss.

Gruß Topaz