busybox: Filesystem-Applets

Zur Zeit steht bei mir:
Code:
#
# Build system options
#
FREETZ_VERBOSITY_LEVEL=2
FREETZ_JLEVEL=2
# FREETZ_CHECK_CHANGED is not set
# FREETZ_BACKUP_CONFIG_CACHE is not set
Ich kann aber nicht versprechen, dass es immer so war. Ich hatte auch teilweise nach dem "precompiled" ein komplettes "make" durchlaufen lassen. An sich sollte er dabei nicht mehr kompilieren. Ob es irgendwelche Auswirkungen hatte, weiß ich nicht.
Es scheint so gewesen zu sein, dass die Sachen unter
Code:
/home/freetz/7270/source/target-mipsel_uClibc-0.9.29/ref-16mb
generell erstmal nicht gelöscht werden, wenn man "make busybox-clean" ausführt. Und diese Sachen sind letztendlich für die busybox-binary entscheidend. Bei mir hat es geholfen dieses Verzeichnis "ref-16mb" zu umbenennen. Dann hat er die Sachen neu gebaut und deine Patches erfolgreich angewendet. Vorher lagen unter "ref-16mb" immer die alten Sourcen ohne deine Patches. Das kann man ganz schön am Datum der Datei sehen.

Nun habe ich aber ein anderes Problem auf der Box selbst. Irgendwie will er bei mir nicht mounten:

Code:
root@fritz:/var/mod/root# findfs /dev/sda2
ext2
root@fritz:/var/mod/root# findfs DEV=/dev/sda2
SYSTEM
root@fritz:/var/mod/root# mount -t ext2 /dev/sda2 /var/mod/root/test -o noatime,nodiratime,rw,async
mount: mounting ext2 on /var/mod/root/test failed: No such file or directory
root@fritz:/var/mod/root# ls -la /var/mod/root
drwxr-xr-x    4 root     root             0 May 15 14:03 .
drwxr-xr-x   11 root     root             0 Jan  1  2000 ..
drwxr-xr-x    3 root     root             0 May 15 13:58 .mc
lrwxrwxrwx    1 root     root            23 Jan  1  2000 .profile -> /tmp/flash/mod/.profile
lrwxrwxrwx    1 root     root            31 Jan  1  2000 .ssh -> /tmp/flash/authorized_keys_root
drwxrwxrwx    2 root     root             0 May 15 14:03 test
Die Fehlermeldung verstehe ich nicht. Module sind auch da:
Code:
root@fritz:/var/mod/root# modprobe -l | grep -E "ext|fat|ntfs"
kernel/fs/vfat/vfat.ko
kernel/fs/ext2/ext2.ko
kernel/fs/fat/fat.ko
kernel/drivers/net/wireless/avm_ath_extensions.ko
kernel/fs/ext3/ext3.ko
Warum kann ich nicht mounten?

EDIT:
Die ältere busybox kann mounten:
Code:
root@fritz:/var/mod/bin# ./busybox mount -t ext2 /dev/sda2 /var/mod/root/test -o noatime,nodiratime,rw,async
root@fritz:/var/mod/bin# mount
rootfs on / type rootfs (rw)
/dev/root on / type squashfs (ro)
dev on /dev type tmpfs (rw,nosuid)
devpts on /dev/pts type devpts (rw)
proc on /proc type proc (rw,nosuid,nodev,noexec)
tmpfs on /var type tmpfs (rw)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec)
/dev/mtdblock5 on /data type jffs2 (rw)
/dev/loop0 on /var/media/ftp type ext2 (rw)
usbfs on /proc/bus/usb type usbfs (rw)
/dev/sda2 on /var/mod/root/test type ext2 (rw,noatime,nodiratime)
Irgendwie habe ich mit meinen Experimenten die "mount"-Sektion anscheinend "zerschossen".

EDIT 2: Jetzt habe ich ref-Verzeichnis umbenannt, alle meine Sachen aus busybox.mk entfernt, sodass busybox neu gebaut werden konnte. Jetzt ist busybox auch etwas kleiner geworden (meine Hilfetexte sind weg), trotzdem bleibt "mount" in dieser Version "zerschossen". Ich versuche jetzt noch deine Patches zu entfernen und neu zu bauen. Mal sehen...

EDIT 3: Die empfohlene Option "FREETZ_CHECK_CHANGED" scheint doch einige weiteren fatalen Folgen mit sich zu bringen. Ich habe sie erstmal wieder aktiviert. Seitdem baut er bei mir jetzt brav ziemlich viel neu. Eine der fatalen Folgen war, dass z.B. libmodmount.sh unter source gepatcht war, unter build/modified landete aber eine alte Version.
Das ist genau das, worüber ich mich hier seit mehreren Beiträgen ärgere: Du hast überhaupt keinen Durchblick was denn von den gepatchten Änderungen überhaupt unter modified landet und was nicht. Diese ganze Kopirerei und patcherei ist inzwischen ein Wodoo-Zeug, wo nur ganz wenige von uns durchblicken, wie sie tatsächlich funktioniert.

Edit4: Na toll... Da wieder diese Patcherei:

Code:
applying patch file make/sispmctl/patches/100-disable-debug.patch
patching file src/main.c
----------------------------------------------------------------------
applying patch file make/sispmctl/patches/200-daemon.patch
patching file src/main.c
----------------------------------------------------------------------
applying patch file make/sispmctl/patches/sispmctl_daemon.patch
patching file src/main.c
Hunk #1 succeeded at 42 with fuzz 2 (offset 2 lines).
Hunk #2 FAILED at 55.
Hunk #3 FAILED at 486.
Hunk #4 FAILED at 651.
Hunk #5 succeeded at 323 with fuzz 2 (offset -371 lines).
3 out of 5 hunks FAILED -- saving rejects to file src/main.c.rej
----------------------------------------------------------------------
ERROR: modpatch: Error in patch-file make/sispmctl/patches/sispmctl_daemon.patch
make: *** [source/target-mipsel_uClibc-0.9.29/sispmctl-3.0/.unpacked] Fehler 2


MfG
 
Zuletzt bearbeitet:
Der Changes Check baut ein Paket neu, wenn du was am Makefile oder den Patches änderst. Dann gibt es noch die Rebuild Subopts. Die bauen ein Paket neu, wenn du was an den Optionen im menuconfig änderst.

Unter source werden keine Package-Dateien hinkopiert, von daher weiß ich nicht was da libmodmount zu suchen hat.

Alles was unter modified landet kommt aus packages. Sourcen werden in source entpackt und gebaut. Die Binaries dann nach packages kopiert.

Gruß
Oliver
 
Es war nicht sources, sondern make/root. Da habe ich mich in diesem Dschungel vertan.
Mittlerweile habe ich festgestellt, dass es difinitiv an deinem Patch "findfs.patch" liegt, dass ich nicht mounten kann. Woran es genau liegt, weiß ich allerdings nicht. Auffällig ist bei den busybox-Patches, dass zusammen mit deinem da jetzt 3 Stück an der zahl sind, die keine Zahl am Anfang vom Namen stehen haben. Rein alphabetisch gesehen würden zunächst alle Patches mit den Zahlen ausgeführt, danach kommt "blkid_support_fstype.patch", dann käme "findfs.patch" und zum Schluss wäre noch "revert_crtscts_fix.patch" durchzuführen. Kann es sein, dass dein findfs.patch da etwas in der Reihenfolge durcheinander bringt?
Zweite Vermutung wäre, dass "mount" in irgendeiner Form auf die Funkionen zugreift, die du für findfs gepatcht hast. Da dabei eine andere Antwort kommt, als "mount" erwartet, schlägt es fehl.

Hast du denn so eine busybox bei dir getestet, oder bin ich der erste alpha-Tester?

EDIT: Das Problem mit dem mount scheint diese Passage hier zu verursachen:
Code:
@@ -303,7 +336,12 @@
 		tmp = get_devname_from_uuid(*fsname + 5);
 	else if (strncmp(*fsname, "LABEL=", 6) == 0)
 		tmp = get_devname_from_label(*fsname + 6);
-
+	else if (strncmp(*fsname, "DEV=", 4) == 0)
+		tmp = get_label_from_devname(*fsname + 4);
+#if ENABLE_FEATURE_BLKID_TYPE
[B][COLOR="red"]+	else if (strncmp(*fsname, "/dev/", 5) == 0)
+		tmp = get_type_from_devname(*fsname);
[/COLOR][/B]+#endif
 	if (tmp == *fsname)
 		return 0; /* no UUID= or LABEL= prefix found */
Wir dürfen es also nicht so direkt mit /dev/sdx ohne Parameter ansprechen, weil es anscheinend mount der Busybox inirgendeiner Form nutzt.

Da mir deine "undokumentierte" Ausgabe von findfs sowieso nicht ganz gefällt, lass uns mal doch bitte die Eingangsparameter zu überdenken.
Von mir aus können wir es mit "DEV=" so machen, wie du es vorgeschlagen hast. Ich würde allerdings noch weiter gehen und auch noch dieses undokumentierte /dev/sdx (ohne DEV=) zulassen und zwar mit der gleichen Auswirkung, wie mit "DEV=".
Die Ausgabe würde ich dagegen über einen zusätzlichen Parameter steuern. Z.B. FILTER=UUID oder FILTER=LABEL oder FILTER=TYPE. Ohne Filter würde ich entweder alle (wie blkid) oder z.B. nur TYPE ausgeben. Anstatt "FILTER=" kann man evtl. mit optionen spielen: -f UUID oder --filter LABEL.

Dies würde die Sache etwas universeller machen. ich weiß auch, dass du UUID noch nicht gefiltert hast. Das kann man dann später einfügen.

EDIT 2: Eine progmatische Lösung, die funktioniert wäre DEVT= und DEVL= zu verwenden:
Code:
@@ -303,7 +336,12 @@
 		tmp = get_devname_from_uuid(*fsname + 5);
 	else if (strncmp(*fsname, "LABEL=", 6) == 0)
 		tmp = get_devname_from_label(*fsname + 6);
-
+	else if (strncmp(*fsname, "DEVL=", 5) == 0)
+		tmp = get_label_from_devname(*fsname + 5);
+#if ENABLE_FEATURE_BLKID_TYPE
+	else if (strncmp(*fsname, "DEVT=", 5) == 0)
+		tmp = get_type_from_devname(*fsname + 5);
+#endif
 	if (tmp == *fsname)
	        return 0; /* no UUID= or LABEL= prefix found */
Sie liefert dann:
Code:
root@fritz:/var/mod/bin# ./busybox findfs DEVL=/dev/sda1
FAT
root@fritz:/var/mod/bin# ./busybox findfs DEVT=/dev/sda1
vfat
root@fritz:/var/mod/bin# ./busybox mount -t ext2 /dev/sda2 /var/mod/root/test -o noatime,nodiratime,rw,async
root@fritz:/var/mod/bin# umount /dev/sda2

Ich schaue gleich noch, was man unter FREETZMOUNT ändern muss, damit es auch mit dieser geänderten Variante läuft.

MfG
 
Zuletzt bearbeitet:
Erste halbwegs funktionierende Variante

Hallo zusammen,

anbei ist meine erste Anpassung am Patch von Oliver. Veränderungen:
1. DEVL=... und DEVT=... anstatt DEV= und ohne DEV vorher
2. Anpassungen sowohl im Patch, als auch in FREETZMOUNT.
3. Zwei Busybox-Patches habe ich nun mit 910 und 920 davor versehen. Daher ist mein svn diff so groß geworden.

Man kann es im Prinzip so einchecken. Allerdings mit einer Einschränkung: SWAP-Erkennung funktioniert nicht. Daher wird SWAP nicht eingebunden. Das scheint busybox-weit zu sein, blkid ist auch betroffen. Ich weiß nicht warum, man muss nachforschen. Eigentlich sind es Überbleibsel vom Patch Ende März, die nicht gehen. Aber wahrscheinlich hat es bis jetzt ehe keiner gebraucht und daher bemerkt, dass SWAP eigentlich nicht geht.

EDIT: Wenn wir es noch mit SWAP hinkriegen würden, wäre ich sehr dafür, es möglichst bald einzuchecken. Damit hätten wir aber wirklich alle Fliegen mit einer Klappe geschlagen. Paket fstyp hätte man komplett aufgeben können und stattdessen einen Einzeiler-Wrapper schreiben, der dann findfs DEVT=$1 enthalten würde. Ich weiß, dass Oliver anstatt Wrapper wahrscheinlich einen Symlink angedacht hatte, aber was sollst. Wir wollen ja nicht übertreiben. Dann hätten wir nur eine Baustelle, nämlich busybox, an der wir basteln würden und nicht drei, wie jetzt (busybox, blkid von e2fsprogs, fstyp).

MfG
 

Anhänge

  • busybox_findfs_01.patch.txt
    34.7 KB · Aufrufe: 4
Zuletzt bearbeitet:
Brauchen wir den ersten Hunk des findfs-Patches noch? Wenn du mit DEVL und DEVT aufrufst, dann brauchen wir doch das verhalten von "findfs /dev/sda1" nicht ändern?

Was ist das Problem mit Swap? libmodmount oder findfs?

Gruß
Oliver

edit: Es fehlt dann noch die ext4-Unterstützung.
 
Brauchen wir den ersten Hunk des findfs-Patches noch? Wenn du mit DEVL und DEVT aufrufst, dann brauchen wir doch das verhalten von "findfs /dev/sda1" nicht ändern?
Das habe ich jetzt nicht kapiert, sorry. Was meinst du damit? Kannst du bitte etwas ausführlicher rausholen?

Aber mit DEVL und DEVT würdest du grundsätzlich mitgehen? Oder willst du es anders lösen?

Was ist das Problem mit Swap? libmodmount oder findfs?
Es funktioniert gänzlich nicht. In der ganzen busybox. Auch wenn du mit blkid die Partitionen auflistest, findet er die SWAP-Partition nicht und mit findfs auch nicht. Es scheint ein grundsätzliches Problem zu sein. Ich hatte mich doch vor ein Paar Wochen oder Monaten bereits darüber beschwert, als du deinen ersten Patch Ende März gepostet hast. Damals haben wir es darauf geschoben, dass sich bei mir irgendwas von den Sub-Applets (nennen wir das mal so) nicht installiert hat. Jetzt ist es aber ausgeschlossen. SWAP geht bei mir grundsätzlich nicht. Ich bin gerade dabei, die entsprechende Datei unter volume_id zu studieren. Wenn du mir endlich eine funktinierende Lösung verraten würdest, wie ich an den Sorcen rumbasteln kann, dass meine Änderungen auch reinkompiliert werden, dann würde ich gerne weiter basteln. Ansonsten hatte ich mich schon fast in die Syntax von Patches eingearbeitet und kann die Patches schon ohne diff selbst erstellen...

edit: Es fehlt dann noch die ext4-Unterstützung.
Ihr seid aber dran, habe ich vernommen. Ralf grübelt da auch mit und du hast da auch schon mal ein Dutzend printk-s eingebaut. Es wird langsam was...

MfG
 
Da geht es nicht um die Erkennung von ext4. Sondern darum das Modul mit der Labor Preview ans Laufen zu bekommen.

Du stellst den changes check ab und änderst direkt in source/target-mipsel.../ref-16mb/busybox...
Mit "make busybox-precompiled" baust du neu. Evtl. musst du vorher "source/target-mipsel.../ref-16mb/busybox.../busybox" löschen. Damit das make aufgerufen wird.

Gruß
Oliver

edit:
Code:
+--- util-linux/findfs.c.orig	2011-03-13 02:45:06.000000000 +0100
++++ util-linux/findfs.c	2011-04-22 23:21:48.112840007 +0200
+@@ -19,17 +19,10 @@
+ 	if (!dev)
+ 		bb_show_usage();
+ 
+-	if (strncmp(dev, "/dev/", 5) == 0) {
+-		/* Just pass any /dev/xxx name right through.
+-		 * This might aid in some scripts being able
+-		 * to call this unconditionally */
+-		dev = NULL;
+-	} else {
+ 		/* Otherwise, handle LABEL=xxx and UUID=xxx,
+ 		 * fail on anything else */
+ 		if (!resolve_mount_spec(argv))
+ 			bb_show_usage();
+-	}
+ 
+ 	if (*argv != dev) {
+ 		puts(*argv);
Warum brauchen wir das noch?
 
Warum brauchen wir das noch?
Keine Ahnung, Oliver. Ich bin nicht in die ganzen Tiefen von deiner Programmierung eingetaucht und weiß nicht, was du mit dieser Löschung wolltest. Jetzt fängt es bei mir langsam einzuleuchten, dass die Passage wahrscheinlich auch was mit dem direkten Aufruf von /dev/sdx zu tun hat. Heißt es dann, dass du gerade dieses "unconditionally"-Aufruf da weggepatcht hattest und ich deswegen Probleme mit dem mount hatte? So ließt es sich für mich zumindest. Ich weiß zwar nicht, was sie dort unter "unconditionally" alles meinen, es könnte aber dem von mir gefundenen Fehlerbild mit dem "mount" entsprechen. Interessant ist natürlich, dass es trotz deiner Patcherei an der Stelle immer noch funktioniert. Aber wenn wir es ehe nicht brauchen, dann wäre es natürlich sinnvoll es wieder heile zu machen, wie es vorher war.

MfG
 
Version mit "to call this unconditionally"

Ich habe es ausprobiert, ohne die besagte Passage zu patchen. Es funktioniert auch. Anbei ist die zweite Version von meinem (auf Olivers Bemühungen basierten) Patch ohne diese Passage.
Nun zurück zu meinen Beobachtungen mit dem SWAP. Ich hatte gestern noch versucht einige "printf-s" in die entsprechende "linux-swap"-Routine unter volume_id einzubauen. Leider bin ich nicht besonders weit damit gekommen. Es scheint so zu sein, dass die Routine ziemlich oft aufgerufen wird und sogar in deren internen Schleifen ziemlich weit durch kommt, nach meiner Meinung sogar dort, wo sie eigentlich gar nicht druch musste und erstaunlicherweise auch bei Partitionen, die gar keine SWAP-Partitionen sind. Ich habe langsam den Eindruck, dass SWAP-Check irgendwo am Ende als so eine Art default-Routine steht und dorthin werden alle Partitionen "hingeschickt" die vorher nirgendswo anders erkannt wurden. Ziemlicher Blödsinn meines erachtens, aber was sollst. Als ich noch zahlreiche "goto-s" mit Sprüngen nach vorne da entdeckt hatte, hab ich nur gedacht, dass ich im falschen Film bin und "strukturiertes Programmieren ade!" gerufen. Aber was sollst, busybox schent dafür erstaunlich stabil zu laufen.
Heißt eigentlich für mich: Noch eine Etage höher steigen und in den Hauptaufrufroutinen nachforschen, wann und wie diese SWAP-Routine aufgerufen wird.

Eine weitere unangenehme Entdeckung habe ich im Aufruf von blkid entdeckt. Ralf hatte dem blkid irgendwann mal beigebracht auch einzeilig die Anfragen zu beantworten, wenn man gezielt nach einer Partition fragt:
Code:
root@fritz:/var/mod/bin# blkid /dev/sda1
/dev/sda1: LABEL="SYSTEM" UUID="457c1f4b-8aec-e4ee-6843-fcded6ae79dd" TYPE="ext2"
Das klappt nur dann gut, wenn blkid die Partition erkennen kann. Im Falle von unerkannten Partitionen (z.B. SWAP in meinem Fall) spuckt er leider die komplette Palette aus:
Code:
root@fritz:/var/mod/bin# ./busybox blkid /dev/sda4
/dev/sdb7: LABEL="NTFS2" UUID="5BA928F435130FDD" TYPE="ntfs"
/dev/sdb6: LABEL="EXT3" UUID="3e602d35-9e47-7595-2e48-fbc7e28e4aeb" TYPE="ext3"
/dev/sdb5: LABEL="TEST-NTFS" UUID="734F9388689A9439" TYPE="ntfs"
/dev/sdb2: LABEL="SYSTEM" UUID="e914f1c2-f05d-20a7-db54-dea0c7c62ca1" TYPE="ext2"
/dev/sdb1: LABEL="FAT" UUID="A47A-253A" TYPE="vfat"
/dev/sda6: LABEL="ARCHIV" UUID="b1328ea0-2360-50da-6cc3-9adc5d42937d" TYPE="ext3"
/dev/sda5: LABEL="DATA" UUID="7b097c41-5282-7a79-feba-b9b0d63459e7" TYPE="ext2"
/dev/sda2: LABEL="FAT" UUID="9A64-8DAD" TYPE="vfat"
/dev/sda1: LABEL="SYSTEM" UUID="457c1f4b-8aec-e4ee-6843-fcded6ae79dd" TYPE="ext2"
/dev/loop0: UUID="3b85c627-9dc1-4ed5-aa08-1fa5b17d92cb" TYPE="ext2"
Und da ist natürlich die gefragte /dev/sda4 nicht vorzufinden. Beim "großen" blkid ist dieses Verhalten nicht so, sondern wenn blkid dort nichts erkennen kann, dann bleibt die Ausgabe leer. Diese Geschichte müssen wir noch flicken. Denn wenn man blkid so gezielt mit dem Namen vom device ansprechen will, dann ist es enorm wichtig, dass da nicht Tausende weitere Infos plötzlich auftauchen, die man nachher nur schlecht verarbeiten kann. Schaust du dir das bitte an, Ralf?
Der große Bruder kann außerdem die Ausgabe nach devices ordnen. Beim busybox-blkid tauchen sie in einem ziemlichen Durcheinander auf. Aber das wäre nicht allzugrosses Problem...
Wie sieht es eigentlich generell mit all diesen busybox-Patches aus? Meldet sie jemand von uns an busybox-Community? Denn meistens sind sie von großer Interesse. Auch diese Idee von Oliver findfs etwas zu missbrauchen ist im Grunde auch nicht verkehrt und von allgemeiner Interesse. Es wäre zu schade, wenn wir für uns hier alleine unser Süppchen kochen würden.

MfG
 

Anhänge

  • busybox_findfs_02.patch.txt
    34.2 KB · Aufrufe: 2
Durch die Änderungen an findfs sollten wir blkid für libmodmount nicht benötigen?

Diese blkid_type Geschichte ist in busybox noch ziemlich neu. Evtl. tut sich da in der nächsten Version auch noch was.

Gruß
Oliver
 
Durch die Änderungen an findfs sollten wir blkid für libmodmount nicht benötigen?
Ja schon, man muss dennoch es schon zu Ende bringen, wenn wir angefangen haben. Eine blkid, die sauber und kompatibel zur "großen" ist, ist auf jeden Fall besser, als die halbfertige.
Wer weiß, vielleicht nutzt jemand blkid für etwas anderes und partitions.cgi gibt es noch auch, obwohl sie es nicht unbedingt nutzt.
Diese blkid_type Geschichte ist in busybox noch ziemlich neu. Evtl. tut sich da in der nächsten Version auch noch was.
Deswegen wäre es schön, wenn wir uns mit busybox-Entwicklern synchronisieren. Denn in manchen Sachen liegen wir schon ziemlich vorne und sie können von uns was lernen. Andererseits wäre es blöd, wenn von mehreren Seiten an der gleichen Baustelle gleichzeitig gearbeitet wird.

MfG
 
Ich habe nun den Fehler gefunden, warum SWAP-Partitionen nicht erkannt werden. Es ist zwar durch die Änderungen von Ralf und von dir, Oliver auch "type" als Zusatzoption als Anzeige möglich, volume_id war aber anscheinend darauf ausgelegt UUIDs und LABELs darzustellen. Fölglich gibt es in get_devname.c eine IF-Bedingung, die auf Leersein von UUID oder LABEL prüft. Sind beide leer, so wird es davon ausgegangen, dass die Partition unerkannt ist.
Jetzt habe ich da noch die Überprüfung auf TYPE hinzugenommen:
Code:
#if ENABLE_FEATURE_BLKID_TYPE
	if (vid->label[0] != '\0' || vid->uuid[0] != '\0' || vid->type[0] != '\0') {
		*label = xstrndup(vid->label, sizeof(vid->label));
		*uuid  = xstrndup(vid->uuid, sizeof(vid->uuid));
		*type = vid->type;
		dbg("found label '%s', uuid '%s', type '%s'", *label, *uuid, *type);
#else
	if (vid->label[0] != '\0' || vid->uuid[0] != '\0') {
		*label = xstrndup(vid->label, sizeof(vid->label));
		*uuid  = xstrndup(vid->uuid, sizeof(vid->uuid));
		dbg("found label '%s', uuid '%s'", *label, *uuid);
#endif
		rv = 0;
	}
 ret:
	free_volume_id(vid); /* also closes fd */
	return rv;
Funktioniert auch soweit, bis er über meine erweiterte Partition stolpert oder eben eine nicht existierende Partition (/dev/sda7) auswerten soll:
Code:
root@fritz:/var/mod/bin# ./busybox blkid /dev/sda1
/dev/sda1: LABEL="SYSTEM" UUID="457c1f4b-8aec-e4ee-6843-fcded6ae79dd" TYPE="ext2"
root@fritz:/var/mod/bin# ./busybox blkid /dev/sda2
/dev/sda2: LABEL="FAT" UUID="9A64-8DAD" TYPE="vfat"
root@fritz:/var/mod/bin# ./busybox blkid /dev/sda3
Segmentation fault
root@fritz:/var/mod/bin# ./busybox blkid /dev/sda4
/dev/sda4: TYPE="swap"
root@fritz:/var/mod/bin# ./busybox blkid /dev/sda5
/dev/sda5: LABEL="DATA" UUID="7b097c41-5282-7a79-feba-b9b0d63459e7" TYPE="ext2"
root@fritz:/var/mod/bin# ./busybox blkid /dev/sda6
/dev/sda6: LABEL="ARCHIV" UUID="b1328ea0-2360-50da-6cc3-9adc5d42937d" TYPE="ext3"
root@fritz:/var/mod/bin# ./busybox blkid /dev/sda7
Segmentation fault
root@fritz:/var/mod/bin# ./busybox blkid /dev/sda
Segmentation fault
root@fritz:/var/mod/bin# ./busybox blkid
Segmentation fault
Das ist natürlich ganz nett, dass Segfault als Meldung kommt, jetzt muss ich aber noch weiter suchen warum....
Die Erkennung von erweiterten Partitionen wollte ich übrigens auch sowieso einbauen. Wenn nicht mit busybox, dann per Shell-Skript und dd. Wäre zwar blöd, ich weiß aber wenigstens, wie es funktioniert:
Code:
root@fritz:/var/mod/bin# dd if=/dev/sda bs=1 count=1 skip=450 2>/dev/null | hexdump -C
00000000  83                                                |.|
00000001
root@fritz:/var/mod/bin# dd if=/dev/sda bs=1 count=1 skip=466 2>/dev/null | hexdump -C
00000000  0b                                                |.|
00000001
root@fritz:/var/mod/bin# dd if=/dev/sda bs=1 count=1 skip=482 2>/dev/null | hexdump -C
00000000  05                                                |.|
00000001
root@fritz:/var/mod/bin# dd if=/dev/sda bs=1 count=1 skip=498 2>/dev/null | hexdump -C
00000000  82                                                |.|
00000001
Ich weiß bloß nicht, wie ich diese hexadecimalen Zahlen in Shell direkt auswerten kann.

MfG
 
Zuletzt bearbeitet:
Version 03 vom Patch, die nun halbwegs funktioniert und auch unbelabelt und SWAP kann

Im Anhang befindet sich die aktuelle Version vom Patch gegen Trunk, die nun endlich halbwegs zufriedenstellend funktioniert und theoretisch eingechekct werden könnte.
AVM-Log:
Code:
04.06.11	09:04:16	Partition unter ARCHIV (/dev/sda6) eingebunden
04.06.11	09:04:11	Partition unter DATA (/dev/sda5) eingebunden
04.06.11	09:04:11	Partition unter SWAP (/dev/sda4) eingebunden
04.06.11	09:04:10	Der USB-Speicher uStor03 (/dev/sda3) enthält kein unterstütztes Dateisystem oder hat eine ungültige Partitionstabelle. (Das Gerät hat den folgenden Typ: unknown)
04.06.11	09:04:06	Partition unter FAT (/dev/sda2) eingebunden
04.06.11	09:04:02	Partition unter SYSTEM (/dev/sda1) eingebunden
04.06.11	09:04:00	Fehler beim Einbinden der NTFS Partition NTFS2 (/dev/sdb7) (16)
04.06.11	09:03:56	Partition unter EXT3 (/dev/sdb6) eingebunden
04.06.11	09:03:56	Fehler beim Einbinden der NTFS Partition TEST-NTFS (/dev/sdb5) (16)
04.06.11	09:03:56	Der USB-Speicher uStor14 (/dev/sdb4) enthält kein unterstütztes Dateisystem oder hat eine ungültige Partitionstabelle. (Das Gerät hat den folgenden Typ: unknown)
04.06.11	09:03:55	Partition unter SWAP (/dev/sdb3) NOT/NICHT eingebunden
04.06.11	09:03:51	Partition unter SYSTEM (/dev/sdb2) eingebunden
04.06.11	09:03:48	Partition unter FAT (/dev/sdb1) eingebunden
04.06.11	09:03:36	Es wurde ein nicht unterstütztes USB-Gerät angeschlossen.
04.06.11	09:03:36	USB-Gerät 1007, Klasse 'USB 2.0 (hi-speed) storage', angesteckt
04.06.11	09:03:36	USB-Gerät 1009, Klasse 'USB 1.1 (low-speed) bulk', angesteckt
04.06.11	09:03:36	USB-Gerät 1008, Klasse 'USB 2.0 (hi-speed) storage', angesteckt
04.06.11	09:03:36	USB-Gerät 1006, Klasse 'USB 2.0 (hi-speed) hub', angesteckt
blkid:
Code:
root@fritz:/var/mod/root# blkid
/dev/sdb7: LABEL="NTFS2" UUID="5BA928F435130FDD" TYPE="ntfs"
/dev/sdb6: LABEL="EXT3" UUID="3e602d35-9e47-7595-2e48-fbc7e28e4aeb" TYPE="ext3"
/dev/sdb5: LABEL="TEST-NTFS" UUID="734F9388689A9439" TYPE="ntfs"
/dev/sdb3: TYPE="swap"
/dev/sdb2: LABEL="SYSTEM" UUID="e914f1c2-f05d-20a7-db54-dea0c7c62ca1" TYPE="ext2"
/dev/sdb1: LABEL="FAT" UUID="A47A-253A" TYPE="vfat"
/dev/sda6: LABEL="ARCHIV" UUID="b1328ea0-2360-50da-6cc3-9adc5d42937d" TYPE="ext3"
/dev/sda5: LABEL="DATA" UUID="7b097c41-5282-7a79-feba-b9b0d63459e7" TYPE="ext2"
/dev/sda4: TYPE="swap"
/dev/sda2: LABEL="FAT" UUID="9A64-8DAD" TYPE="vfat"
/dev/sda1: LABEL="SYSTEM" UUID="457c1f4b-8aec-e4ee-6843-fcded6ae79dd" TYPE="ext2"
/dev/loop0: UUID="3b85c627-9dc1-4ed5-aa08-1fa5b17d92cb" TYPE="ext2"
findfs:
Code:
root@fritz:/var/mod/root# findfs DEVT=/dev/sda1
ext2
root@fritz:/var/mod/root# findfs DEVT=/dev/sda3
root@fritz:/var/mod/root# findfs DEVT=/dev/sda4
swap
root@fritz:/var/mod/root# findfs DEVL=/dev/sda4

root@fritz:/var/mod/root# findfs DEVL=/dev/sda3
root@fritz:/var/mod/root# findfs DEVL=/dev/sda1
SYSTEM
Was geht und was ich geschafft hatte:
1. findfs etwas zu beschleunigen. In deiner variante, Oliver, hat er über alle Partitionen durchsucht, obwohl man ihm explizit die Partition angegeben hat. Dies hatte ich bei meinem Debuging gemerkt und beseitigt
2. Auch unbelabelte Partitionen werden nun gecheckt. Das war vorher der Grund dafür, dass bei mir SWAP nicht erkannt wurde
Was noch nicht geht:
1. blkid spuckt immer noch die volle Palette heraus, wenn er ein System nicht identifizieren kann:
Code:
root@fritz:/var/mod/root# blkid /dev/sda3
/dev/sdb7: LABEL="NTFS2" UUID="5BA928F435130FDD" TYPE="ntfs"
/dev/sdb6: LABEL="EXT3" UUID="3e602d35-9e47-7595-2e48-fbc7e28e4aeb" TYPE="ext3"
/dev/sdb5: LABEL="TEST-NTFS" UUID="734F9388689A9439" TYPE="ntfs"
/dev/sdb3: TYPE="swap"
/dev/sdb2: LABEL="SYSTEM" UUID="e914f1c2-f05d-20a7-db54-dea0c7c62ca1" TYPE="ext2"
/dev/sdb1: LABEL="FAT" UUID="A47A-253A" TYPE="vfat"
/dev/sda6: LABEL="ARCHIV" UUID="b1328ea0-2360-50da-6cc3-9adc5d42937d" TYPE="ext3"
/dev/sda5: LABEL="DATA" UUID="7b097c41-5282-7a79-feba-b9b0d63459e7" TYPE="ext2"
/dev/sda4: TYPE="swap"
/dev/sda2: LABEL="FAT" UUID="9A64-8DAD" TYPE="vfat"
/dev/sda1: LABEL="SYSTEM" UUID="457c1f4b-8aec-e4ee-6843-fcded6ae79dd" TYPE="ext2"
/dev/loop0: UUID="3b85c627-9dc1-4ed5-aa08-1fa5b17d92cb" TYPE="ext2"
Das hat was mit der globalen Struktur zu tun. Ich weiß genau, woran es liegt und hatte vergeblich versucht es zu beseitigen. Hat leider nicht geklappt. Um dies zu beseitigen, muss man Einiges an der Struktur, Funktionen usw. ändern. Ich hatte es nicht getan, weil ich Angst habe, dass etwas anderes auf die gleichen Funktionen zugreift. Man kann es zwar für uns patchen, aber dann wird irgendwas anderes nicht mehr funktionieren. Man muss da ein Paar Runden noch drehen.
2. Erweiterte Partitionen werden immer noch nicht erkannt. Da muss man auch tuefer rein.

Und mein NTFS wird nicht gemounted. Entweder sind die partitionen "beschädigt", oder Module fehlen, oder was auch immer. Hat aber mit dem Thema hier wenig zu tun.

Von mir aus sind wir trunkreif und können auf findfs umstellen. Auf meiner 7270 läuft auf jeden Fall seit 10 Minuten das Image.

Edit: Falls es jemanden interessieren sollte (die Reaktion hält sich allerdings in Grenzen), hatte ich es nun auch mit blkid hinbekommen (s. Punkt 1 von oben), dass blkid die Klappe hält, wenn er nichts zu sagen hat. Ich poste mal hier den betroffenen Abschnitt von blkid.c in Klartext (im Patch ist diese Änderung noch nicht drin):
Code:
int blkid_main(int argc UNUSED_PARAM, char **argv)
{
	[COLOR="red"][B]char with_arg;
	int part_found;[/B][/COLOR]
	
	[B][COLOR="red"]with_arg = 0;
	part_found = 0;[/COLOR][/B]
	while (*++argv) {
		/* Note: bogus device names don't cause any error messages */
		[COLOR="red"][B]with_arg = 1;[/B][/COLOR]
		[COLOR="red"][B]if (([/B][/COLOR]add_to_uuid_cache(*argv))[COLOR="red"][B] && (part_found == 0))
		{
			part_found = 1; // at least data for one partition found
		}[/B][/COLOR]
	}
	
	[COLOR="red"][B]if ((with_arg == 0) || (part_found))
	{ // show all partitions only, if blkid called without arguments[/B][/COLOR]
		display_uuid_cache();[B][COLOR="red"]	// or if uuidCache not empty[/COLOR][/B]
	[COLOR="red"][B]}[/B][/COLOR]
	return 0;
}

MfG
 

Anhänge

  • busybox_findfs_03.patch.txt
    35.6 KB · Aufrufe: 1
Zuletzt bearbeitet:
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.