Bugreports zu "new flashrules barf"

[gmo18t]

... ne Kommando zurück, hab ich doch geirrt - "gcc" wird schon richtig sein !

- GMo -

[Barf]

Das Automake checkt nur auf "mkcramfs", bei Debian heißt das Ding aber mkfs.cramfs.

Also, es gibt ein Programm, z.B. bei sourceforge, namens mkcramfs. Ist das Debianprogramm mkfs.cramfs das Gleiche, oder äquivalent? Nimmt es die gleiche Optionen? Dies muss geklärt werden falls mann behauptet dass Debians mkfs.cramfs ein Ersatz oder Äquivalent zu mkcramfs darstellt. Einfach "das Ding heisst ... " reicht nicht.

Kannst du die Information "garantieren"? Dann nehme ich es gerne.

[Rudi Ratlos 4711]

Das Automake checkt nur auf "mkcramfs", bei Debian heißt das Ding aber mkfs.cramfs.

Also, es gibt ein Programm, z.B. bei sourceforge, namens mkcramfs. Ist das Debianprogramm mkfs.cramfs das Gleiche, oder äquivalent? Nimmt es die gleiche Optionen? Dies muss geklärt werden falls mann behauptet dass Debians mkfs.cramfs ein Ersatz oder Äquivalent zu mkcramfs darstellt. Einfach "das Ding heisst ... " reicht nicht.

Kannst du die Information "garantieren"? Dann nehme ich es gerne.

Also es ist zumindest ein Satz Images "hinten raus gefallen"

RR4711

[Barf]

Es ist durchaus üblich, dass ein SW-Produkt Voraussetzungen auf Versionen etc von installiete Programme stellen. Es is, auch in open-source, mehr Regel als Ausnahme, dass diese Anforderungen "enforced" wird, so steht es z.B AC_PREREQ in fast alle configure.ac. Dies verhindert nicht, aber verringert unnötige HELP-Postings. Der Experte, der bewusst gegen Prerequisites verstossen will, hat keine Probleme dies "hinzuferkeln", z.B. durch händische Editierung von Files.

Falls jemand Information hat, dass die vorausgesetzte Versionsnummern fehlerhaft sind, bitte ich diese Information in CVS eintragen (zu lassen).

[Lefhark]

Hab gestern mal die newmake rules ausprobiert, aber folgendes Problem.
Alles läuft ohne Fehler durch, wenn ich dieses Script benutze:

Code: Alles auswählen

#! /bin/bash

# - anpassen ------------------------------------------------------------------------------------------------

USERDIR="root"

# - anpassung nicht unbedingt nötig (verzeichnisse sollten schon da sein ) ------------------------------------------------------------
LOGODIR=/$USERDIR/Logos
CP=/$USERDIR/tuxbox-cvs
DB=/$USERDIR/dbox2
ARCHIVEDIR=/$USERDIR/Archive
UCODESDIR=/$USERDIR/Ucodes

export CVS_RSH=ssh

# -----------------------------------------------------------------------------------------------------------

cd "$CP"

cvs -d anoncvs@cvs.tuxbox.org:/cvs/tuxbox -z3 co -f -r newmake -P .

cd cdk
/bin/ln -sf $ARCHIVEDIR/ Archive

./autogen.sh
./configure --prefix="$DB" --with-cvsdir="$CP" --enable-flashrules --with-checkImage=rename --with-logosdir="$LOGODIR" --with-ucodesdir="$UCODESDIR"

#make flash-tools_misc
make mostlyclean
make flash-enigma-squashfs-2x
#make flash-all-all-all
#make everything 

allerdings nur, wenn ich den movieplayer aus den plugin makerules herausnehme. Ansonsten sehe ich dies:

Code: Alles auswählen

root@3[movieplayer]# make
/bin/sh ../../libtool --tag=CXX --mode=link powerpc-tuxbox-linux-gnu-g++  -Wall -mcpu=823 -mmultiple -mstring -meabi -pipe -Os   -o movieplayer.la  -rpath /root/dbox2/cdkroot/lib/tuxbox/plugins @CURL_LIBS@ -module movieplayer_la-movieplayer.lo
powerpc-tuxbox-linux-gnu-g++ -shared -nostdlib /root/dbox2/cdk/lib/gcc/powerpc-tuxbox-linux-gnu/3.4.4/../../../../powerpc-tuxbox-linux-gnu/lib/nof/crti.o /root/dbox2/cdk/lib/gcc/powerpc-tuxbox-linux-gnu/3.4.4/nof/crtbeginS.o  .libs/movieplayer_la-movieplayer.o  -Wl,--rpath -Wl,/root/dbox2/cdk/powerpc-tuxbox-linux-gnu/lib/nof -Wl,--rpath -Wl,/root/dbox2/cdk/powerpc-tuxbox-linux-gnu/lib/nof -L/root/dbox2/cdk/lib/gcc/powerpc-tuxbox-linux-gnu/3.4.4/nof -L/root/dbox2/cdk/lib/gcc/powerpc-tuxbox-linux-gnu/3.4.4 -L/root/dbox2/cdk/lib/gcc/powerpc-tuxbox-linux-gnu/3.4.4/../../../../powerpc-tuxbox-linux-gnu/lib/nof -L/root/dbox2/cdk/lib/gcc/powerpc-tuxbox-linux-gnu/3.4.4/../../../../powerpc-tuxbox-linux-gnu/lib /root/dbox2/cdk/powerpc-tuxbox-linux-gnu/lib/nof/libstdc++.so -lm -lc -lgcc_s_nof /root/dbox2/cdk/lib/gcc/powerpc-tuxbox-linux-gnu/3.4.4/nof/crtsavres.o /root/dbox2/cdk/lib/gcc/powerpc-tuxbox-linux-gnu/3.4.4/nof/crtendS.o /root/dbox2/cdk/lib/gcc/powerpc-tuxbox-linux-gnu/3.4.4/../../../../powerpc-tuxbox-linux-gnu/lib/nof/crtn.o  -mcpu=823 -mmultiple -mstring -meabi @CURL_LIBS@ -Wl,-soname -Wl,movieplayer.so.0 -o .libs/movieplayer.so.0.0.0
../../libtool: line 4509: powerpc-tuxbox-linux-gnu-g++: command not found
make: *** [movieplayer.la] Fehler 127

Das eigentliche Problem erscheint aber erst, wenn das erstellte Image geflasht ist und hochfährt. Dann bleibt es bei "loading kernel" hängen und das bootlog zeigt folgendes:

Code: Alles auswählen

debug: DDF: Calibrating delay loop... debug: DDF: 66.76 BogoMIPS
debug: BMon V1.0  mID 02
debug: feID 00    enxID 03
debug: fpID 52     dsID 01-6b.08.cd.07.00.00-e6
debug: HWrev 01  FPrev 0.30
debug: B/Ex/Fl(MB) 32/00/08
dbox2:root> debug: 
BOOTP/TFTP bootstrap loader (v0.3)
debug: 
debug: Transmitting BOOTP request via broadcast
debug: Given up BOOTP/TFTP boot
boot net failed

Flash-FS bootstrap loader (v1.5)

Found Flash-FS superblock version 3.1
Found file /root/platform/philips-dbox2/kernel/os in Flash-FS
debug: Got Block #0040

will verify ELF image, start= 0x800000, size= 154948
verify sig: 262
Branching to 0x40000


U-Boot 1.1.4 (Tuxbox) (Feb  4 2006 - 18:25:18)

CPU:   PPC823ZTnnB2 at 66 MHz: 2 kB I-Cache 1 kB D-Cache
Board: DBOX2, Philips, BMon V1.0
       Watchdog enabled
I2C:   ready
DRAM:  32 MB
FLASH:  8 MB
Scanning JFFS2 FS: . done.
find_inode failed for name=boot.conf
load: Failed to find inode
FB:    ready
LCD:   ready
In:    serial
Out:   serial
Err:   serial
Net:   SCC ETHERNET

Options:
  1: Console on null
  2: Console on ttyS0
  3: Console on framebuffer
Select option (1-3), other keys to stop autoboot:  0 
### FS (squashfs) loading 'vmlinuz' to 0x100000
### FS load complete: 657706 bytes loaded to 0x100000
...............................................................
Un-Protected 63 sectors
## Booting image at 00100000 ...
   Image Name:   dbox2
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:    657642 Bytes = 642.2 kB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
Linux version 2.4.32-dbox2 (root@Crimson-cloud) (gcc version 3.4.4) #2 Sa Feb 4 
18:25:56 CET 2006
On node 0 totalpages: 8192
zone(0): 8192 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: console=ttyS0 root=/dev/mtdblock2 rootfstype=squashfs
Decrementer Frequency = 247500000/60
m8xx_wdt: active wdt found (SWTC: 0xFFFF, SWP: 0x1)
m8xx_wdt: keep-alive trigger installed (PITC: 0x2000)
Console: colour dummy device 80x25
Calibrating delay loop... 65.74 BogoMIPS
Memory: 30824k available (1116k kernel code, 368k data, 60k init, 0k highmem)
Dentry cache hash table entries: 4096 (order: 3, 32768 bytes)
Inode cache hash table entries: 2048 (order: 2, 16384 bytes)
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 8192 (order: 3, 32768 bytes)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
devfs: v1.12c (20020818) Richard Gooch (rgooch@atnf.csiro.au)
devfs: boot_options: 0x1
JFFS2 version 2.2. (NAND) (C) 2001-2003 Red Hat, Inc.
Squashfs 2.2-r2 (released 2005/09/08) (C) 2002-2005 Phillip Lougher
i2c-core.o: i2c core module version 2.6.1 (20010830)
i2c-dev.o: i2c /dev entries driver module version 2.6.1 (20010830)
CPM UART driver version 0.04
ttyS0 at 0x0280 is on SMC1 using BRGttyS1 at 0x0380 is on SMC2 using BRG2
pty: 256 Unix98 ptys configured
eth0: CPM ENET Version 0.2.dbox2 on SCC2, 00:50:9c:2b:a8:c1
loop: loaded (max 8 devices)
D-Box 2 flash driver (size->0x800000 mem->0x10000000)
D-Box 2 flash memory: Found 2 x16 devices at 0x0 in 32-bit bank
 Intel/Sharp Extended Query Table at 0x0035
cfi_cmdset_0001: Erase suspend on write enabled
Creating 6 MTD partitions on "D-Box 2 flash memory":
0x00000000-0x00020000 : "BR bootloader"
0x00020000-0x00040000 : "FLFS (U-Boot)"
0x00040000-0x006a0000 : "root (Squashfs)"
0x006a0000-0x00800000 : "var (jffs2)"
0x00020000-0x00800000 : "Flash without bootloader"
0x00000000-0x00800000 : "Complete Flash"
Linux video capture interface: v1.00
mice: PS/2 mouse device common for all mice
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 2048 bind 4096)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
VFS: Mounted root (squashfs filesystem) readonly.
mount_devfs_fs(): unable to mount devfs, err: -2
Freeing unused kernel memory: 60k init
Warning: unable to open an initial console.
Kernel panic: No init found.  Try passing init= option to kernel.
 <0>Rebooting in 180 seconds..

Toolcheck.sh zeigt nichts auffälliges.

Code: Alles auswählen

cvs:                      1.12.9
autoconf >= 2.57a:        2.59
automake >= 1.8:          1.9.6
libtool >= 1.4.2:         1.5.22
gettext >= 0.12.1:        0.14.5
make >= 3.79:             3.80
makeinfo:                 4.8
tar:                      1.15.1
bunzip2:                  1.0.3
gunzip:                   1.3.5
patch:                    2.5.9
infocmp:                  5.5.20051010
gcc 2.95 or >= 3.0:       4.0.3
g++ 2.95 or >= 3.0:       4.0.3
flex:                     2.5.31
bison:                    2.1
pkg-config:               0.20
wget:                     1.10.2
mksquashfs 2.1            2.1

Irgendeine Idee, woran es liegen könnte, dass meine images bei "loading Kernel" hängenbleiben? Könnte es an der gcc, g++ Version liegen?
Danke schonmal im voraus.

-Lef

[Barf]

@Lefhark:
Zwei Fragen:

- Kompilierst du als root? Ist eine schlechte idee

- Welche mksquashfs wird benuzt? dazu

grep -i mksquashfs $CP/cdk/config.log

[Lefhark]

zu Frage 1:
Ich lasse Linux eh "nur" unter Vmware laufen. Root sollte also nicht so schlimm sein.

Zu Frage 2:
kam das hier raus.

Code: Alles auswählen

root@1[cdk]# grep -i mksquashfs config.log
configure:4367: checking for mksquashfs
configure:4385: found /bin/mksquashfs
configure:4398: result: /bin/mksquashfs
ac_cv_path_MKSQUASHFS=/bin/mksquashfs
MKSQUASHFS='/bin/mksquashfs'

Ist auch nicht nur bei squashfs Images so, sondern auch bei jffs2 und cramfs - hängen bei "loading kernel".
Danke für die schnelle Antwort.

-Lef

[Barf]

Ich kann nicht sicher sage was schief läuft. Das Kompilieren als root KANN durchaus auswirken, vmware auch. Das kernel "hängen" bedeutet dass der Kernel das root filesystem nicht mounten kann -- entweder ist der Kernel oder das Filesystem "doof". Eventuell probieren mit ein funktionerende Kernel, z.B. vom einem dietmarw image (sicherstellen dass support für erforderliche filesysteme da ist.)

Das @CURL_LIBS@ im (enigma) movieplayer ist definitiv ein Fehler der dessen Author auf seine Kappen nehmen muss. Glaube auber nicht dass es wirklich kritisch hier ist.

Kannst du ein lauffähiges yadd erstellen? Ist etwas mehr debuggfreundlich.

PS. Nehmen an, dass ein Makefile sagt

echo "foo bar" > $(dingsbumsroot)/etc/passwd

und, durch ein Fehler $(dingsbumsroot) leer ist, und du buildest als root....

[Lefhark]

Bis zum 2.1.2006 ging es noch, als root ein lauffähiges Image zu erstellen. Werd mal sehen, was ich als nicht-root ausrichten kann.

[Lefhark]

Als normaler User bekomme ich zumindest nun einen Fehler. Vielleicht erklärt der ja, was schief gelaufen ist.

Code: Alles auswählen

ln -s /tmp /home/Lefhark/tuxbox/dbox2/cdkflash/root/var/run
make /home/Lefhark/tuxbox/dbox2/cdkflash/etc/cramfs.urls
make[1]: Entering directory `/home/Lefhark/tuxbox/tuxbox-cvs/cdk'
make[1]: *** Keine Regel, um »/home/Lefhark/tuxbox/dbox2/cdkflash/etc/cramfs.urls« zu erstellen.  Schluss.
make[1]: Leaving directory `/home/Lefhark/tuxbox/tuxbox-cvs/cdk'
make: *** [/home/Lefhark/tuxbox/dbox2/cdkflash/root] Fehler 2

Irgendwie scheint mir da make etwas verwirrt zu sein.
Bei dem Fehler oben habe ich übrigens versucht, ein flash-enigma-jffs2-2x herzustellen.

-Lef

[dietmarw]

der fehler besteht aber heute generell.. der liegt nicht bei dir..

[Barf]

Oooooooooops, Ist aber sein 2 minuten gefixt. Bitte updaten (flashroot.mk). Nochmals sorry.

@Lefhark:
Freut mich das es sonst läuft. Wäre eigentlich intressant zu wissen EXAKT was schiefgegangen war als root.

[Lefhark]

Ah, gut zu wissen. Dann bin ich ja nun halbwegs beruhigt und wieder auf dem gleichen Stand, wie alle anderen (wahrscheinlich). Lag bei mir wohl wirklich daran, das ich als root kompiliert habe.

[Lefhark]

Und wieder ein neuer Fehler nach dem Update.

Code: Alles auswählen

make[3]: powerpc-tuxbox-linux-gnu-gcc: Kommando nicht gefunden
make[3]: Entering directory `/home/Lefhark/tuxbox/tuxbox-cvs/cdk/u-boot-1.1.4/tools'
make[3]: ».depend« ist bereits aktualisiert.
make[3]: Leaving directory `/home/Lefhark/tuxbox/tuxbox-cvs/cdk/u-boot-1.1.4/tools'
make[3]: powerpc-tuxbox-linux-gnu-gcc: Kommando nicht gefunden
make[3]: Entering directory `/home/Lefhark/tuxbox/tuxbox-cvs/cdk/u-boot-1.1.4/post'
powerpc-tuxbox-linux-gnu-gcc -M -g  -Os   -fPIC -ffixed-r14 -meabi -fno-strict-aliasing -D__KERNEL__ -DTEXT_BASE=0x40000 -I/home/Lefhark/tuxbox/tuxbox-cvs/cdk/u-boot-1.1.4/include -fno-builtin -ffreestanding -nostdinc -isystem  -pipe  -DCONFIG_PPC -D__powerpc__ -DCONFIG_8xx -ffixed-r2 -ffixed-r29 -mstring -mcpu=860 -msoft-float -Wall -Wstrict-prototypes cache_8xx.S cache.c codec.c cpu.c dsp.c ether.c i2c.c memory.c post.c rtc.c spr.c sysmon.c tests.c uart.c usb.c watchdog.c > .depend
/bin/sh: powerpc-tuxbox-linux-gnu-gcc: command not found
make[3]: *** [.depend] Fehler 127
make[3]: Leaving directory `/home/Lefhark/tuxbox/tuxbox-cvs/cdk/u-boot-1.1.4/post'
make[3]: powerpc-tuxbox-linux-gnu-gcc: Kommando nicht gefunden
make[3]: Entering directory `/home/Lefhark/tuxbox/tuxbox-cvs/cdk/u-boot-1.1.4/post/cpu'
powerpc-tuxbox-linux-gnu-gcc -M -g  -Os   -fPIC -ffixed-r14 -meabi -fno-strict-aliasing -D__KERNEL__ -DTEXT_BASE=0x40000 -I/home/Lefhark/tuxbox/tuxbox-cvs/cdk/u-boot-1.1.4/include -fno-builtin -ffreestanding -nostdinc -isystem  -pipe  -DCONFIG_PPC -D__powerpc__ -DCONFIG_8xx -ffixed-r2 -ffixed-r29 -mstring -mcpu=860 -msoft-float -Wall -Wstrict-prototypes asm.S cmp.c cmpi.c two.c twox.c three.c threex.c threei.c andi.c srawi.c rlwnm.c rlwinm.c rlwimi.c store.c load.c cr.c b.c multi.c string.c complex.c > .depend
/bin/sh: powerpc-tuxbox-linux-gnu-gcc: command not found
make[3]: *** [.depend] Fehler 127
make[3]: Leaving directory `/home/Lefhark/tuxbox/tuxbox-cvs/cdk/u-boot-1.1.4/post/cpu'
make[2]: *** [depend] Fehler 2
make[2]: Leaving directory `/home/Lefhark/tuxbox/tuxbox-cvs/cdk/u-boot-1.1.4'
make[1]: *** [u-boot-1.1.4/u-boot.stripped] Fehler 2
make[1]: Leaving directory `/home/Lefhark/tuxbox/tuxbox-cvs/cdk'
make: *** [/home/Lefhark/tuxbox/dbox2/cdkflash/squashfs.flfs2x] Fehler 2

(edit)
Scheint ja schon wieder gefixt. Mein nächster Update ging über diesen Punkt hinaus.

[Lefhark]

Super. Funktioniert wieder alles und ich hab mein erstes, mit newrules erstelltes, Image.
Lag also tatsächlich an "root". Danke für die Hilfe.
Übrigens, gute Arbeit, Barf. Selbst jetzt ist das Erstellen eines Images schon viel übersichtlicher geworden. Und man braucht keine "schwarze Magie" mehr, um ein Image so hinzubekommen, wie man es möchte.
Das bei so fundamentalen Änderungen nicht immer alles auf Anhieb klappt, gerade in der Anfangsphase, ist ja nur natürlich.

Hab alle drei Versionen des enigma-2x durchkompiliert und keines hatte Bad Magics. War das erste Mal.
Image-erstellungs Scriptschreiber müssen sich zwar umgewöhnen, aber mir gefallen die Änderungen.
Danke nochmal.

-Lef

[racker]

Es ist durchaus üblich, dass ein SW-Produkt Voraussetzungen auf Versionen etc von installiete Programme stellen. Es is, auch in open-source, mehr Regel als Ausnahme, dass diese Anforderungen "enforced" wird, so steht es z.B AC_PREREQ in fast alle configure.ac. Dies verhindert nicht, aber verringert unnötige HELP-Postings. Der Experte, der bewusst gegen Prerequisites verstossen will, hat keine Probleme dies "hinzuferkeln", z.B. durch händische Editierung von Files.

Die Frage ist nicht ob man es abändern kann, sondern ob es Sinn macht.
Wie bereits geschrieben - bei mir baut mit o.g. Konfiguration das ganze cdk, auch java
Die höchste Version im CDK für automake (Required) ist 1.9 .

[StevenSch]

Ich weis nicht, ob es an mir liegt, deinen rules oder ein genereller Fehler ist.
Ich bekomme beim make -neutrino-all-2x immer folgenden Fehler:
-----
touch .deps/lufs
/usr/bin/install -c /home/steven/tuxbox/dbox2/cdkroot/bin/lufsmnt /bin
/usr/bin/install: reguläre Datei „/bin/lufsmnt“ kann nicht angelegt werden: Keine Berechtigung
make[1]: *** [flash-lufsd] Fehler 1
make[1]: Leaving directory `/home/steven/tuxbox/tuxbox-cvs/cdk'
make: *** [/home/steven/tuxbox/dbox2/cdkflash/root] Fehler 2
-----
So wie ich das verstehe will er lufsmnt nach /bin und nicht nach $DB/cdkflash/root(?)/bin kopieren.
Ich kann das kompilieren danach fortsetzen und es fallen auch Images hinten raus, allerdings hat das jff2 immer bad magics. Aber das ist wohl ein anderes Thema.

[Barf]

Klingt wie DieMades Problem früher in diesem Thread. Führe diese Makefile aus, um
dies zu verifizieren. Welche makeversion hast du?

Code: Alles auswählen

all: | /etc/passwd
        echo Hey man, there is a $< on this system! 

[StevenSch]

Code: Alles auswählen

checking for libtool >= 1.4.2 ... yes (version 1.5.22)
checking for autoconf >= 2.57a ... yes (version 2.59)
checking for automake >= 1.8 ... yes (version 1.9.6)
checking for gettext >= 0.12.1 ... yes (version 0.14.5)
checking for make >= 3.79 ... yes (version 3.81)
checking for gcc >= 3.0 or = 2.95 ... yes (version 4.0.3)
checking for g++ >= 3.0 or = 2.95 ... yes (version 4.0.3)

Das scheint tatsächlich ein Problem mit make-Versionen > 3.80 zu sein.
Das kleine Problem ist, das die 3.81 die Version ist die für Debian(testing) installiert wird.

[gmo18t]

... na ist eher ein features-request :

wenn "--with-ucodesdir" verwendet wird, werden ja die
UCODES kopiert, leider nur mit "cp -p ...", so daß Links
nicht 1:1 übernommen werden. Besser wäre ein "cp -d -p ..."

- GMo -

[Barf]

Danke für den Vorschlag. Ich glaube nicht es so eine gute Idee wäre, und aus folgende Grund:

Der kraftvolle Customization-Mögligkeit sind die Customization-Skripte. Der Wünsch, für private Images ucodes reinzupacken ist aber so "kanonisch", dass man diese Möglichkeit direkt in --with-ucodes-dir verpackt. (Dito --with-bootlogosdir.) Eigentlich ist es ja doof für ein squashfs/cramfs-Image mit enthaltene ucodes diese in /var zu plazieren. Falls mann die ucodes in, z.B. /lib/tuxbox/ucode installieren will, und in /var/tuxbox/ucodes symlinks machen will, ist die ucodesinstallation sowieso nicht mit --with-ucodes-dir erschlagen, und mann muss sowieso zu skripting zugreifen.

Noch besser wäre sowas in /etc/init.d/rcS:

Code: Alles auswählen

if [ -d /lib/tuxbox/ucodes ] ; then
  UCODESDIR=/lib/tuxbox/ucodes
else
   UCODESDIR=/var/tuxbox/ucodes
fi

und später in rcS bei diverse Driverladen (symbolisch)

Code: Alles auswählen

$IM driver firmware=$UCODESDIR/driverfirmware

Was meint ihr?

[gmo18t]

ja, gibt viele Möglichkeiten dafür ...
Bei mir ist das Problem aber eher: ich habe mehrere "avia600-b0xx.ux"
in '/var/tuxbox/ucodes' und linke mir immer die auf "avia600.ux",
welche ich jeweils benötige.
Und den "cp -d -p ..."-Vorschlag habe ich nur im Hinblick auf den
geringsten Aufwand gemacht. Weiß ja, daß du eher die "saubere"
Lösung bevorzugst

Im übrigen, hab mich jetzt doch mehr mit deinem "newmake" bechäftigt
als ich ursprünglich vor hatte. Aber das kommt daher, daß es mir
immer besser gefällt !

- GMo -

[Barf]

ja, gibt viele Möglichkeiten dafür ...
Bei mir ist das Problem aber eher: ich habe mehrere "avia600-b0xx.ux"
in '/var/tuxbox/ucodes' und linke mir immer die auf "avia600.ux",
welche ich jeweils benötige.

DAS ist etwas, was ich überhaupt nicht gedacht habe. Absolut legitim. DIe Änderung ist in CVS. Nicht desto weniger darf Leute sich gerne über den /lib/tuxbox/ucodes-Vorschag äussern.

Im übrigen, hab mich jetzt doch mehr mit deinem "newmake" bechäftigt
als ich ursprünglich vor hatte. Aber das kommt daher, daß es mir
immer besser gefällt !

Anderes Thema (DieMade & StevenSch): Das Problem mit make 3.81 ist behoben: http://cvs.tuxbox.org/lists/tuxbox-cvs- ... 00081.html

[StevenSch]

Werd ich direkt testen, Danke !!

Tante Edit sagt: Läuft ohne Probleme mit make3.81 durch...

[DieMade]

Ja, baut problemlos durch (make distclean, cvs update, make flash-neutrino-all-all).