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

Lance Jump lancej29 at gmail.com
Mon Oct 10 08:39:25 PDT 2011


On Mon, Oct 10, 2011 at 10:54 AM, Andrew Bradford <bradfa at gmail.com> wrote:

> On Mon, Oct 10, 2011 at 10:40 AM, Lance Jump <lancej29 at gmail.com> wrote:
> > /dev/ttyS0 is the USB/serial console.  It is my only console connection
> to
> > either u-boot or Linux and all of the output appears to go there.  It is
> > also the "console=" in the Linux command line.  When I execute something
> > (inittab) other than getty (e.g. ls) the output goes there.  When I do
> getty
> > in inittab, it does put out a message saying that root logged in on
> > /dev/ttyS0.  Is it still possible that this connection is actually not
> > /dev/ttyS0?  How would I check and/or correct?  If it is not /dev/ttyS0,
> > what might it be?
>
> >> Can you provide the entire boot output including uboot output data?
> >> http://pastebin.cross-lfs.org/
> > Done.
>
> For those not searching, direct link here:
> http://pastebin.cross-lfs.org/230524
>
> > I wanted to "lock down" a repeatable configuration with a specific
> > distribution.  As I recall, LFS-Live was actually recommended in one of
> the
> > CLFS books (maybe this one).  The chroot also allows me ensure that
> nothing
> > "gets outside" the environment and to very easily "snapshot" places in
> the
> > development or start over completely without having to worry about any
> > lasting side effects on my main system.
>
> Understandable.  The LFS live CD should work well for building but
> I've not personally tried it.
> If you follow the embedded book exactly for creating the user account
> to build an embedded system, nothing will leak into your build from
> the host.
>

Yes, it is well thought out in that respect.  The problem is the "follow it
exactly" part. Experience has shown me that I make enough mistakes to want a
safety net.

>
> How do you snapshot builds?  I'm curious as I've not found an easy way
> that works well.
>

The "snaphot" to which I refer is basically being able to build up to a
certain point and start over from there if I make a mistake later in the
process.  I have everything from the book scripted so I can exactly
reproduce my steps.  At the end of a script (typically a chapter) I will
archive the result as a "snapshot" of the build to that point.  I used to do
this with a virtual machine (I bought VMware workstation for the multiple
snapshot capability).  But what I do now is simply tar my chroot
environment.  To go back, I delete the current chroot tree and untar an old
one.


>
> > The bootscripts appear to be in /etc/rc.d/init.d and related.  This
> agrees
> > with inittab. The startup script does have code in it to perform the
> mounts,
> > but it is looking like it never executes.  I have echo messages in it
> both
> > to the console and to a file in /var/log and I never see anything.
>
> Based on your pastebin, your bootscirpts aren't executing.  There
> should be some nice "OK" messages printed out for things like doing
> the mounts, bringing up networking, and starting services.  Your
> output doesn't appear to have any of that.
>
> Example:
> init started: BusyBox v1.17.3 (2011-02-27 14:07:01 EST)
> Starting mdev: OK
> Mounting devpts: OK
> Starting fsck for local filesystems.
> Checking local filesystems: OK
> Enabling swap space: OK
> Remounting root rw: OK
> Setting hostname: OK
> Cleaning up system: OK
> Setting up interface lo: OK
> Running start scripts.
> Starting syslogd: OK
> Starting klogd: OK
>
> I think that's part of your problem but possibly not the entire problem.
>

I agree that scripts are not running.  My earlier experiments of putting
messages (including echoing to files) appears to confirm this.  I seem to be
able to run various things by replacing sysinit and TTY entries in inittab.
So inittab is being read and busybox runs as do various applets.  But it
seems that sh (or ash or whatever) itself will not actually run so no shell
scripts (e.g. startup) can run.

-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/20111010/51fbeb7e/attachment-0001.htm>


More information about the Clfs-support mailing list