- Mitglied seit
- 6 Nov 2005
- Beiträge
- 3,726
- Punkte für Reaktionen
- 16
- Punkte
- 38
Auf einem ähnlichen Kleinlinux-System bin ich vor kurzem darauf aufmerksam geworden, dass man durchaus interne Applets der Busybox zur Verwaltung vom Dateisystem verwenden kann. Ich hatte dort z.B. eine halbwegs funktionierende Variante vom integrierten fsck vorgefunden, die auch Links auf fsck.ext fsck.vfat usw. hatte. Das war dort wohl gemerkt mit Busybox 1.1.3 realisiert, sodass ich mich sofort dran gesetzt hatte, um mich unter busybox-menuconfig rumzuschauen. Und erstaunlicherweise hatte ich dort ziemlich viel vorgefunden. Außer fsck gibt es unter busybox fdisk, blkid, diverse mounts und Suchen nach volumen-id oder UUID. Das Schöne daran: man kann ein Teil von e2fsprogs und fstyp ersparen und bekommt dafür eine Reihe nützlicher Applets.
Nachdem ich ziemlich alles ausgewählt hatte, was da zum Thema gabs, ist meine busybox nur etwas größer geworden:
Dafür kann sie jetzt rein theoretisch deutlich mehr:
Hier ist ein Beispiel:
oder
Man kann sicherlich noch viel mehr damit veranstalten.
Die Sache hat allerdings einen Hacken: Die meisten von diesen Applets hängen sich auf mit meiner 7170. Das ist dieses alte Problem mit blkid. Anscheinend liegt das Problem eher nicht in blkid, sondern irgendwo tiefer in der Natur. Das eigentliche Problem scheinen die mtdblocks meiner 7170 zu sein, mit denen irgendwas nicht ganz klar kommen kann. Gelingt es die Applets so anzusprechen, dass mtdblocks umgangen werden (z.B. implizit als /dev/sda), funktionieren sie. Leider lassen einige Applets sowas gar nicht zu und können bei den alten Boxen nicht angewendet werden.
Ich habe dazu folgende Fragen:
1. Das Problem scheint irgendwo in der Flash-Verwaltung alter Boxen zu liegen. Entweder liegt es daran, dass entsprechende Treiber beim 13-Kernel buggy sind, oder AVM hat so ein Konstrukt der Blöcke bei den alten Boxen verfasst, dass dieverse fs-Tools damit nicht klar kommen.
a) Welche Möglichkeiten haben wir den Fehler zu lokalisieren? Strace bringt uns hier auch nicht besonders weiter. Dadurch sind wir damals auch so schlau geworden, dass es an mtdblocks aussteigt.
b) Haben wir irgendwelche Möglichkeiten den Fehler zu beseitigen, in dem wir z.B. entsprechende Treiber vom 13-Kernel patchen? Oder sind es AVM-closed-source-Treiber?
2. Besteht Interesse daran, dass wir diese Busybox-Applets bei FREETZMOUNT einbinden, um auf fstyp/blkid verzichten zu können?
MfG
Nachdem ich ziemlich alles ausgewählt hatte, was da zum Thema gabs, ist meine busybox nur etwas größer geworden:
Code:
root@fritz:/var/media/ftp/SYSTEM# ls -l /bin/busybox
-rwxrwxrwx 1 root root 589444 Oct 5 2010 /bin/busybox
root@fritz:/var/media/ftp/SYSTEM# ls -l busybox
-rwxr-xr-x 1 root root 634448 Oct 6 2010 busybox
Code:
BusyBox v1.17.2 (2010-10-06 20:51:40 CEST) multi-call binary.
Copyright (C) 1998-2009 Erik Andersen, Rob Landley, Denys Vlasenko
and others. Licensed under GPLv2.
See source distribution for full notice.
Usage: busybox [function] [arguments]...
or: function [arguments]...
BusyBox is a multi-call binary that combines many common Unix
utilities into a single executable. Most people will create a
link to busybox for each function they wish to use and BusyBox
will act like whatever it was invoked as.
Currently defined functions:
[, [[, addgroup, adduser, arp, arping, ash, awk, basename, [COLOR="Red"]blkid[/COLOR], bunzip2, bzcat, cat, chmod, chown, [COLOR="Red"]chpasswd[/COLOR], chroot, clear, cmp, cp, crond, crontab, cryptpw,
cut, date, dd, delgroup, deluser, df, dirname, dmesg, dnsdomainname, du, echo, egrep, env, ether-wake, expr, false, [COLOR="Red"]fdisk[/COLOR], fgrep, find, [COLOR="Red"]findfs[/COLOR], free, [COLOR="Red"]fsck[/COLOR],
ftpget, ftpput, getopt, grep, gunzip, gzip, halt, head, hexdump, hostname, httpd, id, ifconfig, ifdown, ifup, inetd, init, insmod, kill, killall, klogd, ln,
logger, login, logname, logread, losetup, ls, lsmod, makedevs, md5sum, mkdir, mkfifo, mknod, mkpasswd, mkswap, modprobe, more, mount, [COLOR="Red"]mountpoint[/COLOR], mv, nc,
netstat, nohup, nslookup, od, passwd, pidof, ping, pivot_root, poweroff, printf, ps, pwd, rdate, realpath, reboot, reset, rm, rmdir, rmmod, route, sed,
setconsole, setlogcons, sh, sleep, sort, strings, stty, swapoff, swapon, sync, sysctl, syslogd, tail, tar, tee, telnet, telnetd, test, tftp, time, top, touch,
tr, traceroute, true, tty, umount, uname, uniq, uptime, usleep, uudecode, uuencode, vconfig, vi, wc, wget, which, xargs, yes, zcatHier ist ein Beispiel:
Code:
root@fritz:/var/media/ftp/SYSTEM# ./busybox fdisk -l /dev/sda
Disk /dev/sda: 2004 MB, 2004877312 bytes
255 heads, 63 sectors/track, 243 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sda1 * 41 84 353430 6 FAT16
/dev/sda2 1 40 321268+ 83 Linux
/dev/sda3 85 100 128520 82 Linux swap
/dev/sda4 101 243 1148647+ 5 Extended
/dev/sda5 101 133 265041 7 HPFS/NTFS
/dev/sda6 134 188 441756 83 Linux
/dev/sda7 189 243 441756 7 HPFS/NTFS
Partition table entries are not in disk orderoder
Code:
root@fritz:/var/media/ftp/SYSTEM# ls
autoend.sh autorun.sh busybox external lost+found
root@fritz:/var/media/ftp/SYSTEM# ./busybox mountpoint external
external is not a mountpoint
root@fritz:/var/media/ftp/SYSTEM# ./busybox mountpoint /var
/var is a mountpoint
root@fritz:/var/media/ftp/SYSTEM# ./busybox mountpoint /bin
/bin is not a mountpointMan kann sicherlich noch viel mehr damit veranstalten.
Die Sache hat allerdings einen Hacken: Die meisten von diesen Applets hängen sich auf mit meiner 7170. Das ist dieses alte Problem mit blkid. Anscheinend liegt das Problem eher nicht in blkid, sondern irgendwo tiefer in der Natur. Das eigentliche Problem scheinen die mtdblocks meiner 7170 zu sein, mit denen irgendwas nicht ganz klar kommen kann. Gelingt es die Applets so anzusprechen, dass mtdblocks umgangen werden (z.B. implizit als /dev/sda), funktionieren sie. Leider lassen einige Applets sowas gar nicht zu und können bei den alten Boxen nicht angewendet werden.
Ich habe dazu folgende Fragen:
1. Das Problem scheint irgendwo in der Flash-Verwaltung alter Boxen zu liegen. Entweder liegt es daran, dass entsprechende Treiber beim 13-Kernel buggy sind, oder AVM hat so ein Konstrukt der Blöcke bei den alten Boxen verfasst, dass dieverse fs-Tools damit nicht klar kommen.
a) Welche Möglichkeiten haben wir den Fehler zu lokalisieren? Strace bringt uns hier auch nicht besonders weiter. Dadurch sind wir damals auch so schlau geworden, dass es an mtdblocks aussteigt.
b) Haben wir irgendwelche Möglichkeiten den Fehler zu beseitigen, in dem wir z.B. entsprechende Treiber vom 13-Kernel patchen? Oder sind es AVM-closed-source-Treiber?
2. Besteht Interesse daran, dass wir diese Busybox-Applets bei FREETZMOUNT einbinden, um auf fstyp/blkid verzichten zu können?
MfG
