[Sammelthread] Der 20€ Server [Part 2]

Joa. ist aber komfortabel. Macht auch automatisch umounts nach z.B. 5 sekunden ohne Datenübertragung und mountet automatisch dann bei zugriff... Finde ich z.B. sehr komfortabel.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
danke erst mal komm nur im moment seit heute leider nicht dazu !! hoffe das ich dazu am WE mehr zeit finde!
 
GrafikTreiber schrieb:
Du nutzt z.B. /dev/disk/by-uuid/af86234b-73af-4789-9223-65sd35a686 und gibst dann deinen Mountpoint an wohin du es eben nun haben willst, das funktioniert dann auch immer weil sich die UUID nicht verändert bis du die Partition neu erstellst oder manuell anpasst.
Zum Vergrößern anklicken....

damit mountet er es richtig aber sobald ich sie austecke und wieder einstecke nicht mehr er soll das ja automatisch machen!!!

mein genaues vorhaben!! ich möchte die hdd bei bedarf einstecken, sie soll gemountet werden und nen sync machen und danach nen unmount nur blick ich weder beim mount noch beim sync durch?!

;/ sorry bin linux noob

EDIT: habs auch irgendwie hinbekomme das er sie ohne was zu machen nach dem ersten system start mountet sobald ich sie einstecke!! aber fragt mich jetzt nich wie ich das gepackt hab :d
 
Zuletzt bearbeitet:
Wollte mal fragen ob jemand ne methode kennt um während des Betriebs ein Sys Backup zu machen?!
geht das einfach mit dd?

Danke!
 
Was verstehst du unter Sys Backup? Eine 1:1 Spiegelung des aktiven Root Filesystems? Das geht nicht so einfach (bzw. kann schnell lustig werden). Wenn du z.B. aber nur /var/ oder /home/ sichern willst geht das noch relativ problemlos. Schaur dir dazu noch rsync an.
 
Nee ich meinte schon n komplettes Backup des Systems während es gerade rennt...

Im moment mach ichs immer manuell mit Clonezilla jedoch möchte ich es mehr automatisieren... Ich habe überlegt einfach auf 2 Sticks das gleiche system drauf zu haben.. Dann kann ich entweder manuell oder automatisch per cron ein reboot initiieren der dann aber quasi (dann bei jedem reboot alternierend) vom anderen stick bootet und dann eine backupprozedur startet die den Stick von dem jetzt nicht gebootet wurde ein backup image zieht!? Da muss ich wohl irgendwas im uboot einstellen bzw. muss mir noch überlegen wie ich das mache. Ist ja ein einfaches den beiden sticks ein anderes Label zu verpassen was dann bei jedem reboot bzw. jedem reboot das ein backup initiieren soll quasi in den uboot variablen so geändert wird dass es dann halt immer den stick zum booten wechselt.

Nur wollte ich jetzt nicht bei jedem boot irgendwas an den uboot variablen ändern lassen. Kann man ja vieles falsch machen bzw. hab ich schiss dass der Flash Speicher dann nach dem vielen rumgeschreibe dann den geist aufgibt!
 
Das könnte eventuell über ein "Rescue System" (also ein Minimalsystem) im NAND gehen. Ich gehe mal davon aus, dass du dein System vom USB-Stick laufen hast.
Im U-Boot könnte man (sofern es USB direkt unterstützt!) nach dem Label des angesteckten USB-sticks suchen lassen. Und sobald auch der Backup Stick gesteckt ist, könnte man ins Rescue-System im NAND booten und dort direkt per "init=" Commandline-Option das/ein Backup-Skript zum Klonen des Sticks aufrufen lassen.
Wie man sieht gibt es dafür aber einige Voraussetzungen.
Mit den V3 Pogos zum Beispiel hat man das Problem der fehlenden USB-unterstütung im standard U-Boot. :-)
Nur das klonen des aktiven Rootfs, ist im Normalfall, wie joph schon erwähnt hat, keine so gute Idee.
 
Also auf meiner Dockstar als auch dem GoFlex net ist das rescue v2.8.1 aus dem doozan forum drauf. Stimmt, man könnte ja einfach in das rescue system booten lassen jedoch finde ich die Idee mit den Label einfacher handzuhaben. Voraussetzung ist ja dann 2 USB Sticks.

Im moment ist mein uboot so eingestellt dass es einfach von einer Partition bootet die das Label "rootfs" hat.. Den anderen stick kann ich ja einfach das Label "rootfs2" verpassen und dann halt immer in den Uboot einstellungen bei reboot das Label umstellen wovon gebootet werden soll...
 
lochman schrieb:
Also auf meiner Dockstar als auch dem GoFlex net ist das rescue v2.8.1 aus dem doozan forum drauf. Stimmt, man könnte ja einfach in das rescue system booten lassen jedoch finde ich die Idee mit den Label einfacher handzuhaben. Voraussetzung ist ja dann 2 USB Sticks.

Im moment ist mein uboot so eingestellt dass es einfach von einer Partition bootet die das Label "rootfs" hat.. Den anderen stick kann ich ja einfach das Label "rootfs2" verpassen und dann halt immer in den Uboot einstellungen bei reboot das Label umstellen wovon gebootet werden soll...
Zum Vergrößern anklicken....

Ich glaube grade ich hab deinen Einsatzzweck ned ganz verstanden.
Wieso von Hand umstellen?

Dachte mir das Szenario so:

U-Boot environment prüft per Skript auf Label der angesteckten USB-Sticks.

Wenn Backup-Label da, und U-Boot Variable "backup_done" gleich "0" dann boot in Rescue-NAND, mit Ausführung des Backup-Skripts.
Backup Skript muss natürlich prüfen, ob Original- und Backup-Stick vorhanden.
Wenn beides vorhanden, und U-Boot Variable "backup_done" gleich 0, dann klonen und "backup_done" auf "1" setzen.

Sobald beim nächsten Boot der Stick mit dem Backup-Label weg ist, muss die Variable "backup_done" wieder umgesetzt werden. U-Boot scripting sollte's möglich machen. Aber nicht vorher umstellen, sonst gibt's endlos Backup, solange der Backup-Stick dran ist. :)


Keine Ahnung, ob ich das falsch verstanden hatte.
 
Brom2 schrieb:
Also ich mach ein Backup immer mit rdiff-backup. Das ist recht praktisch. Einige Ordner müssen aber ausgeschlossen werden, damit das Backup sich nicht selbst sichert und so. Hier ein link dazu Backup unter Linux mit rdiff-backup
Zum Vergrößern anklicken....

Ich glaube ja, dass lochmans Anliegen war eine wirkliche 1:1 Kopie seines aktuellen Rootfs-Sticks zu erstellen. Das dürfte mit rdiff nicht ganz optimal sein. Soweit ich weiß ist das eher für die Sicherung von Teildaten gedacht.

Davon mal abgesehen, wäre eventuell in so einem Fall über ein Raid 1 aus 2 USB-Sticks nachzudenken. Plus Sicherung lauffähiger Stände auf einen 3. Stick.
Das sollte zufällige Defekte und Fehlkonfiguration etc. abdecken.
Is aber nur so eine Idee.
 
Zuletzt bearbeitet:
Genau. also eine komplette kopie die ich dann als image speichere und bei bedarf über das rescue system wieder einspielen kann...

Also ich habe es halt so gedacht:
2 USB Sticks die beide das gleiche system beinhalten stecken auch beide in der Dockstar oder GoFlex Net.
USBStick1 hat das Label rootfs0; USBStick2 hat das Label rootfs1

Jetzt rennt die Dockstar bzw. GoFlex Net von dem Stick mit dem Label rootfs0 da auch im Uboot es so eingestellt ist dass es von rootfs0 bootet. Sobald es aber von diesem Stick gebootet wurde wird durch ein cronjob mit @reboot die Uboot Variable so geändert dass es beim nächsten boot von rootfs1 bootet. Sobald von rootfs1 gebootet wurde dann wird wieder die Uboot Variable auf rootfs0 umgeändert.. So bekomme ich ja bei z.B. jedem reboot (wobei ich wohl eher z.B. ein mal wöchentlich oder so so ein backup initiieren lassen würde und nicht bei JEDEM reboot).

Sobald das System gebootet wurde wird mit einem script kurz gecheckt wie weit der letzte backup her ist bzw. was für ne timestamp das backup image hat. Dann wird nach check ein Backup initiiert von dem Stick von dem nicht gebootet wurde. Das system rennt jetzt ca. ne woch von dem stick und es wird wieder ein reboot mit backup und allem pipapo initiiert.. So habe ich dann immer ein Image was max ne woche alt ist und lasse das system halt wechselnd von den einem und von dem anderen stick laufen...
Das wäre jetzt wohl die vollautomatische variante!

Eine auch sehr nette Variante ist die von dir vorgestellte mit dem Stick wo dann das system nach reboot erkennt dass dieser stick eingesteckt wurde und dann einfach ein backup von dem Systemstick gezogen wird.
Das wäre die halbautomatische variante...

Raid ist zwar auch ne nette idee aber ich will die USB sticks halt so gut wie möglich "schonen"!
 
Unter Vollbelastung, mit viel I/O scheint es Instabilitäten mit dem 3.1.10er Kernel zu geben. Darüber hinaus ist er in Sachen SATA- und USB-Übertragungsraten deutlich langsamer als der 2.6.31er Kernel.
Deshalb benutzt den fast kein Mensch.
 
Dann bleibe ich erstmal bei dem von shv. Ich habe mein System jetzt Wheezy geupdated und konnte endlich minidlna installieren. Beim Update zu wheezy ist jetzt aber folgende Fehlermeldung gekommen, die jetzt immer wieder beim Installieren von Software auftritt. Sonst läuft das System problemlos. Wie kann ich diese Fehlermeldung ausschalten?
update-initramfs: Generating /boot/initrd.img-2.6.32-5-kirkwood
Unsupported platform.
run-parts: /etc/initramfs/post-update.d//flash-kernel exited with return code 1
dpkg: error processing initramfs-tools (--configure):
subprocess installed post-installation script returned error exit status 1
configured to not write apport reports
Errors were encountered while processing:
initramfs-tools
Zum Vergrößern anklicken....
 
Kann es sein, dass du ne Pogoplug hast, aber im Rootfs dr Kirkwood Kernel installiert ist? Das würde genau die Meldungen erklären.
 
Ist nicht wirklich eine Antwort auf die Frage. Und hat ja keiner gesagt, dass der Kernel benutzt würde.
 
OK, du hattest wohl recht, /lib/modules enthält
2.6.31.14_OX820_1.0_shv
2.6.31.6_SMP_820
2.6.32-5-kirkwood

Das letzte ist ja wohl ein kirkwood-Kernel, wie der da hinkommt weiß ich aber nicht. Hab den Ordner jetzt einfach gelöscht. Leider hat das nicht die gewünschte Wirkung, es kommen an der gleichen Stelle noch Fehlermeldungen hinzu. Brauch ich dieses initramfs-tools denn überhaupt, ich könnte es ja einfach deinstallieren.
 
Brom2 schrieb:
OK, du hattest wohl recht, /lib/modules enthält
2.6.31.14_OX820_1.0_shv
2.6.31.6_SMP_820
2.6.32-5-kirkwood

Das letzte ist ja wohl ein kirkwood-Kernel, wie der da hinkommt weiß ich aber nicht. Hab den Ordner jetzt einfach gelöscht. Leider hat das nicht die gewünschte Wirkung, es kommen an der gleichen Stelle noch Fehlermeldungen hinzu. Brauch ich dieses initramfs-tools denn überhaupt, ich könnte es ja einfach deinstallieren.
Zum Vergrößern anklicken....

Das war wahrscheinlich nicht grade die beste Idee. Problem ist, dass der Kirkwood Kernel wohl offiziell über den Paketmanager installiert wurde. Deshalb "weiß" das System, dass der Kernel da ist, und will damit arbeiten.

Schau dir mal mit "dpkg -l" an, wie genau das installierte Kirkwood-Kernel-Paket heißt und versuch es mit "apt-get --purge remove 'kernel-name-kirkwood'" vom System zu schmeißen. Dann versucht das System auch nicht mehr damit was anzufangen. Aber deinstallier ja nicht das verkehrte Paket!
Und ja, solange du kein Initramfs nutzt, ist der automatische Vorgang eh sinnlos. Aber das ist eigentlich egal.
 
Also es gibt zwei mögliche Pakete.
lniux-image-2.6-kirkwood Linux 2.6 for Marvell Kirkwood (meta-package)
linux-image-2.6.32-5-kirkwood Linux 2.6.32 for Marvell Kirkwood

Kann ich beide bedenkenlos deinstallieren?
 
Mit apt-get purge linux-image-2.6.32-5-kirkwood wird der erste Eintrag mit entfernt. Kannst Du bedenkenlos durchführen.

@celemine1Gig:
Beim 14er Kernel scheint ein Fehler im 200-c-2.6.31.14-include.patch zu sein. Dabei werden 3 Zeilen entfernt, von denen 2 Ursache für das Problem mit der Kompilierung des PPP Treibers sind. Die 3 Zeilen (defines) bilden den Unterschied zur sock.h Datei des 6er Kernels. Wenn man aus diesem Grund die sock.h Datei aus dem 6er verwendet, läuft die Kompilierung des PPP Teibers durch.
 
shvde70 schrieb:
Mit apt-get purge linux-image-2.6.32-5-kirkwood wird der erste Eintrag mit entfernt. Kannst Du bedenkenlos durchführen.

@celemine1Gig:
Beim 14er Kernel scheint ein Fehler im 200-c-2.6.31.14-include.patch zu sein. Dabei werden 3 Zeilen entfernt, von denen 2 Ursache für das Problem mit der Kompilierung des PPP Treibers sind. Die 3 Zeilen (defines) bilden den Unterschied zur sock.h Datei des 6er Kernels. Wenn man aus diesem Grund die sock.h Datei aus dem 6er verwendet, läuft die Kompilierung des PPP Teibers durch.
Zum Vergrößern anklicken....

Sorry, ich glaub ich steh grade auf dem Schlauch. "PPP"-Treiber steht für???
 
PPP: Point to Point Protocol

Würde man z.B. für einen Internetzugang über UMTS Stick neben einem pppd benötigen. Alternativ könnte man auch einen direkten Internetzugang über PPPoE aufbauen.
 
Alles klar. Dann schreib mir mal schnell die Details der nötigen Änderung. Hätte schon einen 2.6.32.61er Testkernel. Ist aber noch ungetestet. Ich schau mal, ob er soweit läuft. Wenn ja, dann gibt's auch einen Link. ;)
 
Korrektur für den 14er Kernel nach Anwendung von telzey's include patch:
Code: 
--- include/net/sock.h.org      2013-04-03 21:14:45.902457770 +0200
+++ include/net/sock.h  2013-08-04 20:14:10.946536701 +0200
@@ -944,6 +944,7 @@ static inline void lock_sock(struct sock
 extern void release_sock(struct sock *sk);

 /* BH context may only use the following locking interface. */
+#define bh_lock_sock(_sk) bh_lock_wsock(_sk)
 #define bh_lock_wsock(_sk) do { \
        if (unlikely(!spin_trylock(&(_sk)->sk_lock.slock))) { \
                unsigned long end = jiffies + HZ; \
@@ -972,13 +973,13 @@ extern void release_sock(struct sock *sk
 //             } while (unlikely(!spin_trylock(&wlock->lock)));
 //     }
 //}
-
+#define bh_lock_sock_nested(_sk) bh_lock_wsock(_sk)
 #define bh_lock_wsock_nested(_sk) bh_lock_wsock(_sk)
 //static inline void bh_lock_wsock_nested(struct sock *sk)
 //{
 //     bh_lock_wsock(sk);
 //}
-
+#define bh_unlock_sock(_sk) bh_unlock_wsock(_sk)
 #define bh_unlock_wsock(_sk) spin_unlock(&(_sk)->sk_lock.slock)
 //static inline void bh_unlock_wsock(struct sock *sk)
 //{
 
huhu welche gui würde auf der goflex laufen!! hauptgrund möchte übers inet auf die gui um von da in den router zu kommen um einstellungen vorzunehmen!! da ich anders in das super teledoof ding nicht reinkomme :/
 
Da würde ich eher nen OpenVPN Tunnel ins Netz Zuhause aufbauen und darüber dann mit dem Browser auf den Router zugreifen.
Nicht nötig dafür die GoFlex mit nem Desktop zu belasten.
 
Anmelden, um zu antworten.
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh