Re: Problems with HardHat/NFS root filesystems

Re: Problems with HardHat/NFS root filesystems

[TWG - pat, mark & steve]

Thanks, Wolfgang, for your response.  It helped somewhat.  Here's what I
discovered:

1. I am also unable to run ash.static
2. I forgot to mention another error message (actually, I thought it was
trivial but it's not), I also get a "Warning: unable to open an initial
console" error message.

3. I also had to make a change when installing HHL, and I think this is
the key to my problem.  Basically, the RedHat install I chose left me with
a relatively small root partition, giving most of the disk space to
partitions mounted as /usr and /home.  Since the HHL stuff wouldn't fit in
/opt, I made a directory, /usr/opt, and linked it to /opt. (soft)

In /etc/exports, I export the volume as /opt/hardhat.....

However, when I do an "exportfs -av" the exported volume shows up as
/usr/opt/hardhat.....

I specified /opt/hardhat... in /etc/dhcpd.conf

I think, therefore, that NFS is not allowing access to the proper
directories, and that's why it can't find an init (or a /dev/console!)

Am I on the right track?
Thanks,
Mark Phillips


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Problems with HardHat/NFS root filesystems

[Wolfgang Denk]

In message <Pine.SGI.3.95.1000705121641.27740C-100000@world.std.com> you wrote:
>
> Thanks, Wolfgang, for your response.  It helped somewhat.  Here's what I
> discovered:
>
> 1. I am also unable to run ash.static

Then shread libs are not your primary problem.

> 2. I forgot to mention another error message (actually, I thought it was
> trivial but it's not), I also get a "Warning: unable to open an initial
> console" error message.

OK - that's a different issue, then.


> In /etc/exports, I export the volume as /opt/hardhat.....
>
> However, when I do an "exportfs -av" the exported volume shows up as
> /usr/opt/hardhat.....
> I specified /opt/hardhat... in /etc/dhcpd.conf
>
> I think, therefore, that NFS is not allowing access to the proper
> directories, and that's why it can't find an init (or a /dev/console!)
>
> Am I on the right track?

I think so - most probably your target can't see the files it  needs.
You should be able find out by running some network analyzer (tcpdump
might be enough for the job; ethereal will make it more convenient).

The quick test is to fix your configuration and try it out :-)

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
If it went on at this rate, in several billion  years  he'd  be  rich
beyond his wildest dreams!            - Terry Pratchett, _Soul Music_

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Problems with HardHat/NFS root filesystems

[mark phillips]

Hi all, great list!

I've been working with HardHat Linux on an Embedded Planet CLLF board
(mpc860T processor).  Initial progress was great, but I've run into a
dead end.
I have been able to run the mbxroot.min filesystem (both on NFS and as
an initrd).  However, I am unable to run either mbxroot.full or the
HardHat "target" filesystem
(Both obviously under NFS due to their size).  I am convinced that my
problem has something to do with the shared libraries (But I've been
wrong before!).

In addition, I've noticed that if I run ldconfig on the mbxroot.min
filesystem, it no longer boots.  Removing etc/ld.so.cache fixes the
problem.  I believe both the mbxroot-full filesystem and the HardHat
"target" filesystem are untouched from their original versions.

My host is an i386/RedHat 6.2 Can I run this ldconfig on a ppc
filesystem, or do I need a cross-platform version? (command line:
/sbin/ldconfig -r <target_dir> )

Basically, the symptoms are that the kernel can't find an init.  I ran
tcpdump while booting, and everything looked pretty normal; lots of NFS
queries (but not much or no actual data transfer).  Interestingly the
trace ends with a bunch of queries to
/opt/hardhat/devkit/ppc/8xx/target/opt.

I would greatly appreciate it if anyone has any solution to this
problem, or even if someone could propose a debugging strategy for me?
I've tried both the HardHat CDK 1.0 and the newer Journeyman (CDK 1.1),
both with the same results.
Thanks in advance,
Mark Phillips


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Problems with HardHat/NFS root filesystems

[Wolfgang Denk]

Hi MArk,

in message <39625545.370FE91F@ne.mediaone.net> you wrote:
>
> I have been able to run the mbxroot.min filesystem (both on NFS and as
> an initrd).  However, I am unable to run either mbxroot.full or the
> HardHat "target" filesystem
> (Both obviously under NFS due to their size).  I am convinced that my
> problem has something to do with the shared libraries (But I've been
> wrong before!).

I guess you are right here.

> In addition, I've noticed that if I run ldconfig on the mbxroot.min
> filesystem, it no longer boots.  Removing etc/ld.so.cache fixes the

Don't do this. If you feel you must, get a target running  over  NFS,
and run the native PPC binary on the target.

> problem.  I believe both the mbxroot-full filesystem and the HardHat
> "target" filesystem are untouched from their original versions.

Don't believe anything; reinstall from the archive /  RPMs;  for  the
HHL RPM's, you can also check by using the "rpm --verify" option.

> My host is an i386/RedHat 6.2 Can I run this ldconfig on a ppc
> filesystem, or do I need a cross-platform version? (command line:
> /sbin/ldconfig -r <target_dir> )

I recommend NOT doing it.

> Basically, the symptoms are that the kernel can't find an init.  I ran

HHL comes wityh at least 2 statically linked shells:  /bin/ash.static
and /bin/sash - use one of them as init process by passing the option
"init=/bin/ash.static" on the boot command line.

If this works, you have a native environment which  you  can  use  to
investigate further.

If this does not work, your problem has nothing  to  do  with  shared
libraries.

> tcpdump while booting, and everything looked pretty normal; lots of NFS
> queries (but not much or no actual data transfer).  Interestingly the
> trace ends with a bunch of queries to
> /opt/hardhat/devkit/ppc/8xx/target/opt.

Please pay attention to the fact that HHL has a strange  way  to  fix
the  absolute  path problem for their shared libraries; in the target
root    directory    there    must     be     a     symbolic     link
"/opt/hardhat/devkit/ppc/8xx/powerpc-linux" pointing to "/", i.e. you
should see something like this:

-> ls -l /opt/hardhat/devkit/ppc/8xx/target/opt/hardhat/devkit/ppc/8xx/powerpc-linux
lrwxrwxrwx   1 root     root            1 May 10 23:58 /opt/hardhat/devkit/ppc/8xx/target/opt/hardhat/devkit/ppc/8xx/powerpc-linux -> /

> I would greatly appreciate it if anyone has any solution to this
> problem, or even if someone could propose a debugging strategy for me?

See above - try a shell with static linkage as init process.

> I've tried both the HardHat CDK 1.0 and the newer Journeyman (CDK 1.1),
> both with the same results.

Probably the same problem?

> Thanks in advance,

You're welcome...

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
I know engineers. They love to change things.             - Dr. McCoy

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Problems with HardHat/NFS root filesystems

[Dan Malek]

mark phillips wrote:

> I've been working with HardHat Linux on an Embedded Planet CLLF...

> I have been able to run the mbxroot.min filesystem (both on NFS and as
> an initrd).


I'm surprised this even works.  Mixing tools and libraries is always
a challenge and seldom works.  The HHL tools and libraries are built
as a kit that works together.  The tools generate in-line floating point
and have startup functions ro glibc2.  The HHL tools, libraries and target
file system work together, and it is unlikely you will be able to mix
other pieces with any success.

The 'min' and 'full' file systems are old, glibc-1.99 version software.
The HHL tools will not build executables to work with this library.
It was a nicer library to use for embedded systems because it was smaller,
but it was simply obsolete and we couldn't maintain it.  You can strip
the libraries in the target file system to make them smaller, however
I think it removes symbols needed for linking (but programs run OK).
You can also download the glibc SRPM and remove functions you don't need,
then rebuild it with the HHL tools.


> In addition, I've noticed that if I run ldconfig on the mbxroot.min
> filesystem, it no longer boots.  Removing etc/ld.so.cache fixes the
> problem.

Don't run ldconfig......you don't need to do that, and as you have
experienced it does the wrong thing.

> ....trace ends with a bunch of queries to
> /opt/hardhat/devkit/ppc/8xx/target/opt.

You need a symbolic link in the target file system to resolve the
problem with abosulte path names of libraries in the dynamic loading.
In the /opt/hardhat/devkit/ppc/8xx/target directory on the server,
create a symbolic link opt/hardhat/devkit/ppc/8xx/powerpc-linux -> /.
This way, the target file system "sees" the same directory path that
was used when you cross compile on the host.


	-- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Problems with HardHat/NFS root filesystems

[Tom Roberts]

I, too, had shared-library troubles with this.

My solution was to use the Suse PowerPC Beta distribution CDROM I
got as a door prize. I could not boot from the CDROM (no drive
on my board), but I did manually build up a disk filesystem by
starting from their initial root and then installing all of their
core RPMs on top of it. I ended up with a complete Linux system,
including gcc, gdb, etc., about 180 MB total. It works great for me.

	It is a great convenience to have the embedded board hosted
	on another Linux system which is the NFS fileserver for the
	board; they of course share all logins.

This board is a 200 MHz 750 with 64 MBytes SDRAM, so it is just a bit
bigger than most embedded systems. Now to get the other two CPUs
running....


Tom Roberts	tjroberts@lucent.com

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/