[P3f]

Hi,

ich habe eine Auffälligkeit gesehen, die zwar nicht das Thema genau trifft, aber vielleicht sind hier ja auch Seiteneffekte zu erleben.

In der Datei INSTALL vom Backup-Addon wird bei der Installation ein Link zu /mnt/data/ angelegt, welches auf die aktuelle Systempartition zielt.

Auszug aus INSTALL

Code: [Select]

backup_dir="$(readlink /mnt/system | sed 's|(/[^/]*/[^/]*)/.*|1|')/mld-backup"
                mkdir -p $backup_dir 2>/dev/null && ln -sf $backup_dir /data/backup || mkdir /data/backup


Allerdings kommt es zur Erzeugung von einem falschen Link, und somit keine Erzeugungsmöglichkeit mehr für ein "online" Backup. Schließlich wird hier demnach der Link beim Install erzeugt, und das ist das falsche Laufwerk. Konkret ist es bei mir zu folgenden (falschen) Link gekommen, da ich das Addon in einem angepassten ISO-Image enthalten habe.

MLD> ls -l
lrwxrwxrwx    1 root     root            21 Sep 10 21:49 backup -> /mnt/sdb1/mld-backup/
lrwxrwxrwx    1 root     root            15 Sep  9 21:47 music -> /mnt/data/music
lrwxrwxrwx    1 root     root            15 Sep  9 21:47 photo -> /mnt/data/photo
drwxrwxr-x    2 root     root          4096 Sep  9 21:47 tv
lrwxrwxrwx    1 root     root            15 Sep  9 21:47 video -> /mnt/data/video

korrekt wäre: (manuell angepasst durch mich beim Link vom backup)

MLD> ls -l
lrwxrwxrwx    1 root     root            21 Sep 10 21:49 backup -> /mnt/sda1/mld-backup/
lrwxrwxrwx    1 root     root            15 Sep  9 21:47 music -> /mnt/data/music
lrwxrwxrwx    1 root     root            15 Sep  9 21:47 photo -> /mnt/data/photo
drwxrwxr-x    2 root     root          4096 Sep  9 21:47 tv
lrwxrwxrwx    1 root     root            15 Sep  9 21:47 video -> /mnt/data/video

==> Das löst zwar noch nicht die Problematik mit dem Restore. Aber ich denke es sollte hier immer die installierte Systempartition und nicht die gestartete Systempartition verlinkt werden.

@Marmic:
Was meinst Du mit Anpassung der Hilfe auf der Konsole? Wenn man den Befehl falsch eingibt, dann kommt doch folgende Rückmeldung:

MLD> backup.sh rest
Usage: backup.sh {list | create | restore | delete | update} [BACKUP_NAME]

Gruß,

PIt

[P3f]

Hi,

ich bin mal wieder ein wenig zum Testen gekommen und teile hier mal meine Erkenntnisse mit.

Das vorher beschriebene "falsche" verlinken vom lokalen (online) Backup /data/backup kommt nur zu stande, sobald man nach dem Reboot der Installation den USB-Stick eingesteckt lässt. Es laufen danach erst die INSTALL Einstellungen ab. Also, wenn man die Installation übers Webif gemacht hat, und dann rebootet, sollte man den USB-Stick schon entfernen. Dann ist alles korrekt!!!! ==> also kein Fehler...

Beim Backup-Addon bin ich soweit gekommen, das ich einfach ein älteres ISO (vom 4.8.2013) von mir gefunden hatte, und dieses mal kurz installierte. Danach funktionierte auch der Backup-Mechanismus ohne Probleme. Daraufhin habe ich mir die Versionen angeschaut, und es war die Rev 49 vom Backup-addon. Mutig geworden habe ich dann mal die Rev 54 vom Backup-Addon geupdatet, und siehe da auch das hat funktioniert. :wand

Also, mit den vorherigen INITRAMFS (Rev. 453) und KERNEL-Addons (Rev 166) funktioniert es ohne Probleme, da sich in diesen Addons nur das aufs-Thema geändert hat schiebe ich Probleme auf das aufs-Thema.

Könnt ihr Spezialisten euch das erklären?

So wie ich als Laie das erkenne, wird doch "nur" die readlink-Funktion im Backup.sh Script abgefragt. Kommt diese vom aufs?

Das Ergebnis ist aber reproduzierbar, also sobald ich die Revs vom KERNEL und INITRAMFS aktualisiere funktioniert das Backup.sh Script nicht mehr. Fehlermeldung wieder wie oben.

Ich werde morgen mal, das auch mit den Erweiterungen von MegaX testen. Meine Vermutung ist, das diese Probleme nicht aus dem Backup-Addon kommen.

Leider bin ich heute zeitlich nicht mehr frei und könnte weiter testen ;(  Aber vielleicht habt ihr ja eine Idee dazu?

Gruß,

Pit

[clausmuus]

Hi,

es ist durchaus möglich, das readlink abhängig vom aufs unterschiedliche Ergebnisse liefert (auf den Zusammenhang muss man aber erst einmal drauf kommen,...). Magst Du das mal auf der Kommandozeile überprüfen? Also schauen, ob readlink auf nem alten und dem neuen System unterschiedliche Ergebnisse für den im Backup-Script vorkommenden Pfad liefert. Bitte hier auch beide Ergebnisse posten, sofern die sich unterscheiden.

Claus

[oelhahn]

Ich habe soeben den MLD Client 3.0.3 auf den heutigen Update-Stand gebracht,
mein Webif zum Backup sieht so aus wie unten.
Ich seh' da nix von Sever, oder hab' ich was versemmelt bzw. übersehen?

[P3f]

Hi,

das mit den erweiterungen von MegaX ist im Moment wieder zurückgenommen, da wir einen Fehler beim Restore suchen.... (scheinbar sind wir nun näher dran).

@Oelhahn: Also im Moment nichts falsch gemacht. Das kommt wieder rein....

@Claus: Ich kann leider erst morgen weitermachen, muß auf eine Hochzeit...

Bis später, vielleicht kann ja auch schon jemand anderes da suchen..

Gruß,

Pit

[P3f]

Hi,

so ich habe mal die Unterschiede gefunden, und es ist auch wirklich reproduzierbar :wow:

Ich habe die Werte aus der "/usr/bin/backup.sh" mal als echo umgebaut bzw. ausgegeben. Somit ergibt sich folgendes Ergebnis:

KERNEL REV 174
INITRAMFS REV 461
/mnt/data/backup/$name: /mnt/data/backup/ok
$path/mld-new: /mnt/sda1/mld-new
$path/mld-new/boot/isolinux: /mnt/sda1/mld-new/boot/isolinux
$path/mld/boot/isolinux: /mnt/sda1/mld/boot/isolinux
$path/mld-new/boot/isolinux: /mnt/sda1/mld-new/boot/isolinux
$path/mld: /mnt/sda1/mld
$path/$old_dir: /mnt/sda1/mld-3.0.3
$path/$old_name: /mnt/sda1/mld-mv
$old_name: mld-mv
$path/mld: /mnt/sda1/mld
$path/mld-new: /mnt/sda1/mld-new
$path/$old_dir: /mnt/sda1/mld-3.0.3
$old_dir: mld-3.0.3
$path/mld-mv: /mnt/sda1/mld-mv


KERNEL REV 166
INITRAMFS REV 453
/mnt/data/backup/$name: /mnt/data/backup/ok
$path/mld-new: /mnt/sda1/mld-new
$path/mld-new/boot/isolinux: /mnt/sda1/mld-new/boot/isolinux
$path/mld/boot/isolinux: /mnt/sda1/mld/boot/isolinux
$path/mld-new/boot/isolinux: /mnt/sda1/mld-new/boot/isolinux
$path/mld: /mnt/sda1/mld
$path/$old_dir: /mnt/sda1/mld-3.0.3
$path/$old_name: /mnt/sda1/mld-old
$old_name: mld-old
$path/mld: /mnt/sda1/mld
$path/mld-new: /mnt/sda1/mld-new
$path/$old_dir: /mnt/sda1/mld-3.0.3
$old_dir: mld-3.0.3
$path/mld-mv: /mnt/sda1/mld-mv

Ergebnis: Der "old_name" ist bei der der neueren KERNEL und INITRAMFS Version anders, und damit funktioniert es nicht. Wenn ich mir das Script anschaue, dann wird hier ein existierendes Verzeichnis unter "/tmp/backup" geprüft. Ich sehe hier den Sinn der Prüfung nicht eindeutig. Aber ihr könnt es doch sicherlich erklären.

[clausmuus]

Hi,

ohne mich nun wieder bis in's letzte Detail da einzulesen, komme ich zum folgenden Schluss:
- die Datei /tmp/backup wird angelegt um zu erkennen ob seit dem letzten booten bereits ein Backup eingespielt wurde. Dies ist nötig, um bei der Wiederherstellung eine Sicherheitskopie des ursprünglichen Systems anzulegen, oder dies eben nicht zu tun (wenn das schon erfolgt ist).
- Wie's aussieht scheitert dies da dran, dass das /tmp Filesystem mit dem neusten Update der MLD nicht mehr bei booten gelöscht wird, also nicht mehr in der Ram-Disk liegt. DIes lässt sich überprüfen, indem geschaut wird, ob der Ordner /mnt/systme/tmp existiert, was nicht sein darf. Nun kann der Ordner testweise gelöscht und der Ordner /mnt/tmpfs/tmp angelegt werden, um zu schauen ob /mnt/system/tmp nach einem reboot wieder neu angelegt wurde, was nicht sein darf. /mnt/tmpfs/tmp ist die Spiegelung von /tmp und die darf nicht permanent und unter /mnt/system/tmp zu finden sein.

Das Ganze deutet da drauf hin, dass meine AUFS Patches nicht mehr funktionieren. Die neue Fassung der Patches muss also noch einmal gründlich überprüft und mit der alten Fassung verglichen werden.

Claus