Hanooq
Anmeldungsdatum: 19. April 2015
Beiträge: Zähle...
|
Ich hab grad mein System irgendwie festgefahren und komme nicht weiter. Ich habe das System aufgesetzt, alles eingerichtet und wollte jetzt 2 Sicherungen der Systemplatte machen. Dazu bin ich wie folgt vorgegangen: Sicherungsplatte 1 eingebaut und per Live CD gestartet dd Runterfahren Sicherungsplatte 1 ausgebaut und Sicherungsplatte 2 eingebaut und per Live CD gestartet dd Runterfahren und Sicherungsplatte 2 ausgebaut und in den Schrank Systemplatte ausgebaut und Sicherungsplatte 1 eingebaut Bootvorgang ganz normal durchgelaufen, ich war drin. Einen neuen Benutzer auf dem System angelegt und herunter gefahren Systemplatte an seinen Platz eingebaut, die Sicherungsplatte 1 aber eingebaut gelassen Als Boot Device die ursprüngliche Systemplatte angegeben und die Sicherungsplatte 1 als 2. Boot Device Bootvorgang lief normal durch, allerdings war ich in dem System von Sicherungsplatte 1 !! Also runterfahren und Sicherungsplatte 1 ausbauen. Boot Device nochmal checken und Boot von ursprünglicher Systemplatte. Fehlgeschlagen Systemplatte raus und Sicherungsplatte 1 rein und als Boot Device angegeben. Boot: fehlgeschlagen Sicherungsplatte 2 aus Schrank geholt und eingebaut. Boot Device gecheckt und Boot: fehlgeschlagen
Bitte diskutiert nicht über Sinn und Unsinn meines Vorgehens. Bin blutiger Anfänger und mache meine ersten Gehversuche mit Linux. Kann ich das System nochmal retten oder ist es nachhaltig geschrottet? Happy-Reinstall-Party ? ☹
|
tomtomtom
Supporter
Anmeldungsdatum: 22. August 2008
Beiträge: 53610
Wohnort: Berlin
|
dd hat ja gerüchteweise mehr als eine Option, genutzt zu werden. Es wäre also äußerst informativ, wenn du konkret sagen würdest, was du getan hast.
|
Hanooq
(Themenstarter)
Anmeldungsdatum: 19. April 2015
Beiträge: 12
|
Ich habe erst per fdisk geguckt, welche Platte die Systemplatte ist und welche die Sicherungsplatte. (war anhand der Größe leicht zu erkennen) dann sudo dd if=/dev/sdd of=/dev/sde bs=1M wobei sdd Systemplatte und sde die Sicherungsplatte war. Edit:
fehlgeschlagener Boot heißt: no boot device.... Edit2:
Da ich es jetzt nicht noch schlimmer machen will, frag ich lieber vor Experimenten. Könnte das hier zielführend sein?
http://ubuntuforums.org/showthread.php?t=1641020&p=10216097#post10216097
|
engheneiro
Anmeldungsdatum: 13. August 2009
Beiträge: 2079
Wohnort: Nähe München
|
Hi, das ist sehr wahrscheinlich die richtige Spur. dd clont die ganze Disk oder Partition inklusive der UUID. Somit hast du doppelte UUID wenn beide Disks gleichzeitig im System sind.
Die Lösung ist eine der UUIDs zu ändern (dann aber auch in der /etc/fstab anpassen) oder immer nur eine Disk im System aktiv zu haben. Wenn du "nur" regelmäßige Sicherungen machen möchtest, eignet sich ein anderes Tool (z.B. rsync) besser als dd dafür. Gruss
Rainer
|
Hanooq
(Themenstarter)
Anmeldungsdatum: 19. April 2015
Beiträge: 12
|
Also ich hatte beide Platten dran und konnte 1 mal booten. Danach ging nichts mehr.
Auch wenn jetzt nur 1 Platte angeschlossen ist, bootet sie nicht. Wurde die UUID der Platte irgendwie gelöscht oder was ist da passiert?
Ich würde gern verstehen, was genau da jetzt schief gelaufen ist, damit meine Lösungsversuche keine Schüsse ins Blaue sind. Meinst du ich soll das Vorgehen des unter dem Link genannten Beitrags einfach mal mit einer Platte versuchen? Mein ursprüngliches Ziel war übrigens: 1 Platte mit einem stabilen lauffähigen System im Schrank als Notfallplan.
1 Platte als Testsystem im Rechner, auf dem ich dann verschiedene kompliziertere Sachen versuche zu installieren, bevor ich es auf dem Live System mache.
Ich habe mir noch keine VM aufgesetzt und fand den Weg mit den 2 Platten jetzt erstmal leichter. (oh welch Irrtum)
|
tomtomtom
Supporter
Anmeldungsdatum: 22. August 2008
Beiträge: 53610
Wohnort: Berlin
|
Starte doch mal mit beiden angeschlossenen Platte von einer Live-CD oder einem Live-USB-Stick und poste hier die Terminal-Ausgabe von sudo lsblk -o NAME,UUID,LABEL,FSTYPE im Codeblock.
|
Hanooq
(Themenstarter)
Anmeldungsdatum: 19. April 2015
Beiträge: 12
|
sda und sdb sind USB Sticks. sdf, sdg, sdh, sdi sind die Datenspeicher. Was loop0 ist, weiss ich noch nicht. sdd und sde werden dann die geklonten Platten sein.
Allerdings frage ich mich, warum die nicht exakt identisch sind. Die Platte sollte eigentlich so aussehen wie sde 1 primäre Partition als Boot. 1 primäre Partition, die swap und root enthält. ubuntu@ubuntu:~$ sudo lsblk -o NAME,UUID,LABEL,FSTYPE
NAME UUID LABEL FSTYPE
sda 2014-10-22-19-43-11-00 Ubuntu 14.10 amd64 iso9660
├─sda1 2014-10-22-19-43-11-00 Ubuntu 14.10 amd64 iso9660
└─sda2 CB17-BBAD vfat
sdb
└─sdb1 6B02A9597B610FE5 Pacers ntfs
sdd
├─sdd1 2cb5a22d-73dd-4940-bfe0-53fa78cd8137 ext4
└─sdd2 k3D6Pf-CRsF-Zuhs-If8i-6dKf-IG8P-skGQss LVM2_member
sde
├─sde1 2cb5a22d-73dd-4940-bfe0-53fa78cd8137 ext4
└─sde2 k3D6Pf-CRsF-Zuhs-If8i-6dKf-IG8P-skGQss LVM2_member
├─system-swap
└─system-root
986bed37-e713-43fc-916f-25c52d42e416 crypto_LUKS
sdf
└─sdf1 09ce0922-ff9d-d714-8f04-a0708733029e homeserver:0 linux_raid_memb
sdg
└─sdg1 09ce0922-ff9d-d714-8f04-a0708733029e homeserver:0 linux_raid_memb
sdh
└─sdh1 09ce0922-ff9d-d714-8f04-a0708733029e homeserver:0 linux_raid_memb
sdi
└─sdi1 09ce0922-ff9d-d714-8f04-a0708733029e homeserver:0 linux_raid_memb
loop0 Bei der Installation habe ich mich grob an diese Anleitung gehalten. (Den Teil mit dem RAID habe ich an meine Bedürfnisse angepasst)
http://www.itfromscratch.com/install-ubuntu-server-12-04-with-encrypted-lvm-on-raid1/
|
engheneiro
Anmeldungsdatum: 13. August 2009
Beiträge: 2079
Wohnort: Nähe München
|
sdd und sde werden dann die geklonten Platten sein. Allerdings frage ich mich, warum die nicht exakt identisch sind.
da kann ich auch nur spekulieren. Jedenfalls sind die UUIDs identisch. Das macht sicher Probleme. Das System mounted wahrscheinlich die es zuerst findet. Wenn die Disks nicht exakt identisch groß sind (gleicher Typ) und vorher schon was darauf gespeichert war, dann kann das schon sein dass "hinten" noch Reste einer alten Installation drauf sind.
|
Hanooq
(Themenstarter)
Anmeldungsdatum: 19. April 2015
Beiträge: 12
|
Das System bootet ja gar nicht erst. Es kommt direkt die Meldung, dass keine Systemplatte gefunden wurde. Und die Meldung kommt, egal welche Platte ich angeschlossen habe. (Also auch, wenn nur 1 Platte dran hängt) Die Systemplatte ist eine SSD 120 GB und die Sicherungsplatte eine HDD 320GB, frisch formatiert, bevor ich mit dd gearbeitet habe.
|
engheneiro
Anmeldungsdatum: 13. August 2009
Beiträge: 2079
Wohnort: Nähe München
|
Die Systemplatte ist eine SSD 120 GB und die Sicherungsplatte eine HDD 320GB, frisch formatiert, bevor ich mit dd gearbeitet habe.
Also in der Konstellation würde ich in gar keinem Fall mit dd arbeiten. Bei Ubuntu brauchst du auch kein bitweises Kopieren der Sytemdisk. Ein "einfacher" Kopiervorgang reicht völlig aus. Z.B. wie im Wiki unter System umziehen beschrieben. (http://wiki.ubuntuusers.de/Ubuntu_umziehen) Ich würde jetzt an deiner Stelle die HDD abziehen, das System von einer Live-CD oder USB Stick booten und dann das Filesystem der SSD prüfen lassen (fsck). Bei der doppelten UUID kann das System auch (worst case) inkonsistent geschrieben (evtl. sogar kaputtgeschrieben) worden sein, wenn beide Disks gleichzeitig an waren. Dann solltest du die Eiträge in der /etc/fstab prüfen, ob die richtige Disk fürs Booten drinsteht. Evtl. muss auch der Bootloader (Grub) neu eingerichtet werden. Wenn du sowieso erst neu aufgesetzt hast, wäre ggf. ein neu installieren zu überlegen. HTH Rainer
|
Hanooq
(Themenstarter)
Anmeldungsdatum: 19. April 2015
Beiträge: 12
|
Danke für den rsync Hinweis. Ich werde das dann so lösen. Dann kann ich auch beide Platten angeklemmt lassen, weil sich die UUID dann ja unterscheiden. Aber jetzt muss ich das System erstmal wieder ans Laufen bekommen ☺ Eine Neuinstallation würde ich gerne vermeiden. Ist zwar grad erst frisch aufgesetzt, aber es war ne Menge Arbeit. Ich habe die HDD jetzt wieder abgeklemmt und wollte eigentlich vom Stick starten, bin aber nicht ins Boot Menu rein. Jetzt hat das Ding ganz normal von der SSD gebootet, als wäre nichts gewesen. Was soll das denn jetzt ?!?
Das macht doch absolut keinen Sinn. Gibt es irgendwas, was ich jetzt im laufenden Betrieb des Servers machen kann, um sicherzustellen, dass das Teil jetzt wieder richtig läuft?
Nicht dass ich den gleich rebooten will und es wieder nicht geht. Ich werde jetzt erstmal fsck laufen lassen. (Edit: Ich Scherzkeks, geht ja nur, wenn die Platte nicht in Gebrauch ist)
|
Hanooq
(Themenstarter)
Anmeldungsdatum: 19. April 2015
Beiträge: 12
|
Also mehrfaches Rebooten der ursprünglichen Platte funktioniert. Beide anderen Platten tun aber immernoch nichts. Die werde ich jetzt mal formatieren und dann versuchen wie von Rainer empfohlen per rsync zu beschreiben. Danke für eure hinweise, Zeit und Tipps, auch wenn ich immernoch nicht weiss, was hier schief gelaufen ist.
|
engheneiro
Anmeldungsdatum: 13. August 2009
Beiträge: 2079
Wohnort: Nähe München
|
Die werde ich jetzt mal formatieren
Formatieren bzw. neues Filesystem erzeugen reicht nicht. Die UUID wird erst beim Löschen und Neuanlegen der Partition geändert (oder manuell durch Tool tune2fs - Siehe http://wiki.ubuntuusers.de/UUID) Viel Erfolg, Rainer
|
Hanooq
(Themenstarter)
Anmeldungsdatum: 19. April 2015
Beiträge: 12
|
Genau an dem Punkt hänge ich jetzt ☺ Ich habe jetzt die Platte erneut geklont und kann nun von der SSD sowie der HDD booten, wenn sie einzeln angesteckt sind.
Jetzt wollte ich bei der HDD die UUIDs ändern, sie dann als Testsystem parallel nutzen, und in regelmäßigen Abständen per rsync die Systempartition kopieren. Aber ich bekomme die UUID nicht geändert. tune2fs hat bei der ersten Partition (z.B. in dem Output oben sde1) funktioniert.
Bei der zweiten (sde2) kommt aber ein magic number Fehler. Wahrscheinlich weil es sich hier um ein LVM handelt?
Ich weiss auch nicht, wie ich an das crypto_LUKS system_root dran komme (oben auch unter sde2 zu sehen). Das msus ich ja auch ändern. Hast du hierfür noch einen Tipp für mich?
|
engheneiro
Anmeldungsdatum: 13. August 2009
Beiträge: 2079
Wohnort: Nähe München
|
Hallo nochmal, nein, von crypto-Disks und LVM habe ich bisher die Finger gelassen und deshalb keine Erfahrungen 😉 Da musss jemand anders ran. Das eine "U" in UUID steht für "uniqe" - es ist schlicht keine gute Idee, 2 Disks mit der gleichen UUID zu haben. Zum alternativen Booten von der 2. Disk würde ich bei Bedarf einfach den Eintrag in der /etc/fstab ändern (bzw. schon mal den Eintrag für / vorbereiten und auskommentieren). Umständlich ist das schon - geb ich zu. Ich habe bei meinem System auch mal ein ähnliches Setup vor gehabt, habe es aber dann letztlich nicht durchgehalten, regelmäßge Kopien zu machen. Im Moment lebe ich mit Backups und trenne meine Daten ganz klar vom System. Das System ist dann notfalls austauschbar - die wichtigen Konfig-Dateien sind gesichert. Gruss
Rainer
|