<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hallo zusammen<div class=""><br class=""></div><div class="">Hier ein (vorerst) letztes Update zu meinem Nexctloud-Server:</div><div class="">Ich hatte diese Woche viel Zeit investiert um die Kiste wieder zum laufen zu bringen.</div><div class="">Die gute Nachricht vorweg: ich war Gestern Abend endlich erfolgreich.</div><div class=""><br class=""></div><div class="">Was habe ich versucht:</div><div class="">1) Das mit ddrescue erfolgreich erstellte Backup der SD-Karte auf einer neuen Karte wiederhergestellt. Leider ohne Erfolg.</div><div class="">2) Auf die neue SD-Karte erneut das offizielle Image aufgespielt</div><div class="">3) Den Nextcloud-Ordner der alten SD-Karte in /var/www der Neuen kopiert.</div><div class="">4) Sofort in /var/www/nextcloud/config/config.php maintenance auf true gestellt</div><div class="">4) Anhand der Installationsanleitung (<a href="https://docs.nextcloud.com/server/13/admin_manual/installation/source_installation.html#ubuntu-installation-label" class="">https://docs.nextcloud.com/server/13/admin_manual/installation/source_installation.html#ubuntu-installation-label</a>) von Nextcloud alle nötigen Packete installiert.</div><div class="">5) Mit rsync -avz anhand einer Anleitung (<a href="https://www.tecmint.com/transfer-mysql-databases-from-old-to-new-server/" class="">https://www.tecmint.com/transfer-mysql-databases-from-old-to-new-server/</a>) die MySQL Datenbank mit allen Usern von der alten auf die neue SD-Karte kopiert.</div><div class="">6) Den bisherigen Mountpoint der externen HDD auf dem neuen System und in /etc/fstab den entsprechenden Eintrag erstellt</div><div class="">7) Die vorhandenen Zertifikate für die SSL Verschlüsselung an die entsprechende Stelle kopiert</div><div class="">Ab da war die Nextcloud wieder über dieselbe URL erreichbar und es wurde gemeldet, dass der Maintenance-Modus aktiv ist. Den konnte ich nun wieder deaktivieren und all meine Geräte konnten endlich wieder synchronisieren.</div><div class="">8) Meinen „Backup-User“ mit welchem ich meine Kalender und Kontakte teile mit dem Packet fstab in den dafür vorgesehenen Ordner eingebunden.</div><div class="">9) Mein Backup-Tool für Kalender und Kontakte (calcardbackup: <a href="https://github.com/BernieO/calcardbackup" class="">https://github.com/BernieO/calcardbackup</a>) kopiert und den entsprechenden Cron-Job angelegt, so dass immer nach Mitternacht ein Backup meiner Kontakte und Kalender erstellt wird (Bzw. werden sollte, das erste Mal wird der Cron-Job Heute Nacht ausgeführt).</div><div class="">Nun habe ich den Maintenance Modus nochmals aktiviert, den Server abgeschaltet, die SD Karte entnommen und erstelle mit dem Raspberry Pi und ddrescue (das Tool überzeugt mich auch, weil der Fortschritt jederzeit ersichtlich ist) gerade ein komplettes ISO-Abbild der Karte. </div><div class="">10) To-do: Nextcloud auf den neusten Stand bringen und die Sicherheitsmeldungen abarbeiten.</div><div class="">11) To-do: die grafische Oberfläche deaktivieren so dass der Server standardmässig im Konsolen-Modus startet.</div><div class=""><br class=""></div><div class="">Als Ursache für die Kernel Panik vermute ich meinen Versuch Docker auf meinem ARM basierten System zu installieren. </div><div class="">Die Installation war fehlgeschlagen und seither konnte ich via apt-get upgrade keine Aktualisierungen mehr laden. </div><div class="">Das System startete aber noch einige Male normal und funktionierte ansonsten einwandfrei. Bis sich das System eines Tages aufhängte und sich nicht mehr neu starten lies. </div><div class=""><br class=""></div><div class="">Ich habe viel dazu gelernt und es soll mir eine Lehre sein bezüglich Erstellen von Backups!</div><div class="">Der Wunsch Docker und damit verbunden Collabora Online zum Laufen zu bringen vertage ich wohl auf die Tage. Interessant wär’s allemal.</div><div class=""><br class=""></div><div class="">An dieser Stelle möchte ich nochmals allen herzlich für die tatkräftige Unterstützung danken! Ohne euch würde unser Familienkalender noch lange nicht synchronisiert.</div><div class=""><br class=""></div><div class="">Merci!</div><div class=""><br class=""></div><div class="">Liebe Grüsse</div><div class="">Christian</div><div class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">Am 29.03.2019 um 23:03 schrieb Markus Wernig <<a href="mailto:wernigm@lugbe.ch" class="">wernigm@lugbe.ch</a>>:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hallo Christian<br class=""><br class="">On 3/10/19 1:19 PM, Christian Baumgartner wrote:<br class=""><br class=""><blockquote type="cite" class="">Ich konnte mit ddrescue ein komplettes Backup meiner MicroSD Karte erstellen. Es wurden Null Fehler angezeigt.<br class="">Die SD Karte scheint also keinen Defekt aufzuweisen.[...]<br class="">Im Anhang findet ihr die beiden logfiles, die ich erstellt habe. <br class="">Ich hoffe sehr, dass ihr damit etwas anfangen könnt. <br class=""><br class="">Um Hilfe bei der Interpretation der Logfiles bin ich sehr dankbar. So wie ich die Sache sehe scheitert es beim laden irgendwelcher WLAN Elementen. Was ich nun mit der Info anfangen kann weis ich aber nicht.<br class=""></blockquote><br class="">Ich sehe in den Startmeldungen drei Sachen, keine ist für sich genommen<br class="">schlüssig:<br class=""><br class="">1) Beim erfolgreichen Bootvorgang hattest du eine Maus angesteckt.<br class="">2) Beim erfolgreichen Bootvorgang wurde der Randum number generator des<br class="">Kernels nicht initialisiert, beim gescheiterten schon.<br class="">3) Der fehlerhafte Boot scheitert in dem Moment, wo der Kernel die<br class="">Kontrolle an den systemd-Prozess übergeben will.<br class=""><br class="">1 und 2 halte ich für nicht aussagekräftig genug.<br class=""><br class="">3 ist der Grund, warum das System nicht startet. Allerdings sehe ich den<br class="">Grund für 3 nicht. Da gar keine Meldungen mehr kommen, kann entweder der<br class="">Prozess nicht gestartet werden, blockiert aber dennoch den Kernel, oder<br class="">er wird gestartet und blockiert dann sehr früh, noch bevor die erste<br class="">Meldung geschrieben werden kann.<br class=""><br class="">Die Disk als ganzes ist wohl nicht defekt, sonst hätte auch der Kernel<br class="">gar nicht starten können. Möglich wäre dann, dass die root-Partition<br class="">nicht oder nicht vollständig gelesen werden kann und daher z.B. das<br class="">systemd-Binary nicht korrekt ins Memory geladen werden kann, oder das<br class="">Linken fehlschlägt. Vielleicht blockiert auch ein Lesezugriff, aber dann<br class="">würde ich irgendwelche Fehlermeldungen nach einer gewissen Zeit erwarten.<br class=""><br class="">Wir können uns das morgen natürlich gern anschauen, das wird aber eine<br class="">aufwändige Sache. Zur Sicherheit die Frage: Gibt es einen Grund, warum<br class="">du das Linux auf der Platte nicht einfach neu installieren willst? Die<br class="">Daten hast du ja wieder.<br class=""><br class="">lg /markus<br class=""><br class=""><br class="">-- <br class="">Markus Wernig                              🐧<br class="">Präsident Linux User Group Bern<br class="">PGP: D9203D2A4AD9FC3333DEEF9DF7ACC6208E82E4DC<br class="">---------------------------------------------<br class="">Linux User Group Bern    -   <a href="https://lugbe.ch" class="">https://lugbe.ch</a><br class="">---------------------------------------------<br class=""><br class=""><br class="">_______________________________________________<br class="">Linux-support mailing list<br class=""><a href="mailto:Linux-support@lugbe.ch" class="">Linux-support@lugbe.ch</a><br class="">https://maillists.lugbe.ch/mailman/listinfo/linux-support<br class=""></div></div></blockquote></div><br class=""></div></body></html>