Debian 13 kommt nach dem Klonen mit Clonezilla mit Kernel Panic nicht hoch

Photon

Rear Admiral Pro
🎅Rätsel-Elite ’24
Registriert
Apr. 2006
Beiträge
5.484
Hallo Community,

ich habe eine Debian 13 Installation mittels Clonezilla geklont (device - device) und dann versucht die Kopie zu booten. Leider stoße ich dabei auf eine Fehlermeldung wie hier (Screenshot siehe Anhang): https://askubuntu.com/questions/1443090/mdadm-no-arrays-found-in-config-file-or-automatically.

Also habe ich einen chroot ins Kopie-System gemacht und habe dort wie empfohlen die "resume"-Option aus der GRUB-Bootline in /etc/default/grub entfernt. Beim Versuch, update-grub auszuführen, erhalte ich jedoch die Meldung "Failed to get canonical path of /dev/sda2" (das ist die Root-Partition des Kopie-Systems). Schon vor dem Chrooten hat er abgelehnt /dev und /dev/pts zu mounten, deswegen ist das wohl nicht überraschend.

Außerdem ist mir aufgefallen, dass die Kopie der Swap-Partition laut Partitionsprogramm keine Swap-Partition war. Habe sie dann als swap "formatiert", jedoch hat es nichts gebracht, weil sich ihre UUID vom Original unterschieden hat, also konnte die resume-Option gar nicht funktionieren.

Frage: Was sind best practices beim Klonen einer modernen Linux-Distro, die die resume-Option verwendet, damit das Problem nicht auftaucht und man nicht nacharbeiten muss?

Danke für alle Tipps!
Photon

edit: Ich glaube, das ist mein Problem: https://serverfault.com/questions/8...ot-after-clonezilla-clone-of-redhat-install-t Muss das morgen ausprobieren... Könnte mir aber vorstellen, dass grub-install im chroot genauso wenig klappt wie update-grub...
 

Anhänge

  • 5330307242337106268.jpg
    5330307242337106268.jpg
    268,9 KB · Aufrufe: 132
Zuletzt bearbeitet:
Hi,

resume ist doch nur für hibernate ?

ein grub-mkconfig ausgeführt, damit /boot/grub/grub.cfg aktualisiert und mit den neuen Pfaden ausgefüllt wird ?

beim chroot müssen diverse proc, sys Pfade im chroot eingebunden werden, damit die Laufwerke und Pfade korrekt detektiert werden können

z.B.

Konfiguration​


Vor dem Eintreten in chroot müssen einige Verzeichnisse gemountet werden:


mount --rbind /dev /mnt/mychroot/dev

mount --make-rslave /mnt/mychroot/dev

mount -t proc /proc /mnt/mychroot/proc

mount --rbind /sys /mnt/mychroot/sys

mount --make-rslave /mnt/mychroot/sys

mount --rbind /tmp /mnt/mychroot/tmp

Quelle: https://wiki.gentoo.org/wiki/Chroot/de
 
  • Gefällt mir
Reaktionen: Crisser67
Also ich würde da einfach klassisch chrooten, in Sensei21's Beitrag beschrieben. Da sollte auch ein grub-install funktionieren.
 
Zuletzt bearbeitet:
Photon schrieb:
Jap, genau das chrooten scheitert ja schon. Und zwar daran, dass auf dem geklonten System /dev nicht vorhanden ist.
/dev ist ein dynamisch (nur zur Laufzeit vorhandener) von (meist) 'udev' erstellter Ordner. Anders ausgedrückt, ein vom Gerätemanager beim Systemstart erstellter Ordner, in dem deine Hardware (devices) gepackt werden. Der wird nicht geklont.

Womit machst Du denn den chroot? Debian13 LiveCD? Der dort (zur Laufzeit) vorhandene /dev Ordner muss in den Zielordner gespiegelt werden, bevor die chroot Umgebung betreten wird. Wenn das nicht klappt, brauchst Du nicht weiter machen. /dev ist obligatorisch.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Tanzmusikus
Ja genau, mit Debian 13 LiveCD. Soweit ich das überblicke, müsste das Spiegeln durch den Befehl

"for dir in /dev /dev/pts /proc /sys /sys/firmware/efi/efivars /run; do sudo mount --bind $dir /mnt$dir; done"

passieren. Das scheitert aber mit der Meldung, dass die Mountpoints /dev und /dev/pts nicht existieren. Der Befehl geht dann nur durch, wenn ich die beiden Ordner aus der Liste rausnehme.

Nachtrag: Möglicherweise muss ich was korrigieren: Vielleicht hab ich das gar nicht mit der Debian LiveCD gemacht, sondern mit der Quellplatte, auf die Debian-Installation lebt, die geklont werden sollte. Die Platte war wie ein USB-Stick in einem externen Gehäuse angeschlossen. Könnte das den fehlenden /dev Mountpoint erklären?
 
Photon schrieb:
"for dir in /dev /dev/pts /proc /sys /sys/firmware/efi/efivars /run; do sudo mount --bind $dir /mnt$dir; done"
Edit: Nochmal neu...
Probier mal das:
Code:
for dir in /dev /dev/pts /proc /sys /sys/firmware/efi/efivars /run; do sudo mkdir -p /mnt$dir; sudo mount --bind $dir /mnt$dir; done
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Tanzmusikus
für das chroot kann man die Ordner erstellen, nur für das Booten des fertigen Systems muss man evtl. die Ordner wieder entfernen, da sie dynamisch erstellt werden - da es ansonsten zu Probleme kommen kann (hatte sowas in der Vergangenheit, weiß nicht ob es heutzutage mit aktuellen Systemen problemloser funktioniert)

System-Backups erstelle ich generell über einen komprimierten Tarball (bei gentoo auch mal "stage4" oder "stage3" genannt), da ich Backup-Software nicht traue - oder via rsync
 
welches dateisystem wird verwendet? vielleicht habe ich es auch uebersehen. ich hatte kuerzlich den fall, dass clonezilla nicht zurecht kommt mit btrfs. die platte habe ich dann mit dd geklont, das war die loesung.
gruesse
 
Sensei21 schrieb:
System-Backups erstelle ich generell über einen komprimierten Tarball oder via rsync
Hättest du dafür Links für gute How-To's, wie man das macht ? Wäre nett von Dir...
 
Okay, ich hab das Problem lösen können, indem ich den Ordner /dev einfach im kopierten System angelegt habe. Danach konnte der chroot erfolgreich durchlaufen und dann auch grub-install und update-grub.

Nun möchte ich das System nicht einmal sondern knapp 20mal klonen und dabei nach Möglichkeit vermeiden, bei jedem Klon den chroot durchführen zu müssen. Ich frage mich also, ob man das nicht irgendwie geschickter machen kann, vielleicht in der Clonezilla-Kommandozeile?
 
  • Gefällt mir
Reaktionen: Tanzmusikus
Könntest halt auch mit dd arbeiten und die Festplatte clonen. Aber an die Systeme musste dann ja eh wieder ran, wegen Host-Keys, IPs usw, dann würde sich ein tar bz2 und etwas scriptbasierendes dann eher anbieten, wo Du wieder chrooten müsstest. Oder du packst das Quellimage entsprechend an.
 
  • Gefällt mir
Reaktionen: Sensei21
Photon schrieb:
Was sind best practices beim Klonen einer modernen Linux-Distro, die die resume-Option verwendet, damit das Problem nicht auftaucht und man nicht nacharbeiten muss?

  • Unattended install [über Netzwerk]
  • Basis Image per Hand verteilen, dann den Rest per Ansible hochziehen
  • Image klonen und vorher selbst ein Skript injecten was die ganzen Sachen wie enos/enps/etc anpasst.
 
  • Gefällt mir
Reaktionen: Littlebalgo und Sensei21
Crisser67 schrieb:
Hättest du dafür Links für gute How-To's, wie man das macht ? Wäre nett von Dir...

früher gab es einmal ein archiv des alten gentoo wiki "gentoo wiki archives/archive" oder so ähnlich, Suchtreffer bei unix.stackexchange.com oder reddit und forums.gentoo.org

hab mich auch bei https://wiki.gentoo.org/wiki/Mkstage4 bedient - traute aber nicht wirklich dem Skript vor der Nutzung - hatte es angepasst

"aktueller" Treffer via Suchmaschine: https://github.com/TheChymera/mkstage4 , https://www.tutorials.chymera.eu/blog/2014/05/18/mkstage4-stage4-tarballs-made-easy/ <-- hab diese jedoch nicht getestet bzw. genutzt

hier mal ein sample meiner Befehle:

Warnung: /etc/hosts, /etc/hostname, /etc/fstab beim ersten Wiederherstellen nicht vom rsync ausnehmen !

sources:
  • mkstage4 (gentoo backup script)
  • gentoo-wiki archives
  • forums.gentoo.org
  • stack exchange


backup:
Bash:
time tar -cpP --ignore-failed-read --xattrs-include=. --numeric-owner --use-compress-prog='/usr/sbin/zstd -9 -T8' --exclude=/root/.cache/* --exclude=/root/.cargo/* --exclude=/dev/* --exclude=/var/tmp/* --exclude=/media/* --exclude=/mnt// --exclude=/proc/* --exclude=/run/* --exclude=/sys/* --exclude=/tmp/* --exclude=/var/lock/* --exclude=/var/run/* --exclude=/var/cache/distfiles/* --exclude=/var/cache/ccache/* --exclude=/var/cache/ccache_bak/* --exclude=/var/cache/binpkgs/* --exclude=/var/log/portage/* --exclude=/var/lib/dhcpcd/* --exclude=/home/* --exclude=/data/* --exclude=/bak/* -f /home/backups/stage4-mkstage4-24.08.2025_1_6.15.11_6.16.2_sample.tar.zst /


extract:
Bash:
time tar xpf /home/backups/stage4-mkstage4-30.07.2023_2.tar.zst -I 'zstd -T8' --acls --xattrs-include='.' --numeric-owner -C /mnt/gentoo



time tar xpf /home/backups/stage4-mkstage4-30.07.2023_2.tar.zst -I 'zstd -T8' --acls --xattrs-include='.' --numeric-owner -C /bak/mnt_gentoo


-----------------------------------------------------------------------

sources:
stack exchange unix

backup:
Bash:
time rsync -aHAXU --stats --compress --compress-choice=zstd --partial --inplace --delete /var/log/portage/ /bak/sys_bak/var_log_portage/



time rsync -aHAXU --stats --compress --compress-choice=zstd --partial --inplace --delete /var/db/repos/ /bak/sys_bak/var_db_repos/



time rsync -aHAXU --stats --compress --compress-choice=zstd --partial --inplace --delete /var/cache/binpkgs/ /bak/sys_bak/var_cache_binpkgs/



time rsync -aHAXU --stats --compress --compress-choice=zstd --partial --inplace --delete /var/cache/distfiles/ /bak/sys_bak/var_cache_distfiles/



time rsync -aHAXU --stats --compress --compress-choice=zstd --partial --inplace --delete --exclude=/root/.cache/* --exclude=/root/.cargo/* --exclude=/dev/* --exclude=/proc/* --exclude=/sys/* --exclude=/run/* --exclude=/tmp/* --exclude=/var/tmp/* --exclude=/media/* --exclude=/mnt/* --exclude=/var/cache/distfiles/* --exclude=/var/cache/ccache/* --exclude=/var/cache/binpkgs/* --exclude=/var/log/portage/* --exclude=/var/lib/dhcpcd/* --exclude=/home/* --exclude=/bak/* --exclude=/data/* --exclude="lost+found" / /bak/sys_bak/mnt_gentoo/

restore:
Bash:
time rsync -aHAXU --stats --partial --inplace --delete /bak/sys_bak/var_log_portage/ /mnt/gentoo/var/log/portage/

time rsync -aHAXU --stats --partial --inplace --delete /bak/sys_bak/var_cache_binpkgs/ /mnt/gentoo/var/cache/binpkgs/

time rsync -aHAXU --stats --partial --inplace --delete /bak/sys_bak/var_cache_distfiles/ /mnt/gentoo/var/cache/distfiles/

# sys

# remove compress, zstd and xxhash - zstd potentially segfaults, xxhash might cause issues too (nixos, cachyos, etc. - check RAM via memtest to have safe base + btrfs mount checksum errors)
Bash:
time rsync -aHAXU --stats --compress --compress-choice=zstd --partial --inplace --delete --exclude="lost+found" --exclude=/home/* --exclude=/etc/fstab --exclude=/etc/hosts --exclude=/etc/hostname --exclude=/var/cache/distfiles/* --exclude=/var/cache/binpkgs/* --exclude=/var/log/portage/* --dry-run /bak/sys_bak/mnt_gentoo/ /mnt/gentoo/

hab schon länger kein restore via tar + 7z mehr gemacht, weiß also nicht ob sich was geändert hat - nutze momentan eine externe SSD und rsync dafür
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Tanzmusikus, Littlebalgo und Crisser67
Zurück
Oben