Hallo Oliver,
nach langem hin und her und versuchen zu verstehen, wie unsere Patches denn doch auf Pakete angewendet werden habe ich jetzt halbwegs den Überblick. Korrigiert mich bitte, wenn ich mit meinen Beobachtungen falsch liege:
1. Wenn ein Paket neu gebaut wird, dann wird im ersten Moment alles aus dem Paket-Verzeichnis unter sorce gelöscht. Aus diesem Grund macht es wenig Sinn dort Änderungen zu machen, wenn man z.B. etwas "mal eben" an den Quellen verändern will, um etwas auszuprobieren. Das war mein Fehler und meine falsche Vermutung eine Stelle gefunden zu haben, wo man sich austoben kann.
2. Nun werden die Quellen neu entpackt. Meistens sind es bz2-Dateien, die unter dl liegen.
3. Es werden Patches angewendet, die unter make/package/patches liegen. Und ja, Oliver, deine Patches sind dort gelandet und werden erfolgreich angewendet.
4. Somit sind die Sachen unter source/package gepatcht und können kompiliert werden. Auch dies geschieht in unserem Fall, Oliver.
5. Am Schluss werden die Binaries und die Libraries an eine passende Stelle unter packages/root gepackt und landen irgendwann mal demnächst unter modified.
Jetzt würde ich gerne auch an den Quellen rumbasteln, habe aber keine Lust nach jedem Bastelvorgang einen patch zu erstellen, den ich nachher unter make/package/patches packen muss. Wie kann ich z.B. nur für Busybox Schritte 1-3 verbieten, damit die Sachen unter source unangetastet bleiben und damit ich mich dort austoben kann. Dein Tipp Oliver unter menuconfig diesen Overwrite-Schalter zu deaktivieren funktioniert definitiv nicht. Ich verstehe auch von der Logik her, dass man die Sourcen immer komplett löschen und frisch entpacken muss, damit man anschließend auch patches anwenden kann. Ich will es bloß temporär abschalten, um mit einer bewahrten printf-Methode zu erforschen, warum der Patch von Oliver nicht funktioniert.
EDIT: Oh, mann... Da gab es nochmal alle Sorcen unter "target" irgendwo abgelegt. Der Fehler war, dass dieses "target" anscheinend mit "make busybox-clean" nicht gelöscht wird. Ich blicke da langsam echt nicht durch, wie oft denn da alles hin und her kopiert wird. Kann das bitte jemand dokumentieren, der es bei uns sich ausgedacht hat? Es wäre echt eine Hilfe für solche experimentierfreudige wie ich zu verstehen, WO man noch eine Chance hat an den Sourcen anzupacken und WIE da überhaupt diese unzähligen hin- und her- Kopierereien funktionieren.
Mittlerweile kann meine so erstelle busybox alle Systeme erkennen:
Code:
root@fritz:/var/mod/bin# blkid
/dev/loop0: UUID="3b85c627-9dc1-4ed5-aa08-1fa5b17d92cb" TYPE="ext2"
/dev/sda1: LABEL="SYSTEM" UUID="457c1f4b-8aec-e4ee-6843-fcded6ae79dd" TYPE="ext2"
/dev/sda2: LABEL="FAT" UUID="9A64-8DAD" TYPE="vfat"
/dev/sda4: TYPE="swap"
/dev/sda5: LABEL="DATA" UUID="7b097c41-5282-7a79-feba-b9b0d63459e7" TYPE="ext2"
/dev/sda6: LABEL="ARCHIV" UUID="b1328ea0-2360-50da-6cc3-9adc5d42937d" TYPE="ext3"
/dev/sdb1: SEC_TYPE="msdos" LABEL="FAT" UUID="A47A-253A" TYPE="vfat"
/dev/sdb2: LABEL="SYSTEM" UUID="e914f1c2-f05d-20a7-db54-dea0c7c62ca1" TYPE="ext2"
/dev/sdb3: TYPE="swap"
/dev/sdb5: UUID="734F9388689A9439" LABEL="TEST-NTFS" TYPE="ntfs"
/dev/sdb6: LABEL="EXT3" UUID="3e602d35-9e47-7595-2e48-fbc7e28e4aeb" TYPE="ext3"
/dev/sdb7: UUID="5BA928F435130FDD" LABEL="NTFS2" TYPE="ntfs"
root@fritz:/var/mod/bin# ./busybox findfs DEV=/dev/sda
root@fritz:/var/mod/bin# ./busybox findfs DEV=/dev/sda1
SYSTEM
root@fritz:/var/mod/bin# ./busybox findfs DEV=/dev/sda2
FAT
root@fritz:/var/mod/bin# ./busybox findfs DEV=/dev/sda3
root@fritz:/var/mod/bin# ./busybox findfs DEV=/dev/sda4
root@fritz:/var/mod/bin# ./busybox findfs DEV=/dev/sda5
DATA
root@fritz:/var/mod/bin# ./busybox findfs DEV=/dev/sda6
ARCHIV
root@fritz:/var/mod/bin# ./busybox findfs DEV=/dev/sda7
root@fritz:/var/mod/bin# ./busybox findfs DEV=/dev/sdb1
FAT
root@fritz:/var/mod/bin# ./busybox findfs DEV=/dev/sdb2
SYSTEM
root@fritz:/var/mod/bin# ./busybox findfs DEV=/dev/sdb3
root@fritz:/var/mod/bin# ./busybox findfs DEV=/dev/sdb4
root@fritz:/var/mod/bin# ./busybox findfs DEV=/dev/sdb5
TEST-NTFS
root@fritz:/var/mod/bin# ./busybox findfs DEV=/dev/sdb6
EXT3
root@fritz:/var/mod/bin# ./busybox findfs DEV=/dev/sdb7
NTFS2
root@fritz:/var/mod/bin# ./busybox findfs DEV=/dev/sdb8
Als Image habe ich es allerdings noch nicht getestet.
@Oliver: Hilfetexte stehen als defines unter include/usage.h. Suche da einfach nach "findfs", da wirst du fündig. Es wäre schon schön da unter usage diese neue Funktion zu dokumentieren. Sonst fährt man ganz blind. Würde man usage auch ändern, wäre es ein zusätzliches Indiz dafür, dass deine Patches angewendet wurden. Und wie wir sehen, tun sie es aus unerklärlichen Gründen nicht immer. Daher wäre es schon alleine deswegen sinnvoll usage auch zu patchen.
EDIT 2:
So in etwa meine ich es:
Code:
root@fritz:/var/mod/bin# ./busybox findfs
BusyBox v1.18.4 (2011-05-15 13:08:20 CEST) multi-call binary.
Usage: findfs LABEL=label or UUID=uuid or DEV=/dev/sdx
Find a filesystem device based on a label or UUID
or show label for defined device (FREETZ specific)
Um dies allerdings letztendlich im Binary vorzufinden musste ich unter make/busybox/busybox.mk durch auskommentieren zwei Zeilen das Runterladen der Quellen und das Entpacken verbieten. Dann in VIER Dateien die gleiche Passage einführen:
Code:
#define findfs_trivial_usage \
"LABEL=label or UUID=uuid or DEV=/dev/sdx"
#define findfs_full_usage "\n\n" \
"Find a filesystem device based on a label or UUID" \
"\nor show label for defined device (FREETZ specific)"
#define findfs_example_usage \
"$ findfs LABEL=MyDevice" \
"\n$ findfs DEV=/dev/sda1"
erst dann landete es im Applet. Vier Dateien waren je beiden: usage.h und usage.src.h jeweils unter source/host-tools und unter source/target... Ich blicke da echt sonst nicht durch, wann dort wo landet.
Ein der entscheidener Punkte scheint zu sein, dass usage.h wahrscheinlich während des Kompilierens aus usage.src.h irgendwie generiert wird. Sonst kann ich mir nicht erklären, warum alle meinen Eintragungen in usage.h nach dem Kompilieren immer weg waren.
Oh mann, oh mann, oh mann... Muss es denn so kompliziert sein? Oliver, du hattest irgendwann mal gesagt, dass man durch meine Sourcen in Shell-Skripten nur schwer durchsteigt. Ich würde diese Mechanismen hier bei uns mit dem drei- und vierfachen hier und her Kopieren von Sourcen als viel schlimmer betrachten. Bei meinen Skripten wirst du es wenigstens nach dem dritten oder vierten durchlesen vielleicht kapieren. Hier steigt aber tatsächlich keiner mehr durch, wie rum und wohin da alles kopiert wird und vor allem, welche Überbleibsel denn wo danach bleiben, die einen neuen Kompiliervorgang stören.
EDIT 3: Image ist nun auf der Box drauf. Sowohl deine Sachen, Oliver, als auch mein Hilfetext ist definitiv drin:
Code:
root@fritz:/var/mod/root# busybox findfs
BusyBox v1.18.4 (2011-05-15 13:08:20 CEST) multi-call binary.
Usage: findfs LABEL=label or UUID=uuid or DEV=/dev/sdx
Find a filesystem device based on a label or UUID
or show label for defined device (FREETZ specific)
root@fritz:/var/mod/root# busybox findfs /dev/sda1
vfat
root@fritz:/var/mod/root# busybox findfs DEV=/dev/sda1
FAT
Dennoch will er über FREETZMOUNT die Partitionen nicht einbinden. Im AVM-Log steht, dass er die Partition mit dem jeweils richtig erkannten Typ (z.B. NTFS oder FAT oder EXT2) nicht einbinden kann, weil er so ein Typ nicht unterstützt. Ich schaue mal, ob ich die Partitionen erstmal "zufuss" einbinden kann und suche nachher nach dem Fehler.
Ansonsten wäre es natürlich geile Sache mit diesem Applet sowohl Typ, als auch Label zu erkennen (s. oben in meinem Beispiel)
MfG
