IDE Menü

[tomworld]

das ist mir schon klar @dixidix

jetzt habe ich mal folgendes gemacht, da ich alle Daten von HDD und MMC gesichert habe
keine Swap auf der HDD, mit "BETA! 1.52", aber auf der MMC (ist bei mir eine SD-Karte auf den HDD-IF) eine Swap von 64 MB angelegt, wird auch angezeigt

dann ein Image mit "BETA! 1.53" gebaut und die MMC nach den Flashen wieder aktiviert, was auch klappt
aber es werden im System nicht 64 MB, sondern 128 MB angezeigt

Tenet mit df -h und free:

Code: Alles auswählen

Nokia D-BOX2 - Kernel 2.4.37.9-dbox2 (15:40:11).
dbox login: root


BusyBox v1.14.4 (2010-03-31 14:56:13 CEST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

~ # df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                 5.1M      5.1M         0 100% /
tmp                     128.0M     12.0K    128.0M   0% /tmp
/dev/mtdblock/3           2.6M   1012.0K      1.6M  38% /var
/dev/mmc/disc0/part2    904.5M      1.1M    903.4M   0% /mnt/mmc
~ # free
              total         used         free       shared      buffers
  Mem:        30884        23324         7560            0         3008
 Swap:        65552            0        65552
Total:        96436        23324        73112
~ #

gegentest, lösch die Swap auf der MMC und lege eine mit 128 MB an, geht nicht, was ja auch logisch ist , da ja kein Platz mehr ist
ich finde es nicht Dramatisch, da es ein Flash eines Image ist, auf ein zuvor eingerichteten System und ja auch die zuvor eingerichteten 64 MB im System erscheinen, wenn ich dies auf der MMC wieder richtig neu formatiere, wird es auch richtig erkannt im System:

Code: Alles auswählen

Nokia D-BOX2 - Kernel 2.4.37.9-dbox2 (16:34:53).
dbox login: root


BusyBox v1.14.4 (2010-03-31 14:56:13 CEST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

~ # df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                 5.1M      5.1M         0 100% /
tmp                      64.0M     32.0K     64.0M   0% /tmp
/dev/mtdblock/3           2.6M      1.0M      1.6M  38% /var
/dev/mmc/disc0/part2    904.5M      1.1M    903.4M   0% /mnt/mmc
~ # free
              total         used         free       shared      buffers
  Mem:        30884        25400         5484            0         3304
 Swap:        65552            0        65552
Total:        96436        25400        71036
~ #

Samba läuft auch nur mit MMC/SD, deshalb sind jetzt 32.0K im /tmp

ein weiteres Problem ist die Option -> Erweitert -> Zurücksetzen, es verbleiben in /var/etc/ (squashfs-Image)
K06hdd
K07mounts
K31sambaserver
S06hdd
S07mounts
S31sambaserver
ich denke, das man diese auch dann entfernt über das Menü mit der Option Zurücksetzen

mehr habe ich jetz nicht gefunden auf die schnelle

[dbt]

Wenn MMC nicht gerade schneller ist als eine Platte würde ich da aber kein MMC/SD als swap nehmen. MMC ist eigentlich nicht so der Kandidat für sowas, wenn es nicht gerade ein Hightechteil mit Highspeed>HDD-Speed ist, was man in der Regel bezweifeln darf.

[tomworld]

deswegen nutze ich auch kein Swap, weder auf HDD noch SD, war ja nur mal zum test

das 64 <-> 128 MB Problem ist aber auch mit Swap auf der HDD

Code: Alles auswählen

Nokia D-BOX2 - Kernel 2.4.37.9-dbox2 (22:55:46).
dbox login: root


BusyBox v1.14.4 (2010-03-31 14:56:13 CEST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

~ # df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                 5.1M      5.1M         0 100% /
tmp                     128.0M     20.0K    128.0M   0% /tmp
/dev/mtdblock/3           2.6M    732.0K      1.9M  27% /var
/dev/ide/host0/bus0/target0/lun0/part2
                         18.6G    172.1M     18.4G   1% /mnt/hdd1
/dev/mmc/disc0/part1    968.5M     27.7M    940.8M   3% /mnt/mmc
~ # free
              total         used         free       shared      buffers
  Mem:        30884        25956         4928            0         3080
 Swap:        65984            0        65984
Total:        96868        25956        70912
~ #

[tomworld]

"BETA! 1.54" läuft

löscht auch alles ausser in /var/conf/ die drivesetup.conf beim Zurücksetzen

[dbt]

Die wird auch nicht gelöscht, sondern nur zurückgesetzt, also alles auf Standard.

[tomworld]

hi,

ich merke das meine HDD mit Swappartition (128 MB) beim Flashen anläuft und schliesse daraus das Swap über HDD funktioniert
bei Aufnahmen läuft die HDD ehe und macht keine Probleme

mehr Last konnte ich noch nicht erzeugen

[rhabarber1848]

Die Diskussion über Samba2 habe ich aus diesem Thread soeben
ausgeschnitten und hier abgelegt:
http://www.tuxbox-cvs.sourceforge.net/f ... =7&t=49272

[dbt]

...
P.S.: Die Mount- und Unmount-Skripte fehlen doch sehr. Ich habe jetzt mal probeweise den Sambaserver auf der CF-Karte gestartet. Leider klappt danach das unmounten der CF-Karte aus dem Menü heraus nicht mehr. Man muss die 2 Deamons erst wieder per Telnet abschießen. Wenn dies automatisch vor dem unmounten über ein Unmount-Skript gemacht werden könnte und nach dem mounten der gewünschte Deamon wieder gestartet werden könnte, wäre das schon Spitze.



Es wäre also wünschenwert, die Mount- und Unmount-Skripte baldmöglichst zu programmieren.

Greetz von DrStoned

Für Experten ein kleine Anmerkung noch dazu:
Man braucht den Sambaserver jetzt nicht mehr auszulagern, weil der 2.2.12er mit LFS ja jetzt bei Bedarf mitgebaut wird. Sollte man die smb-Binaries dennoch nicht ins Image packen wollen, kann man per Customizing, Symmlinks nach /bin auf die Binaries setzen, nach /var/bin schieben oder per Symlink auf Platte oder SD auslagern. Das sollte gehen. Das Killen mittels Script ist aber normalerweise jetzt nicht mehr nötig, sofern man ihn auf ein eigene Partition ausgelagert hat, weil man ja für die jeweilige Partition die Option "Für Samba freigeben" einstellen kann, weis das Menü ja, dass es was killen muss und erledigt das automatisch mit, falls der Server laufen sollte. Falls man den Server trotzdem auf Platte oder SD auslagern möchte, sollte man ihn mitkompileren und auch strippen (...und für den späteren Gebrauch aufheben) und empfehle folgende Partitionierungs-Schema auf Master:

• *swap
• *daten
• *bin

Die Binaries sollten dann logischerweise auf die bin-Partition installiert werden. Ist z.B. daten freigegeben, wird beim unmounten automatisch auch der server angehalten. Wichtig ist halt, dass die Partition auf der die Binaries liegen immer die letzte auf dem jeweiligen Laufwerk ist, weil z.B. beim Übernehmen oder Alle aushängen beim Aushängen die Partitionen der Reihe nach abgearbeitet werden und es zum Fehler kommen kann, wenn die Partition zuerst ausgehangen soll, auf der der Server läuft.
In diesem Fall und auch sonst helfen dann natürlich die Scripte wie gehabt.

PS: Der Server wird, sofern Freigaben festgelegt wurden, beim Übernehmen automatisch mit gestartet, jedoch nicht beim manuellen Mounten, das kann man dann manuell entweder im Netzwerkmenü->Sambaserver oder im im Untermenü der jeweiligen Partition unter Globale Sambaeinstellungen machen

Edit: Eine Anleitung zum Auslagern folgt noch

[rhabarber1848]

Die Binaries sollten dann logischerweise auf die bin-Partition installiert werden.

http://article.gmane.org/gmane.comp.vid ... x.scm/2182

Wie wäre es "/hdd/bin" in cdk/root/etc/profile hinzuzufügen?

EDIT: Du bist aber schnell

[dbt]

Symlinks dürften so auch nicht mehr notwendig sein, nur muss ich mal ne genaue Anleitung zusammenbauen wie man das mit dem Auslagern macht, das ist wohl nicht so ganz ohne.

[rhabarber1848]

nur muss ich mal ne genaue Anleitung zusammenbauen wie man das mit dem Auslagern macht, das ist wohl nicht so ganz ohne.

Da habe ich seit längerem eine Idee für eine neue configure-Option (@seife & Barf: sorry ):

cdk/configure --with-external-bin="bin/smbd bin/nmbd bin/links_g"

Alle dort aufgeführten Dateien werden nach dem Durchlauf von mklibs.py,
aber vor dem Erstellen des root-Images nach $(prefix)/cdkflash/external_bin/
verschoben und können vor dort aus weiter verwendet werden.

[dbt]

Ist vlt. nicht mal so schlecht.

[FlatTV]

Die Binaries sollten dann logischerweise auf die bin-Partition installiert werden.

http://article.gmane.org/gmane.comp.vid ... x.scm/2182

Wie wäre es "/hdd/bin" in cdk/root/etc/profile hinzuzufügen?

EDIT: Du bist aber schnell

was für hdd gilt, sollte dann aber auch für mmc Gültigkeit haben.

cu FlatTV

[dbt]

Kann man, aber bist du sicher, dass es sinnvoll ist, ausführbare Bins vonner lahmen Karte zu starten?

[dbt]

nur muss ich mal ne genaue Anleitung zusammenbauen wie man das mit dem Auslagern macht, das ist wohl nicht so ganz ohne.

Da habe ich seit längerem eine Idee für eine neue configure-Option (@seife & Barf: sorry ):

cdk/configure --with-external-bin="bin/smbd bin/nmbd bin/links_g"

Alle dort aufgeführten Dateien werden nach dem Durchlauf von mklibs.py,
aber vor dem Erstellen des root-Images nach $(prefix)/cdkflash/external_bin/
verschoben und können vor dort aus weiter verwendet werden.

Da fällt mir nochwas dazu ein, wenn man generell sowas wie ein Binary-Store anlegt, wo alle fertigen ungestrippten Binaries drin liegen würden wo sich Make bei Bedarf bedient anstatt komplett neu zu bauen, das würde Speed beim Bauen bringen. Fragt sich nur, ob das überhaupt so möglich ist, wegen diverser Abhängigkeiten, aber das wär mal was.

[rhabarber1848]

wo alle fertigen ungestrippten Binaries drin liegen würden

In meinem Entwurf liegen dort gestripte binaries, die ansonsten im Flashimage
drin wären, aus Platzgründen aber auf HDD ausgelagert werden sollen. Diese
Idee entstand im Rahmen der Strategie, customization-Skripts so weit wie
möglich überflüssig zu machen.

Fragt sich nur, ob das überhaupt so möglich ist, wegen diverser Abhängigkeiten

Das ist des Pudels Kern

[rhabarber1848]

wo sich Make bei Bedarf bedient anstatt komplett neu zu bauen

Meinen Vorschlag, die toolchain zu recyclen, kennst Du?

[dbt]

Ansatzweise, wenn es hilft, dass nicht immer bei jedem Poops, ein Komplettneubau veranstatltet wird, ist mir das recht.

[rhabarber1848]

Ansatzweise, wenn es hilft, dass nicht immer bei jedem Poops, ein Komplettneubau veranstatltet wird, ist mir das recht.

http://www.tuxbox-cvs.sourceforge.net/f ... 24#p371124

[rhabarber1848]

cdk/configure --with-external-bin="bin/smbd bin/nmbd bin/links_g"

Alle dort aufgeführten Dateien werden nach dem Durchlauf von mklibs.py,
aber vor dem Erstellen des root-Images nach $(prefix)/cdkflash/external_bin/
verschoben und können vor dort aus weiter verwendet werden.

Hier geht es weiter: http://www.tuxbox-cvs.sourceforge.net/f ... =7&t=49283

[Striper]

Bei kleinen SD Karten gibt es mit dem largefile Parameter bei der Formatierung recht schnell Probleme mit den inodes. Wenn man viele Files auslagert kommt schnell mal: "no space left on device" obwohl eigentlich noch genug Platz ist.

Zuerst dachte ich das dieser Patch das schön erschlagen würde:

Code: Alles auswählen

--- ./tuxbox_source/apps/tuxbox/neutrino/src/gui/drive_setup.cpp	2010-05-03 17:03:35.581317467 +0200
+++./source/apps/tuxbox/neutrino/src/gui/ drive_setup.cpp	2010-05-19 18:47:51.740846565 +0200
@@ -3600,8 +3600,8 @@
 
 const fstype_struct_t fstype[MAXCOUNT_FSTYPES] =
 {
-	{"ext2", 	"-T largefile -m0 -q -I 128", 	"-y -v"},
-	{"ext3",	"-T largefile -m0 -q -I 128", 	"-y -v"},
+	{"ext2", 	"-T journal -m0 -q -I 128", 	"-y -v"},
+	{"ext3",	"-T journal -m0 -q -I 128", 	"-y -v"},
 	{"msdos", 	"", 			"-y"},
 	{"vfat", 	"", 			"-y"},
 	{"reiserfs", 	"-f", 			"-f -y "},

Allerdings wird dadurch auf großen Platten unglaublich viel Platz durch die dann viel zu hohe Anzahl an inodes verschwendet. "journal" erstellt ein inode (128 Byte?!) pro 8 kB. "largefile" erstellt ein inode pro 1024 kB. Am besten wäre vermutlich eine Lösung die abhängig vom Speicherplatz auf dem Medium den richtigen Parameter wählt. Z.B. > 4 GB largefile / < 4 GB journal.

[dbt]

Edit:
Noch etwas: Bei Druck auf "Übernehmen" wird immer etwas ausgeführt, auch wenn nichts geändert wurde....

Das sollte jetzt nicht mehr so sein. Man wird auch zwangsläufig daran erinnert, falls man nicht übernommen hat.

[FlatTV]

Hier noch einmal etwas zu dem von Striper angesprochenem Problem...

~Zitat:
"So, habe mir heute meine CF-Karte zerlegt und die Karte neu formatiert.
Beim Versuch, Dateien auszulagern wurden mir allerdings ständig Fehler produziert.
Im Telnet kam ich schnell darauf, dass die Karte angeblich(!) voll war und darum nichts geschrieben werden konnte ...
Nachdem ich die Karte mit

Code: Alles auswählen

mkfs.ext3 -T journal -m0 /dev/ide/host0/bus0/target1/lun0/part2

formatiert und dadurch mehr inodes zur Verfügung gestellt habe, geht wieder alles wie gewohnt!"

Das sollte man vielleicht nochmal ändern

cu FlatTV

[dbt]

Ja, wäre ratsam. Largefile hatte ich so aus dem alten Menü übernommen, wenn es mit journal besser ist, kein Problem.

[Miky1968]

Bei kleinen SD Karten gibt es mit dem largefile Parameter bei der Formatierung recht schnell Probleme mit den inodes. Wenn man viele Files auslagert kommt schnell mal: "no space left on device" obwohl eigentlich noch genug Platz ist.
......
Allerdings wird dadurch auf großen Platten unglaublich viel Platz durch die dann viel zu hohe Anzahl an inodes verschwendet. "journal" erstellt ein inode (128 Byte?!) pro 8 kB. "largefile" erstellt ein inode pro 1024 kB. Am besten wäre vermutlich eine Lösung die abhängig vom Speicherplatz auf dem Medium den richtigen Parameter wählt. Z.B. > 4 GB largefile / < 4 GB journal.

Habs einfach mal nur zitiert, denn nur journal oder nur largefile scheint ja auch nicht die Lösung zu sein.