<br><br><div class="gmail_quote">On Sat, Oct 15, 2011 at 10:53 AM, Lance Jump <span dir="ltr"><<a href="mailto:lancej29@gmail.com" target="_blank">lancej29@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br><br><div class="gmail_quote"><div>On Sat, Oct 15, 2011 at 9:21 AM, Andrew Bradford <span dir="ltr"><<a href="mailto:bradfa@gmail.com" target="_blank">bradfa@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div>On Fri, Oct 14, 2011 at 6:40 PM, Lance Jump <<a href="mailto:lancej29@gmail.com" target="_blank">lancej29@gmail.com</a>> wrote:<br>
> The board I have is the OpenRD client. It is based on the Marvell Kirkwood,<br>
> which is the same processor used in the PlugComputer. I have a config file<br>
> for an older kernel (2.6.18).<br>
<br>
</div>Can you try a CLFS build using 2.6.18 kernel source? The procedure<br>
should be the same, just you'll end up with different headers and an<br>
older kernel than what the book says.<br></blockquote></div><div><br>That is a test can try. But some of my later experiments (after my email yesterday) are leading e to believe that the problem is not actually in the kernel (more on that later).<br>
</div><div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><br>
> The reason I wanted a working config from the CLFS build is so that I can<br>
> check non-hardware related things like devpts and tmpfs settings. I<br>
> compared the one you sent to mine and found numerous non-hardware related<br>
> differences.<br>
<br>
</div>My kernel config is not at all optimized to have "the right stuff" in<br>
it. It's just the first config I had that worked well enough to boot.<br>
I wouldn't consider it to be a great example, but it is a working<br>
example.<br>
<div><br>
> I think since the ${CLFS}-final has already been created at that point and<br>
> there are other things being fixed up for it, that doing it in -final makes<br>
> the most sense.<br>
><br>
> I will try to get either the trac ticket or patch this weekend. Does the<br>
> protocol require a trac ticket against which to submit the patch?<br>
<br>
</div>If you just send a small-ish patch to -dev list, there's no need to<br>
open a trac ticket. My stance (not necessarily anyone else's) is to<br>
open tickets when the change will take a long time, involve more than<br>
just me, or if I don't have the urge to fix it right now. If you're<br>
fixing something you just found and it's small, just send a patch.<br></blockquote></div><div><br>After some of my experiments last night, I'm not sure of the right way to fix this. I am thinking that it might be just to remove the lines entirely.<br>
<br></div><div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><br>
> I have done some more experimenting and found some interesting things.<br>
> First, with only console and null in /dev I get repeated "Can't open<br>
> /dev/tty1: No such file or directory" (tty1..6) messages. When I create<br>
> these nodes, the messages go away.<br>
<br>
</div>You shouldn't need to create these nodes. mdev should be doing that<br>
for you. Of course, mdev doesn't run till after mounting everything<br>
in the startup script, so we're back to one of your original problems<br>
:)<br></blockquote></div><div><br>Well, this is part of the experimental results. Since every sysinit line in inittab will be executed in sequence, I was able to do much of the initialization that would normally be done by the startup script. Here are the lines:<br>
<br>::sysinit:/bin/rm -rf /dev<br>::sysinit:/bin/mkdir /dev<br>::sysinit:/bin/mount -t tmpfs -o mode=0755 none /dev<br>::sysinit:/bin/mkdir /dev/pts<br>::sysinit:/bin/mkdir /dev/shm<br>::sysinit:/bin/mount -a<br>::sysinit:/bin/echo "/sbin/mdev" > /proc/sys/kernel/hotplug<br>
::sysinit:/sbin/mdev -s<br><br>This all appears to work since I can then see dozens (hundreds?) of devices in /dev. But scripts still don't run and the login behaves exactly as before. Note that the first I thing I do is to delete and create /dev so it doesn't matter whether null or console were there -- they get created. (This is why I am leaning towards removing their creation from the book.)<br>
<br></div><div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><br>
> I can replace the sysinit line in inittab with just about anything else (for<br>
> example "mount -a" or "/bin/busybox --help" and it appears to do exactly<br>
> what is expected. In fact, I used the "mount -a" to locate missing mount<br>
> points in /dev (/dev/pts and /dev/shm).<br>
><br>
> I can also use various commands other than getty for the other lines in<br>
> inittab and they do as expected. For example if I used "touch /tmp/test" it<br>
> creates or updates the file /tmp/test. I seem to be able to do most things,<br>
> but I just can seem to execute a script no matter how simple. For example,<br>
> if I put the touch command in a script file and try to execute it, it does<br>
> nothing.<br>
<br>
</div>I think your ash might not be built right if you can't run scripts.<br>
That's odd, especially if things like touch or mount work. Are you<br>
changing the BusyBox config at all?<br></blockquote></div><div><br>I didn't make any changes to the busybox configuration -- I built it exactly as in the book. However, I am starting to think that the problem is in busybox (rather its configuration or related files) rather than the kernel. My previous experiments essentially show that the kernel works fine and seems to do whatever is asked of it. Since I didn't change busybox, it may be related to the environment files such as in /etc or /root. For example, Mike's earlier suggestion of securetty (which I tried without success, but I mean something like it). <br>
</div><div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><br>
> Another interesting things is that device detection for things like USB mice<br>
> and thumb drives and SD cards all appears to work except that none of it is<br>
> ever mounted. The drives are identified from driver messages as sda, sda1,<br>
> sdb... but nothing ever appears in the /dev directory. By the way, this is<br>
> also an indication that the kernel believes the serial port to be the<br>
> console.<br>
<br>
</div>mdev should be taking this info from the kernel and populating /dev for you.<br></blockquote></div><div><br>Yes, with the inittab "script" this appears to be the case.<br><br>I started looking into the busybox source to see I can tell what is happening. I don't believe the issue is in busybox per se, but I am thinking debug messages can help me find out where it going and where it is going astray. This is somewhat difficult without significant concentrated time and a debugger, but I am running out of other promising things to try. I'm sure the problem will turn out to be a typo on my part or something -- it's always a simple solution.<br>
<br></div></div></blockquote><div>I may have found something. I put debug printf calls in the ash.c source to see if it was getting that far and what was happening if it did. It does get to ash and it appears to crash after the first call call to setjmp. I removed that call and it got far enough to give me the "~ #" prompt. But as soon as I entered a command, it went back to the "Please press Enter ..." message. I followed it a bit further and found that it was crashing at another setjmp. So, I searched for "Busybox setjmp" and found lots of references to setjmp being broken in ARM uClib. Most were older, but few were more recent. A few made references to floating point configuration. Here are a couple:<br>
<br><a href="http://www.bettina-attack.de/jonny/view.php/projects/actiontec_dpcm_stuff/toolchain/" target="_blank">http://www.bettina-attack.de/jonny/view.php/projects/actiontec_dpcm_stuff/toolchain/</a><br><a href="http://lists.busybox.net/pipermail/uclibc/2002-February/023533.html">http://lists.busybox.net/pipermail/uclibc/2002-February/023533.html</a><br>
<br>I recall setting up for software floating point in the environment variables. I will go back and look at the uClib and kernel settings when I get a chance. This looks promising...<br> <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="gmail_quote"><div></div><div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><div></div><div><br>
-Andrew<br>
_______________________________________________<br>
Clfs-support mailing list<br>
<a href="mailto:Clfs-support@lists.cross-lfs.org" target="_blank">Clfs-support@lists.cross-lfs.org</a><br>
<a href="http://lists.cross-lfs.org/listinfo.cgi/clfs-support-cross-lfs.org" target="_blank">http://lists.cross-lfs.org/listinfo.cgi/clfs-support-cross-lfs.org</a><br>
</div></div></blockquote></div></div><br>
</blockquote></div><br>