Ankündigung

Einklappen
Keine Ankündigung bisher.

LaCie 2big network 2 - mit uboot File bearbeiten

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • 2big Network LaCie 2big network 2 - mit uboot File bearbeiten

    Hallo,

    seit einem Update ist der Nas-Server nach dem Booten nicht mehr zugänglich. Ich kann nur noch in uboot via netconsole herumexperimentieren, und beim Booten zusehen.


    Es würde genügen, 1 oder 2 Dateien zu korrigieren, in /etc und /root. Die könnten auf /dev/md0 oder /dev/md2 liegen, vielleicht in snapshots. Wie kann ich unter uboot auf so eine Partition zugreifen und Dateien ansehen/bearbeiten?


    Alternativ - wozu gibt es diese Snapshots? Kann ich einen älteren Snapshot aktivieren? (oder ist das eine Frage für einen separaten Thread?)


    Weitere Frage: Könnte ich den Bootvorgang so beeinflussen, dass ich Zugang bekomme? Es gab (vielleicht nur bei x86?) mal so Bootparameter wie "single" und "init=/bin/sh". Diese haben hier keine Wirkung. Man sieht sogar, dass sie vom Kernel beim Booten angezeigt werden, dann aber vollkommen ignoriert werden. Der kernel zeigt also an: Kernel command line: ... root=/dev/nfs nfsroot=.... und bootet dann wie immer, nicht von NFS.


    btw: gibt es noch ein englischsprachiges Forum zu dem Thema? forum.nas-central... gibt es ja nicht mehr.

    danke
    Zuletzt geändert von sunflower; 10.12.2018, 02:30.

  • #2
    Zitat von sunflower Beitrag anzeigen
    Es würde genügen, 1 oder 2 Dateien zu korrigieren, in /etc und /root. Die könnten auf /dev/md0 oder /dev/md2 liegen, vielleicht in snapshots. Wie kann ich unter uboot auf so eine Partition zugreifen und Dateien ansehen/bearbeiten?
    Not. md0 and md2 are raid arrays. U-boot can't assemble them. And it doesn't contain a file editor either.
    Alternativ - wozu gibt es diese Snapshots? Kann ich einen älteren Snapshot aktivieren?
    You can activate the oldest snapshot by performing a factory reset.
    Originally Lacie had a nice way to handle updates, a layered rootfs. The factory image is on partition 8, which is mounted readonly. A writable layer (a snapshot directory from partition 9) is mounted on top of that. All user settings are written to that snapshot layer. If you can an update, theoretically only changed files are written to the snaphot, and a new snapshot is created to work with.
    So theoretically you can revert any update. The temporary rootfs on partition 7 contains scripts to strip a single snapshot, or to merge several snapshots to a new one. But AFAIK there is no interface to call them. Only factory reset, which basically flushes partition 9.
    This clean design is broken anyway, as the latest updates are no longer incrementally, and so use lots of diskspace.

    Es gab (vielleicht nur bei x86?) mal so Bootparameter wie "single" und "init=/bin/sh".
    On older boxes init=/bin/sh worked, although I don't know if the shell is supposed to work over netconsole. 'single' is handled by the OS bootscripts, so I don't think it is supposed to work on an embedded system.

    I think you'd have a look at plugout.net. That forum is dedicated to a custom OS for Lacie boxes, and the installer is a netconsole injected kernel/rootfs which gives you telnet access. So that opens a way to edit your filesystems.

    Kommentar


    • #3
      [Gelöst] - ich habe leider keinen Gelöst-Tag gefunden.

      Mijzelf hat die direkten Fragen wohl alle beantwortet.

      Zur Reparatur der Box: Die meisten Anleitungen, die ich gefunden habe, haben nicht funktioniert; es liegt immer an kleinen Details. clunc alleine kann hier keinen Zugang zur netconsole bieten - aber zusammen mit einem Zusatzprogramm "netconsole" oder "u-boot-netconsole". Nachdem clunc gestartet ist, muss noch netconsole gestartet werden. Ob es an nc liegt oder an meiner Box, weiß ich nicht. clunc ist nur ein wrapper script.

      Für einige Schritte ist ohnehin eine serielle console nötig. Die Schrauben an den hinteren Ecken des Gehäuses sind verdeckt und getarnt; die Abdeckung kann nicht entfernt werden, sondern ich musste mit Schraubendreher direkt in die Abdeckung hineinstechen. Zugang zur seriellen Console bekomme ich mit einem ch340 Gerät und 3 1-pin breadboard cables, ich denke die braucht man noch öfter, wenn man z.B. orangepi und ähnliches benutzt.

      Der offensichtliche Lösungsweg - wenn mit normalem Booten kein Zugang möglich ist (root Passwort nicht bekannt) - ist boot von TFTP und in eine NFS-Umgebung. Gentoo Linux hat sowas schon seit ca 15 Jahren "stage3", ich habe nur keinen Kernel dazu gefunden. Der Kernel auf der Box, der auch in den "capsules" enthalten ist, scheint die Bootparameter erst als print output zu wiederholen und dann komplett zu ignorieren. Statt dessen habe ich einen Debian Installer, bestehend aus Kernel und initrd, gefunden:
      http://lacie-nas.org/doku.php?id=ins...stom_installer
      Der FTP Server ist nicht mehr so organisiert wie es mal war, die Files liegen jetzt in anderen Verzeichnissen.
      Die Anleitung beschreibt einen ssh-Zugang, der hat aber nicht funktioniert (vielleicht Passwort inzwischen geändert), aber mit der seriellen Console muss der Installer abgebrochen werden, dann ist ein Shell-Zugang möglich. So konnte ich auf irgendwelchen Partitionen die Files finden, die das Booten blockiert haben, und den üblichen ssh-Zugang (-p 2222) wiederherstellen.

      Nach dem Booten hat sich noch herausgestellt, dass der installierte Kernel (Update-Kernel) verschwunden war. Man hat keine shares und keine User mehr im Webinterface gesehen. Grund war, dass der (alte) Kernel und die (neuen) Module nicht zusammenpassten. Mit dem üblichen ssh-Zugang konnte ich den neuen Kernel auf /dev/sda10 installieren -> Funktion wiederhergestellt.

      Den Hinweis auf plugout.net habe ich nicht mehr gesehen, weil das Problem schon nach ca 4 Stunden gelöst war.

      Kommentar

      Lädt...
      X