Unfortunately no one can be told what fun_plug is - you have to see it for yourself.
You are not logged in.
Assuming that the kernel now works, you should check if you've setup stuff correctly, i.e. devices files in dev/, etc/, bin/, sbin/, usr/ links, proc/ and sys/, ffp/etc/passwd, etc...
Offline
Hmmmm... by adding "echo" statements to /etc/rc, I was able to isolate the problem to the /ffp/start scripts not starting properly.
I get the following output from rc:
* /ffp/start/syslogd.sh ...
* /ffp/start/SERVERS.sh inactive
* /ffp/start/portmap.sh inactive
* /ffp/start/unfsd.sh inactive
* /ffp/start/cleanboot.sh inactive
* /ffp/start/nfsd.sh inactive
* /ffp/start/ntpd.sh inactive
* /ffp/start/LOGIN.sh inactive
* /ffp/start/telnetd.sh inactive
* /ffp/start/sshd.sh inactive
* /ffp/start/rsyncd.sh inactive
* /ffp/start/mediatomb.sh inactive
* /ffp/start/kickwebs.sh inactive
* /ffp/start/lighttpd.sh inactive
* /ffp/start/inetd.sh inactive
Even though, an "ls -al /ffp/start" executed from the same rc script shows:
drwxr-xr-x 2 root root 4096 Oct 13 21:44 .
drwxr-xr-x 15 root root 4096 Oct 13 04:12 ..
-rw-r--r-- 1 root root 52 Aug 17 13:29 LOGIN.sh
-rw-r--r-- 1 root root 35 Aug 17 13:29 SERVERS.sh
-rw-r--r-- 1 root root 1328 Oct 12 18:12 cleanboot.sh
-rw-r--r-- 1 root root 203 Sep 29 18:45 inetd.sh
-rw-r--r-- 1 root root 229 Sep 30 10:19 kickwebs.sh
-rw-r--r-- 1 root root 223 Sep 30 10:19 lighttpd.sh
-rw-r--r-- 1 root root 267 Apr 15 2008 mediatomb.sh
-rw-r--r-- 1 root root 1468 Apr 15 2008 nfsd.sh
-rw-r--r-- 1 root root 526 Apr 15 2008 ntpd.sh
-rw-r--r-- 1 root root 160 Apr 15 2008 portmap.sh
-rw-r--r-- 1 root root 224 Sep 14 14:02 rsyncd.sh
-rwxr-xr-x 1 root root 971 Sep 30 08:38 sshd.sh
-rwxr-xr-x 1 root root 383 Sep 29 18:45 syslogd.sh
-rwxr-xr-x 1 root root 169 Sep 29 18:45 telnetd.sh
-rwxr-xr-x 1 root root 998 Apr 16 20:33 unfsd.sh
I need to troubleshoot this some more but I suspect this may be a path issue or something.
Note that when I added manually "sh /ffp/start/sshd.sh start" to the /etc/rc script, I was able to ssh into the system...
Offline
I am stumped. It is not at all clear to me why "syslogd" starts while "sshd" and "tenetd" which have the same perms don't.
Also, note that if I run 'rc' manually from the command line that it all works ok.
What (obvious thing) am I missing here?
Offline
One more data point that stumps me even more...
Everything works perfectly fine if I make the following simple change to rc.sysinit:
--- rc.sysinit 2008-10-15 20:46:13 +0000
+++ rc.sysinit.orig 2008-08-17 12:10:56 +0000
@@ -45,5 +45,5 @@
fi
# run start scripts
-. /ffp/etc/rc >> /rclog
+. /ffp/etc/rc
So, I'm CONFUSED!
Offline
ONE good thing though -- nfs works nicely with the 2.6.12.6 kernel that you provide.
So, this leads me to wonder whether there is any way to modify ffp-reloaded to launch this kernel but still boot to the original rootfs contained in the dns-323 firmware. The goal would be to have all the advantages of this kernel while also still preserving the basic dns-323 functionality and web interface.
In other words, I would like to use ffp-reoladed to boot alternative kernels (without having to modify my firmware) but still preserve all the other functionality of the native firmware.
Is this possible?
If so, I would assume that I would somehow have to set root to the part of the flash representing root on the firmware.
Any ideas on what explicitly I would need to do?
I would think this would be very useful to people wanting to play with new kernels but who don't want to take the risk of potentially bricking the dns-323 by overwriting the kernel firmware.
Thanks!
Offline
puterboy wrote:
If so, I would assume that I would somehow have to set root to the part of the flash representing root on the firmware.
Any ideas on what explicitly I would need to do?
The firmware boots an initrd stored in flash.
The ramdisk flash region is accessible through /dev/mtdblock3. Although I haven't tried myself, it should be possible to extract the filesystem, and boot it (just like booting the fsck ramdisk). This requires only a few steps:
First, get the data from flash:
cd /mnt/HD_a2/tmp dd if=/dev/mtdblock3 of=mtd3
The format of mtd3 is a U-Boot image (try 'file mtd3'). To extract the compressed ramdisk, strip the first 64 bytes:
dd if=mtd3 of=initrd.gz bs=64 skip=1
To verify that you really got a root filesystem, you can uncompress and mount it:
zcat initrd.gz >initrd mkdir mnt mount -o loop initrd mnt ls mnt ... umount mnt
Offline
Fonz, any ideas on why /ffp/etc/rs.sysinit is not working properly for me (see above)?
Offline
puterboy wrote:
Fonz, any ideas on why /ffp/etc/rs.sysinit is not working properly for me (see above)?
No idea. Is it possibly looking at a different set of start scripts? Also, it's busybox ash, might have a strange bug (you could try bash instead).
Offline
Thanks for the advice on how to extract initrd.
The next thing I (perhaps too simplistically) tried to do was:
./reload.sh -r initrd.gz -I root=/dev/root
However, this did not work...
Any suggestions on what I should do from here to *mimic* the original boot process using your version of the 2.6.12.6 kernel?
Offline
puterboy wrote:
./reload.sh -r initrd.gz -I root=/dev/root
However, this did not work...
Any suggestions on what I should do from here to *mimic* the original boot process using your version of the 2.6.12.6 kernel?
I'd try passing the same command line:
root@bob:~# cat /proc/cmdline root=/dev/ram console=ttyS0,115200 :::DB88FXX81:egiga0:none
Since you don't have a serial console, it might become hard to find problems. I can try this myself this weekend.
Offline
I tried it and no luck so I guess I will have to wait for your experiments unless you have some other suggestions to try.
The 2 other things that I am not sure about are:
- Am I right in using the compressed initrd.gz rather than the uncompressed initrd (I know on ix86 systems I have always used compresed initrds)?
- Do I need to specify the location of the init binary as in something like: init="/busybox init"?
Just so you know, I hope to give back to the community by writing up how to do this and creating an alternative package version of ffp-reloaded that does all this automatically.
Hopefully this will allow the less brave among us to get the best of both worlds -- all the functionality of new kernels with no risk of bricking the dns-323 and with all the original web interface functionality intact.
Offline
fonz wrote:
I can try this myself this weekend.
http://www.inreto.de/dns323/misc/
Works most of the time. If it doesn't, try again after a fresh reboot. The reloaded module needs contiguous memory blocks for kernel and initrd, both are quite large here and allocation may fail due to memory fragmentation.
Offline
Fonz - can you tell me what you changed to make this work?
When I did a diff on initrd, I noticed that some of the files differed but most (if not all) of the differences appear to be due to differences in our firmware.
So, if I understand what you did to make this work then I can better understand what I need to do to get my own kernels/initrd to work.
Thanks
Offline
puterboy wrote:
Fonz - can you tell me what you changed to make this work?
I adapted the reload.sh script, and the only interesting part of boot.sh is:
kernel=zImage-2.6.12.6 initrd=initrd.gz cmdline="$(cat /proc/cmdline)" machtype=526
The rest is mechanics. So, does it work for you?
Offline
no it doesn't and in fact I was basically using the same kernel and command line myself earlier just doing it manually.
I have hardware B1 and firmware 1.05 -- could that be the source of the difference?
If memory is the issue is there any smart way of clearing up more memory or at least compacting memory to get enough contiguous...
It is both tantalizing and frustrating that you have it working but I can't lol...
Offline
puterboy wrote:
I have hardware B1 and firmware 1.05 -- could that be the source of the difference?
If memory is the issue is there any smart way of clearing up more memory or at least compacting memory to get enough contiguous...
I don't think the hardware revision is an issue here. The kernel works, you've seen it working.
reloading immediately after rebooting the firmware always works, here.
Offline
I know that is what is so frustrating...
I know the kernel works and I know the reloaded module works.
But this doesn't.... (and I do try it immediately after booting).
That is why the only thing I could think of is that perhaps there is less free memory in my version of the hardware or something.
I wonder whether anything in the initrd can be trimmed
Offline
hmmmm I guess if memory is an issue, one possibility would be to try reloading after running ffp-reloaded (the original one) since that will have presumably released memory taken up by the ramdisk in the original configuration.
I actually tried this but it didn't work since I don't have a reloaded module that is compatible with the vanilla 2.6.12.6 kernel.
Do you think this approach might be a good "test" to see if memory is an issue?
Offline
and I have tried running it both with the initrd.gz that you supplied and with the one that I copied directly from my firmware (after taking off the initial uboot segment as you directed)
Offline
THIS IS FRUSTRATING - I have been playing with this for days and can't get your firmware-reloaded to work and it's hard to believe that I could be messing anything up -- just untar and run nohup ./boot.sh
Also, I know your kernel works, because it works for me also using ffp-reloaded.
So this really stumps me...
I just recompiled a smaller/simpler kernel than the 2.6.12.6-arm1-huge that you supplied.
Would it be possible to test whether it works for you? (not sure how to get it to you though since I don't see any 'button' for adding attachments on my screen here)
Offline
fonz wrote:
puterboy wrote:
I'm willing to try to help out here to get it to work with rev B1 however I can.
- Can you point me to anybody who is working on it so I can offer assistance?
- If nobody is working on it, are there any pointers and background that you can give me to get me started on trying to figure this out? (or is it too complicated and kernel-hacky)It most likely involves kernel hacking. The fix might be trivial, but I don't know. I don't know if anyone is actively working on it. But if someone is, you'll most likely find him here:
http://marc.info/?l=linux-arm-kernel&r=1&w=2
http://git.kernel.org/?p=linux/kernel/g … ;a=summary
Fonz, have you been using a purely vanilla 2.6.25 kernel or have you been using the Marvell/Orion branch (http://git.kernel.org/?p=linux/kernel/g … ;a=summary).
My understanding is that even though many arm/marvell changes were merged into 2.6.25, they continue to add in changes in their branches.
Do you have any experience or knowledge of this branch?
I am just asking what you have done before I start pulling in 100+MB of git kernel stuff.
Offline
puterboy wrote:
Fonz, have you been using a purely vanilla 2.6.25 kernel or have you been using the Marvell/Orion branch (http://git.kernel.org/?p=linux/kernel/g … ;a=summary).
2.6.25.1 + a few patches
puterboy wrote:
My understanding is that even though many arm/marvell changes were merged into 2.6.25, they continue to add in changes in their branches.
Do you have any experience or knowledge of this branch?
Yes. Afaict, it's still not complete, and there's an issue with the NIC driver.
Offline