Sicherung Boot-SSD

[padersuse]

Man kann unter tumbleweed snapshots ins btrfs System zurückspielen, ich möchte aber zusätzlich ganze Partitionen sichern, um ein bootfähiges Ersatzlaufwerk zu haben.
Habe mit Clonzilla eine 1:1 Kopie gemacht, dann die kopierte Platte ausgebaut und die geklonte eingebaut. Leider bekomme ich folgende Fehlermeldung :

error: ../../grub-core/commands/loadenv.c:read_envblk_file:113:invalid environment block

Die UUID`s sind ja exakt abkopiert, aber das System fährt trotz der Fehlermeldung hoch und bleibt bei der graphischen Anmeldung hängen. Starte ich das System im recovery mode gelingt der Start des Systems. Was ist falsch gelaufen ?

 

[susejunky]

Habe mit Clonzilla eine 1:1 Kopie gemacht,

Warum hast Du die Kopie nicht mit dd gemacht?

... das System fährt trotz der Fehlermeldung hoch und bleibt bei der graphischen Anmeldung hängen. Starte ich das System im recovery mode gelingt der Start des Systems. Was ist falsch gelaufen ?

Was sagt in einer solchen Situation der Log?

journalctl --no-hostname --no-pager --full --utc -b -1 -p 3

Eventuell hilft das hier weiter.

 

[padersuse]

hallo susejunky,
der Befehl

journalctl --no-hostname --no-pager --full --utc -b -1 -p 3

bringt

Jun 22 19:32:57 systemd-udevd[507]: /etc/udev/rules.d/55-brother-brscan4-libsane-type1.rules:9 Invalid key 'SYSFS'.
Jun 22 19:32:57 systemd-udevd[507]: /etc/udev/rules.d/55-brother-libsane-type1-inst.rules:14 Invalid key 'SYSFS'.
Jun 22 19:32:57 (udev-worker)[572]: usb1: Failed to find and pin callout binary "/usr/lib/virtualbox/VBoxCreateUSBNode.sh": No such file or directory
Jun 22 19:32:57 (udev-worker)[538]: usb2: Failed to find and pin callout binary "/usr/lib/virtualbox/VBoxCreateUSBNode.sh": No such file or directory
Jun 22 19:32:58 (udev-worker)[556]: 1-1: Failed to find and pin callout binary "/usr/lib/virtualbox/VBoxCreateUSBNode.sh": No such file or directory
Jun 22 19:32:58 (udev-worker)[572]: 2-9: Failed to find and pin callout binary "/usr/lib/virtualbox/VBoxCreateUSBNode.sh": No such file or directory
Jun 22 19:32:59 (udev-worker)[556]: 1-8: Failed to find and pin callout binary "/usr/lib/virtualbox/VBoxCreateUSBNode.sh": No such file or directory
Jun 22 19:32:59 (udev-worker)[556]: 1-9: Failed to find and pin callout binary "/usr/lib/virtualbox/VBoxCreateUSBNode.sh": No such file or directory
Jun 22 19:32:59 (udev-worker)[556]: 1-8.3: Failed to find and pin callout binary "/usr/lib/virtualbox/VBoxCreateUSBNode.sh": No such file or directory
Jun 22 19:33:01 systemd-udevd[1014]: /etc/udev/rules.d/55-brother-brscan4-libsane-type1.rules:9 Invalid key 'SYSFS'.
Jun 22 19:33:01 systemd-udevd[1014]: /etc/udev/rules.d/55-brother-libsane-type1-inst.rules:14 Invalid key 'SYSFS'.
Jun 22 19:33:02 (udev-worker)[1040]: tpmrm0: Failed to open device node '/dev/tpmrm0': Operation not supported

ich war wohl fälschlicherweise davon ausgegangen dass clonezilla mit

dd

arbeitet

 

[susejunky]

@padersuse :

Aus den von Dir gezeigten Logeinträgen kann ich leider keinen direkten Zusammenhang zu dem von Dir beschriebenen Problem ableiten.

In der GRUB2-Dokumentation steht zum Thema Environment Block:

On Btrfs filesystems, a reserved area in the filesystem header may be used to store the environment block. This static block avoids the problems of updating a normal file on a copy-on-write filesystem, where writing raw block is not stable and requires metadata update. The reserved area provides a fixed location that GRUB can update directly, allowing commands such as grub-reboot and ‘GRUB_SAVEDEFAULT’ to function correctly on Btrfs volumes.

Ich habe keine Erfahrung mit clonezilla (und bin auch nicht wirklich mit btrfs vertraut). Aber wenn Clonezilla, nicht wie dd einfach nur Datenblöcke ohne Berücksichtigung von Partitionierung, Dateisystem, usw. bewegt, sondern dateisystemspezifische Optimierungen vornimmt, dann könnte das die Ursache für das von Dir beschriebene Verhalten sein.

Kannst Du Dir den Environment Block mit

grub2-editenv - list

anzeigen lassen?

Vielleicht hilft auch eine der folgenden Maßnahmen (ACHTUNG! Ich habe keine der Maßnahmen getestet.) Dein Problem zu beseitigen:

• In /etc/default/grub GRUB_SAVEDEFAULT=false setzen und danach

  update-bootloader --config

  ausführen.
• Mit

  grub2-editenv - create

  einen neuen, leeren Environment Block anlegen.

Und letztendlich wäre es sicherlich auch einen Versuch wert, den Datenträger mit dd zu "klonen".

 

[padersuse]

grub2-editenv - list

bringt

env_block=512+1
saved_entry=openSUSE Tumbleweed

 

[susejunky]

env_block=512+1
saved_entry=openSUSE Tumbleweed

Meine Vermutung (abgeleitet aus der GRUB2-Dokumentation):

clonezilla hat keine 1:1-Kopie des Original-Datenträgers erstellt, deshalb findet GRUB2 in der Kopie seinen Environment Block nicht an der Position 512+1.

 

[padersuse]

Die Vorschläge zur Reparatur funktionierten nicht, habe mit yast den Bootloader neu erstellt, trotzdem keine Veränderung.

 

[susejunky]

habe mit yast den Bootloader neu erstellt,

In welchem meiner Beiträge habe ich Dir empfohlen den Bootloader mit YaST neu zu installieren ???

Hast Du (auf der Kopie, die den Fehler aufweist) einen neuen GRUB2 Environment Block erstellt? Wenn ja, welche konkreten Fehler treten danach immer noch auf?

Hast Du eine Kopie des Originaldatenträgers mit dd erstellt und geprüft, ob die selben Fehler auch mit dieser Kopie auftreten?

 

[padersuse]

Ich habe Deine Vorschläge versucht, aber ohne Erfolg. Doe Originalplatte ergibt bei Aufruf von

grub2-editenv - list

ebenso

env_block=512+1
saved_entry=openSUSE Tumbleweed

Ich schaue nochmal nach den Fehlermedlungngen und versuche es mit

dd

 

[padersuse]

Hallo susejunkey,
mit dd funktioniert das klonen noch schlechter, ich lande in der "schwarzen" grub-minimal bash, der Bootloader mit opensuse-Optionen esrcheint erst gar nicht, konkrete Fehlermeldungen nach Anwendung deiner Vorschläge habe ich nicht gesehen, es änderte sich nur nichts. Kann natürlich nochmal mit clonzilla eine Kopie machen und dann nochmal schauen, ich warte aber erst, was Du dazu schreibst.
Habe übrigens folgenden Befehl im laufenden Betrieb ausgeführt

dd if=/dev/sda of=/dev/sdb bs=64K status=progress

 

[susejunky]

@padersuse :

Ich habe mir Deinen ersten Beitrag noch einmal genauer angesehen. Du beschreibst darin drei Sachverhalte, die beim Systemstart mit der Kopie auftreten:

1. Es wird die Fehlermeldung "error: ../../grub-core/commands/loadenv.c:read_envblk_file:113:invalid environment block" angezeigt.
2. Das System fährt trotz der Fehlermeldung hoch und bleibt bei der graphischen Anmeldung hängen.
3. Starte ich das System im recovery mode gelingt der Start des Systems.

Ich hatte vermutet, dass 2.) nur eine Folge von 1.) sei aber möglicherweise ist das nicht so.

Habe übrigens folgenden Befehl im laufenden Betrieb ausgeführt

Eine Kopie der Systemplatte aus dem laufenden System heraus zu erstellen ist, unabhängig davon, ob man clonezilla oder dd verwendet, keine gute Idee (offene Dateien, usw.).

Mein Vorschlag für das weitere Vorgehen ist folgender:

Starte ein LIVE-System und erstelle aus dem LIVE-System heraus eine Kopie der Systemplatte mittels dd.

Wenn auch diese Kopie in der graphischen Anmeldung hängen bleibt, versuche ob Du mit Strg+Alt+F3 ein virtuelles Terminal öffnen kannst.

 

[padersuse]

Ich habe nach starten des rescue-systems von tumbleweed feststellen müssen, nach nach ausführen des Befehls

dd if=/dev/sda of=/dev/sdc bs=64K status=progress

(sdc stimmt in diesem Fall)
der Kopiervorgang bei ca. 64GB stoppte aus für mich unerfindlichem Grund.
habe das rescue-system nochmal neu gestartet. Jetzt muss ich erstmal warten
Sollte ich einen mem-Test machen ?

 

[susejunky]

Sollte ich einen mem-Test machen ?

Das ist schwer zu sagen. Allerdings würde ich eher ein Problem bei den beteiligten Datenträgern (sda bzw. sdc) vermuten. Da dd auf Datenblockebene arbeitet kann es auch kein Problem des Dateisystems sein.

Eventuell können

smartctl -a /dev/sda

und

smartctl -a /dev/sdc

Hinweise liefern.

 

[padersuse]

der dd-Befehl ist wohl einwandfrei durchgelaufen, bekomme keine Error-Meldung beim Booten und die Anwendung über kde ist möglich. Smartctl hat keine error-Meldungen gebracht. Ich danke Dir susejunky !

 

[susejunky]

der dd-Befehl ist wohl einwandfrei durchgelaufen, bekomme keine Error-Meldung beim Booten und die Anwendung über kde ist möglich. Smartctl hat keine error-Meldungen gebracht.

Dann lag das Problem möglicherweise darin begründet, dass die Kopie bei laufendem System gemacht wurde und/oder dass clonezilla keine 1:1-Kopie erstellt.

Aber schön, dass jetzt alles funktioniert.

Weiterhin viel Spaß mit Deinem openSUSE Tumbleweed System.