[Clfs-support] Cannot login on serial port (embedded ARM, busybox)

Sat Oct 15 07:53:55 PDT 2011

On Sat, Oct 15, 2011 at 9:21 AM, Andrew Bradford <bradfa at gmail.com> wrote:

> On Fri, Oct 14, 2011 at 6:40 PM, Lance Jump <lancej29 at gmail.com> wrote:
> > The board I have is the OpenRD client. It is based on the Marvell
> Kirkwood,
> > which is the same processor used in the PlugComputer.  I have a config
> file
> > for an older kernel (2.6.18).
>
> Can you try a CLFS build using 2.6.18 kernel source?  The procedure
> should be the same, just you'll end up with different headers and an
> older kernel than what the book says.
>

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).

>
> > The reason I wanted a working config from the CLFS build is so that I can
> > check non-hardware related things like devpts and tmpfs settings.  I
> > compared the one you sent to mine and found numerous non-hardware related
> > differences.
>
> My kernel config is not at all optimized to have "the right stuff" in
> it.  It's just the first config I had that worked well enough to boot.
>  I wouldn't consider it to be a great example, but it is a working
> example.
>
> > I think since the ${CLFS}-final has already been created at that point
> and
> > there are other things being fixed up for it, that doing it in -final
> makes
> > the most sense.
> >
> > I will try to get either the trac ticket or patch this weekend.  Does the
> > protocol require a trac ticket against which to submit the patch?
>
> If you just send a small-ish patch to -dev list, there's no need to
> open a trac ticket.  My stance (not necessarily anyone else's) is to
> open tickets when the change will take a long time, involve more than
> just me, or if I don't have the urge to fix it right now.  If you're
> fixing something you just found and it's small, just send a patch.
>

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.

>
> > I have done some more experimenting and found some interesting things.
> > First, with only console and null in /dev I get repeated "Can't open
> > /dev/tty1: No such file or directory" (tty1..6) messages.  When I create
> > these nodes, the messages go away.
>
> You shouldn't need to create these nodes.  mdev should be doing that
> for you.  Of course, mdev doesn't run till after mounting everything
> in the startup script, so we're back to one of your original problems
> :)
>

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:

::sysinit:/bin/rm -rf /dev
::sysinit:/bin/mkdir /dev
::sysinit:/bin/mount -t tmpfs -o mode=0755 none /dev
::sysinit:/bin/mkdir /dev/pts
::sysinit:/bin/mkdir /dev/shm
::sysinit:/bin/mount -a
::sysinit:/bin/echo "/sbin/mdev" > /proc/sys/kernel/hotplug
::sysinit:/sbin/mdev -s

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.)

>
> > I can replace the sysinit line in inittab with just about anything else
> (for
> > example "mount -a" or "/bin/busybox --help" and it appears to do exactly
> > what is expected. In fact, I used the "mount -a" to locate missing mount
> > points in /dev (/dev/pts and /dev/shm).
> >
> > I can also use various commands other than getty for the other lines in
> > inittab and they do as expected. For example if I used "touch /tmp/test"
> it
> > creates or updates the file /tmp/test. I seem to be able to do most
> things,
> > but I just can seem to execute a script no matter how simple.  For
> example,
> > if I put the touch command in a script file and try to execute it, it
> does
> > nothing.
>
> I think your ash might not be built right if you can't run scripts.
> That's odd, especially if things like touch or mount work.  Are you
> changing the BusyBox config at all?
>

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).

>
> > Another interesting things is that device detection for things like USB
> mice
> > and thumb drives and SD cards all appears to work except that none of it
> is
> > ever mounted.  The drives are identified from driver messages as sda,
> sda1,
> > sdb... but nothing ever appears in the /dev directory.  By the way, this
> is
> > also an indication that the kernel believes the serial port to be the
> > console.
>
> mdev should be taking this info from the kernel and populating /dev for
> you.
>

Yes, with the inittab "script" this appears to be the case.

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.

> -Andrew
> _______________________________________________
> Clfs-support mailing list
> Clfs-support at lists.cross-lfs.org
> http://lists.cross-lfs.org/listinfo.cgi/clfs-support-cross-lfs.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.clfs.org/pipermail/clfs-support-clfs.org/attachments/20111015/6cc851e3/attachment-0001.htm>