Pengutronix first root login problem

I'm attempting to install Pengutronix to my mini2440, and when I get to the
portion where I need to login, the following occurs:

 ____ _______  __
|  _ `_   _` `/ /
| |_) || |  `  / 
|  __/ | |  /  ` 
|_|    |_| /_/`_`

           _       _ ____  _  _   _  _    ___  
 _ __ ___ (_)_ __ (_)___ `| || | | || |  / _ ` 
| '_ ` _ `| | '_ `| | __) | || |_| || |_| | | |
| | | | | | | | | | |/ __/|__   _|__   _| |_| |
|_| |_| |_|_|_| |_|_|_____|  |_|    |_|  `___/ 


OSELAS(R)-Mini2440-2011.12.0 / mini2440-2011.12.0
ptxdist-2012.01.0/2012-01-21T18:42:33-0500

mini2440 login: root
Password: 
Login incorrect



I am entering "root" as login, and nothing as password, just hitting enter,
and it tells me login incorrect.

Does anybody know if it requires a proper password, or how I can fix this
so that I can use root with no password?

root should work.

Try entering it again when asked, maybe you have a space before or after
it.

I noticed that you are running:
ptxdist-2012.01.0/2012-01-21T18:42:33-0500

Are not the BSP and ptxdist versions supposed to be the same? And 2011.12
was the last BSP

Let's try again:

If you get the login correct you should not be asked for a password.  So,
try again.  If that doesn't work maybe you have messed with your passwd
file.

Ok, I tried recompiling everything with the current version I'm using. It
still says Login incorrect, so now I'll try different versions and try to
match them and see if it works.

Did you add a file like "projectroot/etc/passwd" into you project or did
you change the content of the "<ptxdist-install-path>/generic/etc/passwd"?
One of these files will be used to create the "/etc/passwd" file on your
running Mini2440. And the one from the PTXdist installation defines the
user root without a password. Strange. Never seen this kind of failure from
our generic BSPs.

I also notice that there are not any lines after:

OSELAS(R)-Mini2440-2011.12.0 / mini2440-2011.12.0
ptxdist-2012.01.0/2012-01-21T18:42:33-0500

that tell you which tty you are using.

Have you got virtual terminal enabled so that you can see stuff on the
FriendlyArm?

Shows us your /etc/inittab

Ok, I tried compiling everything with version 2011.11.0, and I got some
errors along the way that prevented me from compiling the BSP, so I will go
back to the versions I used when I got the error from my original post, and
I will post the information requested when I get up to there.

As for the passwd file, I didn't touch it at all, so when that directory is
created again, I'll check on it.

Okay.

Juergen,

There is no file like "projectroot/etc/passwd", the contents of
"<ptxdist-install-path>/generic/etc/passwd" remain unchanged and are as
follows:

root:x:0:0:root:/home:/bin/sh
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
ftp:x:11:101:ftp user:/home:/bin/false
www:x:12:102:www user:/home:/bin/false
sshd:x:100:65534:SSH Server:/var/run/sshd:/bin/false
messagebus:x:103:104:messagebus:/dev/null:/bin/false
rpcuser:x:65533:65534:RPC user:/dev/null:/bin/false
nobody:x:65534:65534:Unprivileged Nobody:/dev/null:/bin/false

and the error persists.

davef,

I can't find any sort of file in /etc named inittab.

For picocom, I'm using ttyS4, and in picocom, I'll paste here the same as
my original post, but with the line preceding:

starting pid 405, tty '/dev/console': '/sbin/getty -L 115200 ttySAC0 vt100'

(ASCII art saying PTX mini2440)

OSELAS(R)-Mini2440-2011.12.0 / mini2440-2011.12.0
ptxdist-2012.01.0/2012-01-22T18:16:44-0500

mini2440 login: root
Password: 
Login incorrect

The mini2440 itself shows nothing on the screen.

The versions of files I'm using are as follows:

ptxdist-2012.01.0.tar.bz2
OSELAS.Toolchain-2011.11.0.tar.bz2
OSELAS.BSP-Pengutronix-Mini2440-2011.12.0.tgz

davef,

I found a few /etc/inittab files.

platform-mini2440/generic/etc/inittab is:

#
# /etc/inittab
#

console::sysinit:/etc/init.d/rcS
console::respawn:/sbin/getty -L @SPEED@ @CONSOLE@ vt100

# Stuff to do before rebooting
::ctrlaltdel:/sbin/reboot
::shutdown:/bin/umount -a -r


platform-mini2440/root/etc/inittab and 
platform-mini2440/root-debug/etc/inittab are both:

#
# /etc/inittab
#

console::sysinit:/etc/init.d/rcS
console::respawn:/sbin/getty -L 115200 ttySAC0 vt100

# Stuff to do before rebooting
::ctrlaltdel:/sbin/reboot
::shutdown:/bin/umount -a -r

platform-mini2440/build-target/busybox-1.18.5/examples/bootfloppy/etc/inittab
is:

::sysinit:/etc/init.d/rcS
::respawn:-/bin/sh
tty2::askfirst:-/bin/sh
::ctrlaltdel:/bin/umount -a -r

Don't know how much these help, but I hope they do.

Is /etc/inittab not ending up in your root filesystem?  Sounds like a
problem.

starting pid 405, tty '/dev/console': '/sbin/getty -L 115200 ttySAC0 vt100'

comes after:

OSELAS(R)-Mini2440-2011.12.0 / mini2440-2011.12.0
ptxdist-2012.01.0/2012-01-22T18:16:44-0500

on all versions of PTXdist that I have run over the last 6 months.  Seems
odd.

> For picocom, I'm using ttyS4, and in picocom, I'll paste here the same as
> my original post, but with the line preceding:

> starting pid 405, tty '/dev/console': '/sbin/getty -L 115200 ttySAC0
> vt100'

Have you got ttyS4 enabled as a serial port?
Why not put picocom on ttySAC0 as a starter?

What is the full location of /etc/inittab, maybe I'm missing something?

And for the serial port, I don't know if it's activated or not, I just
enter "sudo picocom -b 115200 /dev/ttyS4" when starting picocom. That's all
I know about the serial port. Are you suggesting using "sudo picocom -b
115200 /dev/ttySAC0" instead?

The full location is /etc/inittab

Yes,  Unless you enable the serial port for read/write it won't work.  For
example:

chmod 666 /dev/ttySAC1

Why are you trying to use ttyS4?

if /etc/inittab is the full location, then I seem to be lacking that file.

The picocom tutorial page I found said to to use ttySx with x as port
number. It was showing vivi, so I assumed it worked fine. I don't have
anything in /dev file like /ttySACx either, only ttySx files. I'm pretty
sure my serial port is indexed as ttyS4 since that is the only way I can
communicate with the mini.

Am I doing something very wrong?

Are you using the default kernel config, as found in the mini2440 2011.12
BSP?  Or are you selecting one of the other kernel configs?

Not seeing any ttySACx seems to be a major problem.

If you look into /platform-mini2440/root/etc you should see an inittab.

This should be on your target.

So, "ptxdist go" and "ptxdist images" work without errors.  How are you
getting your kernel and root filesystem unto the mini2440?

I'm following this guide:
http://wingston.workshopindia.com/wingz/embedded-programming-on-the-mini...

I'll try and explain everything I did.

ptxdist setup:
-go into extracted directory,
-$./configure
-$make
-$make install
-(skipped ptxdist setup since there is nothing to change)

Toolchain compilation:
-extract toolchain to /opt/OSELAS.Toolchain.etc.
-$ptxdist select
ptxconfigs/arm-v4t-linux-gnueabi_gcc-4.6.2_glibc-2.14.1_binutils-2.21.1a_kernel-
2.6.39-sanitized.ptxconfig
-$ptxdist migrate
-$ptxdist go

BSP compilation:
-extract BSP and navigate to it.
-Modify barebox-128m-env config file with network things, tftp, and nfs
root directory
-$ptxdist select configs/ptxconfig
-$ptxdist platform
configs/platform-friendlyarm-mini2440/platformconfig-NAND-128M
-$ptxdist migrate (Here i kept hitting enter taking default options when it
asked for extra packages to install, which ended up installing no extra
packages)
-$ptxdist go
-$ptxdist images
(Everything worked fine)

Bootloader through tftp:
-Mini connected through ethernet, usb, and serial.
-opened seperate terminal and ran:
 $sudo picocom -b 115200 /dev/ttyS4, picocom waits for mini
-set mini to NOR and turn on, this brings up the vivi bootloader in picocom
-in the first terminal (in BSP folder) ran:
 $sudo platform-mini2440/sysroot-host/bin/usbpush
platform-mini2440/images/barebox-image
-mini boots into this and I stop the autoboot bringing me to the
 mini2440:/ command line
-copy barebox-images to my tftp folder and rename it as barebox-mini2440
-run on mini:
 mini2440:/ update -t barebox -d nand
-bootloader is now on mini and I can switch back to NAND and come up with
this same command line through picocom.

Linux Image: (where the problem is)
-move linuximage to tftp folder renaming as uImage-mini2440
-set up NFS so it speaks to mini
-start up mini in NAND mode, let it autoboot, and it grabs uImage-mini2440,
booting into the screen where I need to input login and password.

This is where I input root as login and nothing as the password and it says
it is incorrect.

Go into documents and read through the Quickstart guide.

First, I have been told that ptxdist migrate is for experts only.  I got
into a mess several times, which I solved by deleting unwanted PTXdist
files in home/.ptxdist

You only need ptxdist 2011.11 to build the toolchain (I then delted any
reference to it in home/.ptxdist, then build ptxdist 2011.12 and lastly
build the BSP 2011.12.  No migrates or --force required.  There is another
method to do this properly by making softlinks to the version you want.

Search Pengutronix blogs on gmane, they are linked to from their website.

To save yourself future grief there is one thing you want to set up in
ptxdist and that is where your downloaded source files exist OR you will
download them everything you make a kernel/root filesystem. I save them in
/home/ptxdist/all_src

Your procedure does not describe actually putting the root filesystem on
the mini2440. The root filesystem should include /etc/inittab :)

Still curious why ttyS4?

Forget the last comment I haven't used NFS on this for the last few months.

delted = deleted
everything = everytime

Okay, that's a whole lot to take in. I think I'm going to have to try all
that tomorrow because it's getting late and I've used my allotted brain
power for the day.

Just to clear up before I start in the morning, I install ptxdist 2011.11.0
when compiling toolchain 2011.11.0 and I install ptxdist 2011.12.0 when
compiling BSP 2011.12.0? And if so, when I do this and I type ptxdist go,
it will not make me migrate or force at all? Does this mean that
migrate/force is when the ptxdist version does not match the files being
compiled?

Thanks a lot! I will post with results at some point tomorrow hopefully.

I hope so! 

> Does this mean that
> migrate/force is when the ptxdist version does not match the files being
> compiled? 

. . . does not match the mini2440-BSP version.

When you have a properly operating toolchain save your /opt directory, just
in case you lose it!  The rest of builds are much shorter!

Good luck

http://article.gmane.org/gmane.comp.embedded.ptxdist.oselas.community/73...

I think the link only needs to be in the BSP that you are working with.  If
you are trying to use multiple toolchains, you probably have to do
something more, as suggested.

Stick with one toolchain and one BSP version.  It will be easier now
because they are only coming out every 3 months :)

Also, are you sure your NFS setup is working properly?

Hi Pants,

you say the passwd file in your root filesystem is the same as the one from
the PTXdist installation directory. So, there is no password for the root
defined. Maybe something goes wrong when your target asks you for username.
What is your setting for <enter> in your terminal? CR, LF or CF+LF? It's
just a shot in the dark.
Another idea: You can start your kernel with the parameter "init=/bin/sh"
to get a shell on your target (without a login prompt). Maybe this will
discover something.
And the logfile would be of interst for me: please send the file
"platform-mini2440/logfile" (compressed) to my account jbe at pengutronix
dot de after you have built the whole BSP ("ptxdist go").
And, after running the command "ptxdist image" please send me also the
result archive "platform-mini2440/images/root.tgz"

Can someone let me know how to properly/fully uninstall ptxdist before I
reinstall a different version?

If you want to de-install it, just remove the
'/usr/local/lib/<ptxdist-version>' and the corresponding link in
'/usr/local/bin/ptxdist-<version>', and the file(s) from '$HOME/.ptxdist'.
That's all. It does not pollute your system with shared libraries or
something like that.
And: you can install all versions side by side. The do not conflict! You
only need some mechanism to always use the correct one in your project (me
sets up a link in every project to the correct versions. And then I use
only the link to call ptxdist):

$ ln -s /usr/local/lib/ptxdist-2012.01.0/bin/ptxdist p
$ ./p menuconfig
$ ./p go
$ ./p images (and so on)

Hi Pants,

I tried your root filesystem archive you sent me, and it works as expected.
I can login as 'root' without a password.

Interesting... Does it matter where I am located in the terminal to link
them? or can I do it from anywhere?

Really? Then what am I doing wrong?

> Still curious why ttyS4?

Yes, davef. I don't get why everyone else has their serial port as ttySAC0
but mine is recognised as ttyS4.

Where is it recognised as ttyS4? /dev?

You have your serial cable connected to the 9pin D range, right? 
Unmodified mini2440?

Serial cable connected from pci card in computer up to mini's only 9-pin
serial port.

It is recognized as ttyS4 on my ubuntu machine in /dev.

> It is recognized as ttyS4 on my ubuntu machine in /dev.

If you can't log into the mini2440 and look at /dev on the target, how can
you determine which tty it is using?

Are you looking at the serial port being used by the ubuntu machine?

My toys are at home, but I think  you need to tell picocom you want to
communicate with ttySAC0.

I just tried it because you got me curious. If I replace ttyS4 with ttySAC0
(I tried ttyS0-ttyS6), it doesn't activate at all. ttyS4 seems to be the
only one that works.

> ttyS4 seems to be the only one that works.

But, it doesn't seem to work properly.

If you have done a default kernel compilation, I think the FriendlyArm
touchscreen should work (virtual terminal in kernel config).  Does anything
show up on the touchscreen?

Nothing shows up on the screen at all during the process. It flashes a
couple times, then either stays off, or keeps the backlight on depending on
which stage I'm in, but never does it have any sort of UI.

Here's what you might have to do in the kernel:

http://article.gmane.org/gmane.comp.embedded.ptxdist.oselas.community/58...

and /etc/inittab needs another entry:

console::respawn:/sbin/getty -L 9600 tty1 vt100

That is from memory.  Now, you should be able to work from the FA and then
later work out why you can't talk to it from the host.

in inittab the line:
console::respawn:/sbin/getty -L 115200 ttySAC0 vt100
is already there.

Do I replace this line with:
console::respawn:/sbin/getty -L 9600 tty1 vt100
or just place this new line below it?

Place it below this line.

Okay, I tried running it again, and it still isn't working. I get a new
error after incorrect login:

starting pid 423, tty '/dev/console': '/sbin/getty -L 9600 tty1 vt100'
process '/sbin/getty -L 115200 ttySAC0 vt100' (pid 420) exited. Scheduling
for restart.

or

starting pid 415, tty '/dev/console': '/sbin/getty -L 9600 tty1 vt100'
process '/sbin/getty -L 9600 tty1 vt100' (pid 415) exited. Scheduling for
restart.


Should I just start over from scratch, or will I just end up making the
same mistake if I don't know what I'm doing?

You should get those before the login prompt comes up.  Going back to
previous comments I don't understand why those prompts are being announced
in an unusual place.

Also, those errors you get do they keep repeating themselves?  I have had
that happen as well, which was cured by the changes just above.

I think we need to back-up a bit.  Which variant mini2440 and LCD are you
using?

Another suggestion is to try putting the kernel and root filesystem into
NAND before trying NFS.

I'm using the mini2440 with 128M NAND, and the W35i screen.

I think I'm just going to start the process over and see if I can avoid
this by following the quickstart guide instead of the online guide I was
using.

Good idea.  A lot of work has gone into that document.  Anything which
makes it easier to get results quickly, I am sure would be appreciated.

W35i, better search that screen out on here, I think it caused a few
problems.  Did you ever run the original FriendlyArm distro successfully?

The stock shipped Qtopia? Yes, it was working perfect when we received it.

Try to login into your Mini2440 target via telnet. Does it work in this way
(also 'root' without password)? If it works this way then run the 'getty'
line manually from this console, but with "strace" please.

root@mini2440: strace /sbin/getty -L 115200 ttySAC0 vt100

When this line is running you should see an new message in your serial
terminal. Then try to login in this terminal and watch what 'getty' really
does. Maybe the log of the 'strace' output would be of interest for us.

BTW: 'ttyS' versus 'ttySAC': 'ttyS' is the device node name for all 8250
based UARTs. 'ttySAC' is the device node name for Samsung UARTs, like the
ones in the S3C2440 CPU. So, you can use the 'ttyS' only on your x86 based
host, not at the Mini2440 side. And the 'ttySAC' can only be used at the
Mini2440 side, not at your x86 based host.
So, everything is all right, if the Mini2440 uses the "ttySAC0" and your
host uses the 'ttyS4'.

I re-did the whole process, I used the 2 different typed of ptxdist to
match both the Toolchain, and the BSP, and I did steps that I missed when
using the other tutorial, and now, I am finally able to log in as root. The
filesystem and kernel are both transferred to nand, and I can boot the mini
into linux while connected to my computer through picocom with no problems.

I just want to confirm that there is nothing shown on the lcd and all work
is done through the terminal on the host computer.

Now I need to find out how to use PWM to drive servos and see if there is a
way I can make this work in real time :D

Thanks everyone for the help.

> I just want to confirm that there is nothing shown on the lcd and all
> work is done through the terminal on the host computer.

Re-read the previous comments about activating the touchscreen.  Any
problem there just post your bootup messages.

Good to hear you got there in the end.  Something I think that would have
resolved things sooner is you need the answer questions that people put to
you.  The query about ttys4 occurred about 1/2 the way through this thread.

Good luck with the PWM.

Pants,

Perhaps to tidy off the job advise Wingston what he missed and suggest
against using ptxdist migrate.  I was "told off" by the PTXdist gurus!

Dave

The thing is : everytime i did a ptxdist go from a new setup it always
gives an error because of some config file and to run ptxdist migrate to
fix it.
When i do run migrate, it asked for (i think) all the new entries a y/n
option which i always do no to. 
what are the exact missing steps? (for me to add them) :)

See the link to gmane above.  

The way I was doing it was a "workaround" the correct way is to make links.


I suggest the following:

********************
Section 3.3.3

Before building the toolchain make a link to the correct PTXdist to build
that toolchain, ie:

$ ln -s /usr/local/bin/ptxdist-2011.11.0 p

then change all calls to ptxdist to ./p  for example

./p select ptxconfigs/armv4t- . . .
./p go

Section 4.3

Before building the kernel and root filesystem, delete the above link and
make a new link:

$ ln -s /usr/local/bin/ptxdist-2011.12.0 p

then change all calls to ptxdist to ./p for example

./p select configs/ptxconfigs

*******************

I haven't tested this, so I'd suggest you try it out before publishing.

you must change attribute of "passwd" and "shadow" file in /etc/ to be
writeable readable and excute by command :

sudo chmod a+rwx /etc/passwd
sudo chmod a+rwx /etc/shadow

and then reboot your mini2440 board
login with root user without password.

BTW: What issue should this change solve?
The 'passwd' and the 'shadow' files do never need execution permission. And
it is a really bad idea (and a huge security hole) to make the 'shadow'
file world read and write able.

I agree with Juergen Beisert. It's not safe for that permission of files.
So sorry that is my bad habit to change permission of files.
just only use 

sudo chmod a+r /etc/password
sudo chmod a+r /etc/shadow

it's enough for login to mini2440 linux.
It can be solve login incorrect problem.
(I got this problem too and can be solved be this solution)

To keep the read permission for all is still no solution. It seems in your
system something is wrong with the user ids, the processes are running on.
The login process runs as root. So, there should be no problem to be able
to read the /etc/shadow, even if this file has only 0400 permissions.
BTW: how did you change the permissions of this file, when the login fails?

I'm new in mini2440 just like Mr.Pants. This is the first time I use this
board and I have the save problem as him.
Then I solved the problem by using chmod a+r method.
I see the permission of passwd and shadow file have read permission on root
only. and then I change that permission to readonly to all of user by chmod
a+r. it can work properly but I don't know why.

I use the linuxkernel, root.nffs2 file and extract root.tgz to nfs.
I change passwd and shadow permission with my ubuntu.
Am I setup or config something mistake?

I tried it here with the sparse information I have about your environment.
When I extract the root.tgz archive anywhere in my filesystem, exporting
this directory via NFS server but with the 'root_squash' option set I also
get:

mini2440 login: root
Password:
Login incorrect

After adding the 'a+r' to the etc/shadow I can login into this system. This
could be a solution, but its not the cause of your trouble:

You must take into account at the Mini2440's side the user 'root' is
working. Some things at system start-up have to be done as root, because
for some actions only root has the permissions to do so. But now you are
using an NFS root filesystem. And the user 'root' at the Mini2440 side
depends on the permissions to act as 'root' also in the filesystem. But the
NFS server option 'root_squash' (the default) prevents any external host
from being 'root' on the local filesystem. So, the 'root' at the Mini2440
fails when it tries to access special files in the NFS root filesystem (in
your case it fails to access the etc/shadow).

Real solution: add the 'no_root_squash' option to the exported filesystem
and the Mini2440's 'root' is also 'root' at your local filesystem (with all
risk, drawbacks and security holes, so never export the your whole
filesystem in this way).