Systemplatte auf kleinere Platte klonen

  • Hallo zusammen,


    das System meines neuen VDRs habe ich zuerst, da die endgueltige Hardware noch nicht da war, auf eine 300GB 3.5" SATA Platte installiert. Gestern kam dann die endgueltige Hardware, eine 60GB 2.5" SATA Platte.


    In meinem (nicht mehr ganz) jugendlichen Leichtsinn dachte ich, dass Thema mit einer beliebigen Diskimagesoftware (beispielsweise Ghost, Acronis TrueImage etc...) in Windeseile erledigt ist. Ja, die Frustration war gross. Keines der mir zur Verfuegung stehenden Programme konnte eine ext3 und/oder swap Partition verkleinern.


    Setup (Standardoptionen beim Setup von Debian 5.0 lenny amd64):
    sda1: ~294GB ext3 (Primaer)
    sda5: ~6GB swap (Logisch)


    Also im Internet belesen und gemacht und getan. Letztenendes mit Knoppix gebootet, Partitionen wie oben, nur kleiner angelegt, mit mkswap und mke2fs initialisiert bzw formatiert und mit rsync -avHx --delete /mnt/sdb1/ /mnt/sda1 (alte Partition ist sdb1, neue Partiton ist sda1) alle Daten kopiert. Dann noch ein grub-install --root-directory=/mnt/sda1 /dev/sda hinterher.


    Soweit so gut. Gebootet, grub da, alle Auswahlmoeglichkeiten wie auf der alten Platte.


    Leider bootet die Platte im read-only Modus, egal mit welchem Kernel, keine Ahnung, warum. Die Eintrage in der menu.lst sehen auf jeden Fall unveraendert aus. Verstehe das nicht! :(


    Hat da jemand spontan ne Idee?


    Viele Gruesse,
    Martin

    Hardware: Intel E5300, Gigabyte GA-EP41-UD3L, 4GB DDR2-RAM, 60GB 2.5" System, 3TB 3.5" Daten, L4M Cine S2 V6.5 DuoFlex S2 V4, Samsung 46" LED-LCD TV
    Software: yaVDR mit diversen Plugins und XBMC
    Ambilight: SEDU Board, 112 * WS2801 LEDs, boblight/vdr-plugin-seduatmo


    Pro-Taucher - Tauchplätze weltweit

  • hallo...


    also eine konkrete lösung habe ich momentan nicht parat...


    allerdings meine klonierereien habe ich bis jetzt immer mit einer clonezilla cd erledigt und bis jetzt noch nie probleme damit gehabt.


    soweit ich weiß, kann clonezilla auch die partitionsgrößen verändern. obs mit verkleinern funktioniert, kann ich nicht sagen...


    aber vielleicht is es mal ein versuch wert


    grüße peter

    Mein VDR
    Hardware: Athlon64 X2 3800+, 1GB RAM, MB: Gigabyte GA-M61P-S2, 1x HDD Seagate Barracuda (ST3500418AS) 500GB , 1x Nova T DVB-T, 2x TT S-1401 DVB-S, 1x TT S2300, LG GSA-H42N Brenner, Silverstone Crown SST-CW01S-R silber Gehäuse
    Software: yavdr

  • Hallo Peter!


    Quote

    Originally posted by pez3
    allerdings meine klonierereien habe ich bis jetzt immer mit einer clonezilla cd erledigt und bis jetzt noch nie probleme damit gehabt.


    soweit ich weiß, kann clonezilla auch die partitionsgrößen verändern. obs mit verkleinern funktioniert, kann ich nicht sagen...


    Leider kann CloneZilla nicht verkleinern. Auf das Tool, das mir bisher unbekannt war, bin ich gestern auch gestossen nach meiner Suche im Netz. Leider steht das direkt explizit auf deren Webseite, dass Verkleinerungen z.Zt. (noch) nicht moeglich sind. Die zu klonenden Partitionen muessen genau so gross oder kleiner als die Ziele sein.


    Viele Gruesse,
    Martin

    Hardware: Intel E5300, Gigabyte GA-EP41-UD3L, 4GB DDR2-RAM, 60GB 2.5" System, 3TB 3.5" Daten, L4M Cine S2 V6.5 DuoFlex S2 V4, Samsung 46" LED-LCD TV
    Software: yaVDR mit diversen Plugins und XBMC
    Ambilight: SEDU Board, 112 * WS2801 LEDs, boblight/vdr-plugin-seduatmo


    Pro-Taucher - Tauchplätze weltweit

  • Was steht den in der fstab. Beim booten wird immer erst ro gebootet erst durch die inet scripte wird dann die root partition rw gemountet nach dem zuvor eventuell fsck lief. Wenn in der fstab die root partition mit uid oder über ein Label angegeben ist und nicht über /dev/sda1 wird die root partition nicht rw gemountet.

  • hallo martin,


    mit


    resize2fs -M /dev/sda1


    kannst du die Partition auf ein Minimum verkleinern.


    Dann sollte auch das kopieren auf die 60GB Platte kein Problem mehr sein.


    Grüße, Wolfgang


    Server:
    Hw: Xeon , 16 GB Ram, VMware 6.5, DD Cine S2 V6.5 + 7A
    Sw: yavdr 0.5 + 0.6.1

    Clients:
    5 x Raspberry Pi (VompClient)

    The post was edited 1 time, last by kowo ().

  • Quote

    Originally posted by swer
    Was steht den in der fstab. Beim booten wird immer erst ro gebootet erst durch die inet scripte wird dann die root partition rw gemountet nach dem zuvor eventuell fsck lief. Wenn in der fstab die root partition mit uid oder über ein Label angegeben ist und nicht über /dev/sda1 wird die root partition nicht rw gemountet.


    Also die fstab schaut unauffaellig (und altmodisch) aus:


    Code
    1. # <file system> <mount point> <type> <options> <dump> <pass>
    2. proc /proc proc defaults 0 0
    3. /dev/sda1 / ext3 defaults,noatime,data=writeback,acl 0 1
    4. /dev/sda5 none swap sw 0 0
    5. /dev/sdb1 /var/lib/video.01 ext3 defaults,noatime,data=writeback,acl 0 2
    6. /dev/hda /media/cdrom0 udf,iso9660 user,noauto 0 0


    Daran scheint es also auch nicht gelegen zu haben... :-/



    Ja, diesen Befehl habe ich gestern auch entdeckt. Habe nicht weiter recherchiert, z.B. wie man dann nachher die Partition wieder "aufblaest", denn ich scheue mich irgendwie noch davor, die Originaldaten anzufassen... ;)


    Zum heulen, es kann doch verdammt noch mal nicht so schwer sein, ein Linuxsystem zu klonen oder ne Partition zu verkleinern?!? Mit FAT(32) und NTFS ist das alles doch kein Problem, warum ist das mit ext3 so ein Act? Die o.g. Imagetools zeigen ja nichtmal Infos ueber die ext3 Partition an, also z.B. wieviel Platz belegt ist und so weiter... Scheint den Programmen ein Buch mit sieben Siegeln zu sein. *gnarf*


    Viele Gruesse,
    Martin

    Hardware: Intel E5300, Gigabyte GA-EP41-UD3L, 4GB DDR2-RAM, 60GB 2.5" System, 3TB 3.5" Daten, L4M Cine S2 V6.5 DuoFlex S2 V4, Samsung 46" LED-LCD TV
    Software: yaVDR mit diversen Plugins und XBMC
    Ambilight: SEDU Board, 112 * WS2801 LEDs, boblight/vdr-plugin-seduatmo


    Pro-Taucher - Tauchplätze weltweit

  • Ja mit der fstab kann der Fehler an den ich dachte nicht auftreten.
    Ja mit resize2fs kann man das Datei-System schrumpfen und anschließen auch wieder auf das maximum aufblasen. Dazu braucht man nur resize2fs /dev/sdxy ohne einen weiter Parameter. Je nach Dateisystem und Kernel kann man das vergrößern auch online durch führen.
    Trotzdem bin ich ein Freund davon Linux Systeme auf Dateiebene zu Klonen. Man ist viel flexibler so kann man leicht von einem singel Drive System zu einem Raid oder LVM wechseln oder einzelne Verzeichnisse auf andere Partitionen legen oder das Dateisystem ändern. Sicher sind das dann keine 100% Klone.


    Auch wenn ich biss Dato dieses nur mit tar oder rdiff-backup gemacht habe ist der von dir verwendete rsync Befehl nicht ungeeignet. Auch wenn Unterumständen eine paar Berechtigungen (acls und xattrs) auf der Strecke geblieben sind.


    Gibt denn dein System eine Meldung aus warum es das Root Feilsystem nicht rw mountet. Was passiert wenn du versuchst nach dem das System gebootet hat selber ein remount durch zu führen.

  • Quote

    Originally posted by swer
    Trotzdem bin ich ein Freund davon Linux Systeme auf Dateiebene zu Klonen. Man ist viel flexibler so kann man leicht von einem singel Drive System zu einem Raid oder LVM wechseln oder einzelne Verzeichnisse auf andere Partitionen legen oder das Dateisystem ändern. Sicher sind das dann keine 100% Klone.


    Ich habe schon mehrfach ein Linuxsystem im Internet (Rootserver) mit Tarballs erfolgreich geclont. Ich dachte halt nur, dass ich um diesen Stress rumkomme. Aber anscheinend denke ich zu einfach und erwarte zu viel von ext3 bzw den Imagetools.


    Quote

    Originally posted by swer
    Auch wenn ich biss Dato dieses nur mit tar oder rdiff-backup gemacht habe ist der von dir verwendete rsync Befehl nicht ungeeignet. Auch wenn Unterumständen eine paar Berechtigungen (acls und xattrs) auf der Strecke geblieben sind.


    Anscheinend bleibt etwas auf der Strecke. Wird mir also nichts anderes uebrig zu bleiben als meinen tar-Befehl auszupacken und das System mit einem Tarball zu klonen.


    Quote

    Originally posted by swer
    Gibt denn dein System eine Meldung aus warum es das Root Feilsystem nicht rw mountet. Was passiert wenn du versuchst nach dem das System gebootet hat selber ein remount durch zu führen.


    Geht problemlos, nach Boot und Logon die Systemplatte writeable zu remounten. Habe dann neben dem grub-install auch ein update-grub durchgefuehrt (manche, die ihr System per rsync geklont haben, schrieben, dass dies auch noetig sein), hat aber nichts gebracht.


    Bezueglich rsync habe ich mich uebrigens dem Befehl aus diesem Howto bedient. Vorher waere ich nicht auf die Idee gekommen, dass per rsync machen zu koennen und hatte eben die umstaendliche Art und Weise des Tarballs vor Augen.


    Und bevor ich nun noch mehr Zeit verschwende wollte ich das Problem erst einmal hier diskutieren. VDR laeuft ja und die 2.5" Platte kann auch 1-2 Tage spaeter in Betrieb gehen.


    Viele Gruesse,
    Martin

    Hardware: Intel E5300, Gigabyte GA-EP41-UD3L, 4GB DDR2-RAM, 60GB 2.5" System, 3TB 3.5" Daten, L4M Cine S2 V6.5 DuoFlex S2 V4, Samsung 46" LED-LCD TV
    Software: yaVDR mit diversen Plugins und XBMC
    Ambilight: SEDU Board, 112 * WS2801 LEDs, boblight/vdr-plugin-seduatmo


    Pro-Taucher - Tauchplätze weltweit

  • Ich muss ja zugeben das ich kaum Debian Erfahrungen habe. Ich bin nie wirklich grün damit geworden.
    Aber dennoch kann ich mir nicht vorstellen das Fehlende acls und xattrs dazu füren as das Root Filesystem nicht rw gemountet wird. Auch wenn in der fstab explizit acl für das Root Filesystem aktiviert wurde.


    Ich habe oft genug mit einem simplen "cp -a" ein System kopiert auch wenn ich meist "cd $QUELLE && tar -cf - * | tar -xf - -C $ZIEL" verwende. Beides verdient nicht die Bezeichnung kompliziert. Aber ich muss zugeben das ich mir nie um acls und xattrs Gedanken gemacht habe. Und wenn ich mir die Manpage von rsync anschaue diese bei dem von dir verwendeten Befehl nicht Berücksichtigen wird.


    Giebt es den wirklich kein hinwies beim booten warum das root Filesystem nicht rw gemountet wird?


    Da ich bei anderen Distributionen die Erfahrung gemacht habe das das der boot Prozess nicht durchläuft mit einem ro Root. Zu Mindestens nicht ohne User-Eingabe viel diverse demons keine Dateien in /var oder /tmp erzeugen können. Und du ja auch keine separaten Dateisysteme für diese verwendest wird mir Debian immer suspekter.

  • Quote

    Originally posted by swer
    Giebt es den wirklich kein hinwies beim booten warum das root Filesystem nicht rw gemountet wird?


    So schnell kann ich nicht gucken und die Pause-Taste auf dem Keyboard funktioniert ja nur waehrend dem BIOS. ;)


    Ich sehe lediglich die vielen Fehlermeldungen, dass er dies und jenes nicht anlegen kann (z.B. pid-Dateien) weil read-only. Mit Shift + Bild-hoch kann ich ja hochblaettern, aber leider nicht weit genug...


    Ich denke, ich versuche es dann mal mit nem Tarball. Das sollte auch noch recht einfach gehen. Und was remote ueber das Rescue-System im Internet geht, sollte auch lokal von ner Knoppix-Console aus gehen.


    Viele Gruesse,
    Martin

    Hardware: Intel E5300, Gigabyte GA-EP41-UD3L, 4GB DDR2-RAM, 60GB 2.5" System, 3TB 3.5" Daten, L4M Cine S2 V6.5 DuoFlex S2 V4, Samsung 46" LED-LCD TV
    Software: yaVDR mit diversen Plugins und XBMC
    Ambilight: SEDU Board, 112 * WS2801 LEDs, boblight/vdr-plugin-seduatmo


    Pro-Taucher - Tauchplätze weltweit

  • Ein grund mehr warum ich mir in naher Zukunft Debian und seien ableger nicht genauer anschauen werde.

    Quote

    Ich sehe lediglich die vielen Fehlermeldungen, dass er dies und jenes nicht anlegen kann (z.B. pid-Dateien) weil read-only. Mit Shift + Bild-hoch kann ich ja hoch blättern, aber leider nicht weit genug...


    Wie ich bereits geschrieben habe Booten meine favorisierten Distributionen in dem Fall nicht einfach weiter. Oder der scrollback buffer hat immer gereicht, das weis ich nicht mehr so genau.
    Ich denke das man den mit der richtigen Optionen für den Kernel sicher den scrollback buffer erweitern kann.
    Aber sag Bescheid wen du es mit tar geschafft hast

  • Yohoo!


    Wie sieht den die /boot/menu.lst (oder /boot/grub/menu.lst) aus? Mein erster Gedanke war auch die /etc/fstab, aber die scheint i.O. zu sein.


    Kannst Du Dich denn ans System anmelden? Oder geht garnichts? Wenn es geht, kannst Du doch die Meldungen via "dmesg" nachvollziehen....

    Glotze: yaVDR (ASRock Q1900M, 4GB RAM, DD Cine S2 V6.5, ZOTAC GT630 (Rev. 2)
    Server: HP ProLiant MicroServer G8, VMware ESXi 5.5 :P

  • anmeden wird wohl gehen da er ja händisch das root Filesystem rw mounten kann!


    Mir ist aber gerade der Gedanke gekommen das mit rsync vielleicht die Einträge unter /dev nicht richtig erzeugt wurden.
    Da er ja nach dem gebootet wurde und udev seine Arbeit getan hat er das Root Filesystem rw mounten kann halte ich es für möglich das die Einträge für sda oder sda1 nicht richtig kopiert wurde, und erst verwendet werden können nach dem udev angefangen hat zu arbeiten.
    Das könnte man fixen indem mannach dem Boot Prozess das root Filesystem rw mountet und dann mit der optione --bind an andere stelle erneut einbindet und anschließend mit cp -a /dev/* auf das Root Filesystem schreibt.

  • Quote

    Originally posted by swer
    anmeden wird wohl gehen da er ja händisch das root Filesystem rw mounten kann!


    Ach, haendisch geht? Dann gerade die menu.lst. Wenn der Kernel naemlich sein /-Device via Grub Kernel-Bootparameter (root=UUID=....) bekommt, versucht er genau das zu mounten, nicht das, was in der fstab steht (kann ja noch nicht, da nicht gemounted!)....obwohl, sollte dann nicht ein "root-device not found" kommen? :schiel


    Quote

    Mir ist aber gerade der Gedanke gekommen das mit rsync vielleicht die Einträge unter /dev nicht richtig erzeugt wurden.


    Koennte auch sein. Aber Dein System war ja zum Zeitpunkt von rsync garnicht gebooted- da duerfte das kein Problem sein.


    Ich tippe immer noch auf menu.lst. Und melde Dich mal an udn mach "dmesg|less"

    Glotze: yaVDR (ASRock Q1900M, 4GB RAM, DD Cine S2 V6.5, ZOTAC GT630 (Rev. 2)
    Server: HP ProLiant MicroServer G8, VMware ESXi 5.5 :P

  • Ich hatte auch schon daran gedacht das das root dev in grub.conf bzw menu.list als UUID angegeben sein könnte. Aber dann wäre das System definitiv nicht boot bar bzw. so ballt der init Prozess läuft ist das irrelevant. Wie sollten dann die init scripte laufen. In dem Fall würde der Boot Prozess mit "waiting for root-device" oder wie knebb schreibt mit "root-device not found" stehen bleiben bevor irgend ein init script läuft.


    knebb versteh mich nicht falsch ich weiß das meine Beiträge nicht einfach zu lesen sind. Aber ich glaube du hast nicht alle Fakten bedacht.



    @all vergebt meine grauenhafte Rechtschreibung und meinen schlechten schreib Stiele.

  • Hallo,


    und danke fuer die Antworten. War gestern nicht mehr in der Lage, was zu testen oder zu schauen (zumall sich ja die erfolglos geklonte Platte nicht in Betrieb befindet).


    Werde mich heute abend wieder dem Thema annehmen. Melde mich dann mit den gewuenschten Infos wieder und werde auch versuchen, die Tipps hier umzusetzen.


    Bis dahin viele Gruesse,
    Martin

    Hardware: Intel E5300, Gigabyte GA-EP41-UD3L, 4GB DDR2-RAM, 60GB 2.5" System, 3TB 3.5" Daten, L4M Cine S2 V6.5 DuoFlex S2 V4, Samsung 46" LED-LCD TV
    Software: yaVDR mit diversen Plugins und XBMC
    Ambilight: SEDU Board, 112 * WS2801 LEDs, boblight/vdr-plugin-seduatmo


    Pro-Taucher - Tauchplätze weltweit

  • So, nochmal zum verstehen...
    per resize2fs kann das filesystem verkleinert werden, die partitionsgrösse bleibt jedoch erhalten!!!
    per fdisk die partition löschen und kleiner neu anlegen und die Partition wird auch kleiner.
    AAAber auf jeden fall den Start Sektor gleich lassen!!! (sonst wird das fs nicht gefunden)
    Und die Partition nicht kleiner als das fs machen!!!


    Wenn das fs danach noch etwas kleiner als die partition ist noch mal resize2fs drüber laufen lassen und alles passt.


    Die nachfolgenden Partitionen dann am besten löschen,
    per dd die platte klonen (wird halt irgendwann beendet weil kein Platz mehr auf der Zielplatte ist...)
    Vom Ziel booten, weitere partitionen erstellen etc. fertig


    partimage kann auch eine einzelne Partition spiegeln, in ein file sichern etc.
    dann muss grub jedoch manuell noch in den mbr geschrieben werden.

  • du benutzt doch debian oder ein derivat?


    dann installiere dir "dump" und mit einem:


    dump und restore iat dein inhalt innerhalb von 30 min von einer auf der anderen partition


    fertisch


    vdr-box

    The post was edited 1 time, last by vdr-box ().

  • Mit gparted kann man bei ext-Partitionen gut die Grösse ändern, verschieben und kopieren(da bin ich aber nicht sicher, ob das nur auf der selben Platte geht).
    Ich nehme dazu meistens die LiveCD.

    Gruss
    SHF


  • Hallo zusammen,


    so, ich habe alles ausprobiert, resize2fs, geparted (was einen sehr netten Eindruck macht) und so weiter und so fort.


    Es lag letztendlich an der fstab, wie ich nach einer Testinstallation rausgefunden habe. Kaum habe ich diese Optionen noatime,data=writeback,acl drinnen stehen, bootet die Platte nur read-only. Wie kann das denn sein, was passt der Platte denn nicht? Es handelt sich um eine Hitachi Travelstar SATA mit 7200U/min, also nicht unbedingt ein altes Modell. Die 300GB 3.5" SATA Platte ist aelter. Die 1TB Datenplatte laesst sich natuerlich auch so mounten.


    Desweiteren mounte ich so seit Jahren alle moeglichen Rootserver, die ich betreue. Kein Ding seit 2002.


    Habe nun einfach nur default-Werte drinnen stehen, bei nem VDR kommt es ja nicht so wirklich drauf an. Aber interessieren wuerde es mich ja schon, was das soll...


    Viele Gruesse,
    Martin

    Hardware: Intel E5300, Gigabyte GA-EP41-UD3L, 4GB DDR2-RAM, 60GB 2.5" System, 3TB 3.5" Daten, L4M Cine S2 V6.5 DuoFlex S2 V4, Samsung 46" LED-LCD TV
    Software: yaVDR mit diversen Plugins und XBMC
    Ambilight: SEDU Board, 112 * WS2801 LEDs, boblight/vdr-plugin-seduatmo


    Pro-Taucher - Tauchplätze weltweit