From: Gerald B. <gbr...@mi...> - 2000-04-12 04:50:24
|
After downloading the 2.3.99-pre4-1um kernel and trying to boot it, I get this message when trying to run init: Usage: ld.so [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...] You have invoked `ld.so', the helper program for shared library executables. This program usually lives in the file `/lib/ld.so', and special directives . . . It's acting as if it's not properly passing arguements to the dynamic linker when it executes. I can get it to run if i boot with init=/sbin/sash. sash comes up and runs and I can do stuff in it, but if i try to execute anything, I get a kernel segfault error. My host system is a 2.2.15pre16+ext3+kdb+autofs4 SMP kernel running redhat 6.1. any ideas? |
From: Jeff D. <jd...@ka...> - 2000-04-12 14:37:42
|
Can you show us the console output? I don't think it matters, but what are you booting it from? Jeff |
From: Gerald B. <gbr...@mi...> - 2000-04-12 14:49:52
|
I'm just running it in an xterm. I got essentially the same results when running the previous 2.3.99-pre3 version. A capture of the console output is below. -- Gerald % ls 2.3-patch* README UserModeLinux-HOWTO.txt linux* root_fs % ./linux signal thread pid = 5415 idle thread pid = 5416 Linux version 2.3.99-pre4-1um (jd...@cc...) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #143 Tue Apr 11 19:50:22 EST 2000 On node 0 totalpages: 4096 zone(0): 256 pages. zone(1): 3840 pages. zone(2): 0 pages. Calibrating delay loop... 241.17 BogoMIPS Memory: 16080k available Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes) Page-cache hash table entries: 4096 (order: 2, 16384 bytes) VFS: Diskquotas version dquot_6.4.0 initialized POSIX conformance testing by UNIFIX Linux NET4.0 for Linux 2.3 Based upon Swansea University Computer Society NET3.039 NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 1024 bind 1024) Starting kswapd v1.6 pty: 256 Unix98 ptys configured Initializing stdio console driver Initializing software serial port version 0 serial line 0 assigned pty /dev/ptyp0 ssl receive thread is pid 5421 devfs: v0.93 (20000306) Richard Gooch (rg...@at...) devfs: devfs_debug: 0x0 devfs: boot_options: 0x0 VFS: Mounted root (ext2 filesystem) readonly. Mounted devfs on /dev Usage: ld.so [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...] You have invoked `ld.so', the helper program for shared library executables. This program usually lives in the file `/lib/ld.so', and special directives in executable files using ELF shared libraries tell the system's program loader to load the helper program from this file. This helper program loads the shared libraries needed by the program executable, prepares the program to run, and runs it. You may invoke this helper program directly from the command line to load and run an ELF executable file; this is like executing that file itself, but always uses this helper program from the file you specified, instead of the helper program file specified in the executable file you run. This is mostly of use for maintainers to test new versions of this helper program; chances are you did not intend to run this program. --list list all dependencies and how they are resolved --verify verify that given object really is a dynamically linked object we get handle --library-path PATH use given PATH instead of content of the environment variable LD_LIBRARY_PATH --inhibit-rpath LIST ignore RPATH information in object names in LIST |
From: Jeff D. <jd...@ka...> - 2000-04-12 17:25:32
|
If -pre3 does the same thing, did it ever work? If so, what did you change :-) That ls makes it look like you grabbed the Debian package. Is it still the stock root_fs, or did you do anything to it? I just booted up that root_fs to check, and it works fine for me. I'm going to back off my earlier claim that it doesn't matter what you're booting from. I can't think of anything else that makes any sense. There's no way that it should be trying to exec ld.so, which is what I think that error message is saying. Can you try making and booting a tiny filesystem with init, the shared libraries that it needs, ld.so, and maybe an inittab? Just enough stuff to get init up and running a little. If that works, then that would make it look like something's wrong with the root filesystem. Jeff |
From: Gerald B. <gbr...@mi...> - 2000-04-12 17:31:35
|
On Wed, Apr 12, 2000 at 01:19:55PM -0500, Jeff Dike wrote: > If -pre3 does the same thing, did it ever work? If so, what did you change :-) I haven't ever gotten it to work and haven't changed anything. > That ls makes it look like you grabbed the Debian package. Is it still the > stock root_fs, or did you do anything to it? I just booted up that root_fs to > check, and it works fine for me. Yep, it's the debian package. > I'm going to back off my earlier claim that it doesn't matter what you're > booting from. I can't think of anything else that makes any sense. There's > no way that it should be trying to exec ld.so, which is what I think that > error message is saying. When executing any dynamically linked executable, ld.so is run to link in all the librarys the program uses. > Can you try making and booting a tiny filesystem with init, the shared > libraries that it needs, ld.so, and maybe an inittab? Just enough stuff to > get init up and running a little. If that works, then that would make it look > like something's wrong with the root filesystem. It does the same thing with any dynamically linked executable used as init, if i use a statically linked executable as init, that works. But I then cannot execute anything. If i try, the kernel panics with the message "Bogus address in segv" -- Gerald |