Backup bootet nicht (erstellt mit dd)

L I V E Stammtisch ab 20:30 Uhr im Chat
  • Guten Tag zusammen,

    ich betreibe mittlerweile einige Pis, komme jetzt aber bei einem banalen Problem einfach nicht weiter.

    Ich habe ein Image, welches ich auf verschiedenen Raspberrys verteilen muss. Das Betriebssystem wurde vorher per gparted etwas verkleinert um Platz zu sparen (5GB). Bei Ausführung von dd habe ich es extra etwas weiter gefasst:

    Code
    sudo dd if=/dev/sdb of=/home/pi/backup/backup.img bs=1M count=6144

    Nach meinem Verständnis müsste das also ausreichen? Das Backup wurde ebenfalls auf einem Raspberry mit folgendem Kartenlesegerät erstellt: Transcend All-in-1 Multi Kartenlesegerät [Anzeige].

    Die Installation erfolgte so:

    Code
    sudo dd if=/home/pi/backup/backup.img of=/dev/sdb bs=1M

    .

    Die neu erstellte Karte funktioniert dann am selben Pi nicht. Beide LED leuchten permanent, was wohl auf einen Boot-Fehler hindeutet.

    Die SD-Karte (SanDisk Ultra microSDHC 16GB [Anzeige]) funktioniert ebenfalls mit einer jungfräulichen Distribution, ist also selbst auch nicht defekt.

    Einziger Unterschied: Installation über Notebook über internen Kartenleser unter Verwendung von Win32DiskImager. Der ist ja allerdings unbrauchbar, da ja immer nur die gesamte SD-Karte als Image ausgelesen werden kann und bekanntlich nicht alle SD-Karten gleich groß sind.

    Gibt es noch andere Möglichkeiten, ein reduziertes Image zu erstellen, bzw. was mache ich falsch? Wäre für Hilfe sehr dankbar.

    Beste Grüße
    AXEL

  • Hi,
    Du kannst nicht einfach nur einen Teil des Image verwenden und annehmen, dass Du "schon alles erwischen wirst".
    Das Image beinhaltet das Filesystem und wie dieses aufgebaut ist bzw. was davon wo auf der SD-Karte steht, weisst Du nicht. Das ist lediglich Spekulation.
    Nimm mal die Forensuche zu Hilfe ... das Thema mit Verkleinern des Image wurde schon ausführlich behandelt.
    cu,
    -ds-

  • Vielen Dank für den Anhaltspunkt. An der Stelle habe ich nicht das Problem gesehen. Ich werde bei der Verkleinerung ansetzen.

    EDIT: Ich habe mir jetzt die Anleitung durchgelesen. Genau das waren meine Schritte außer

    Code
    sfill -z -l -l -f /mnt

    Ich würde gerne verstehen, wieso das die Probleme löst. Muss dd dabei genau das Ende der ext4-Partition erfassen, oder kann man es zur Sicherheit auch ein paar 100MB größer halten?

    Danke nochmals
    AXEL

    Einmal editiert, zuletzt von AxelRHD (10. Dezember 2014 um 21:44)

  • Hi,
    ich hab' mir das jetzt nicht durchgelesen ... Du hast aber die Infos aus -> diesem <- Link des Beitrags mit einbezogen, oder?
    Der sfill ist imho nur dazu da, um den leeren Bereich mit Nullen zu füllen. Dadadurch wird das komprimierte Image kleiner.

    Ich versuch's mal mit meinen Worten zu umschreiben:
    dd (disk dump) liest einen Datenträger Byte für Byte und schreibt ihn dann z.B. in eine Datei. dabei handelt es sich um eine physikalische Kopie. Das bedeutet, dass Dateisystem-Strukturen wie Verwaltungsdaten, Belegungstabellen, Partitions-Informationen, Bootcodes, Journale, ... mit kopiert werden.
    Im Gegensatz dazu machst Du z.B. mit tar eine logische Kopie, die lediglich die Daten und die dem Benutzer sichtbare Verzeichnis-Hirarchie beinhaltet. Eine logische Kopie ist deshalb auch immer kleiner als die physikalische Kopie und kann problemlos auch partiell wieder restauriert werden.

    Da ein physikalisches Image eine in sich geschlossene Einheit darstellt, kannst Du sie nicht einfach irgendwo auseinanderhacken oder, ohne Hilfswerkzeuge, nur Teile daraus rekonstruieren.
    Und das ist genau das Problem bei der physikalischen Kopie. Da die Datenträger oft unterschiedlich groß sind, und seien es nur einige Byte, kann nicht das gesamte Abbild auf eine andere, "fast" gleichgroße Karte geschrieben werden, und Filesystem und/oder Partition darauf sind korrupt.

    Nun kann man aber mit enteprechenden Tools (z.B. gparted) eine Partition verkleinern und mit einem resize2fs das Filesystem darauf an die neue Grösse anpassen. Das funktioniert aber nur dann fehlerfrei, wenn am "Ende" des Datenträgers keine Daten abgelegt sind.
    Dann, und nur dann, wenn das Dateisystem angepasst wurde, kannst Du mit dd einen Teil des Datenträgers als vollwertiges Image sichern. Dazu benötigst Du den letzten belegten Block der Partition, den Du mit z.B. fdisk ermitteln kannst.
    Dieser Block plus 1 ist die Anzahl der 512-Byte Blöcke, die Du als Image sichern musst.
    Beispiel: fdisk zeigt für eine SD-Karte als größten End-Block die Nr. 39999 an. Dann lautet das Kommando zum sichern des Image:
    dd if=/dev/SDKARTE of=./Imagedatei bs=512 count=40000
    Somit wird das gesamte Dateisystem der Karte gesichert und ist damit auf eine andere übertragbar und gültig.

    Ist es nicht möglich, die Partition ohne Datenverlust zu verkleinern, dann musst Du versuchen den Umweg über eine logische Kopie zu gehen.
    Dazu erstellst Du eine Daten-Sicherung der gesamten SD-Karte. Anschliessend nimmst Du eine kleinere, leere und erstellst die benötigten Partionen darauf. Schliesslich must Du noch die Daten auf die kleinere Karte restaurieren. Jetzt Karte testen und, falls alles funktioniert, von dieser kleineren Karte ein Image erstellen.

    Das Ganze geht auch über eine Datei, in der Du die Partitionen resp. Filesysteme anlegst. Aber das würde den Rahmen sprengen.
    Ausserdem habe ich schon einen Krampf im Finger ;) ...

    Alles klar so weit?

    cheers,
    -ds-

  • Besten Dank! Ich habe es jetzt größtenteils verstanden und werde es morgen nochmals testen.

    Aber ich dachte, bei gparted werden die Filesystem-Informationen ebenfalls geändert? Der Knackpunkt liegt also bei der genauen Festlegung des counts bei dd.

    Einmal editiert, zuletzt von AxelRHD (10. Dezember 2014 um 22:59)

  • Hi,
    ne ... das Verändern der Partition verändert nichts am drunter liegenden Filesystem. Genau das ist ja der Grund, warum das "abhacken" nicht funktioniert.
    Erst durch das resize2fs wird das Filesystem selbst repariert ... also an die neue Größe angepasst.
    Und nachdem dann eben der Teil mit dem gültigen Filesystem ausreicht, ist der magic count eben die Anzahl der 512 Byte Blöcke.

    cu,
    -ds-

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!