[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Kernel panic. No init found



Tim wrote:
> At 01:17 20/07/02 +0100, Oliver Elphick wrote:
> >olly@linda$ ls -l /lib/ld-2.2.5.so /lib/libc-2.2.5.so
> >-rwxr-xr-x    1 root     root        88578 Jul 17 04:52 /lib/ld-2.2.5.so
> >-rwxr-xr-x    1 root     root      1149584 Jul 17 04:52
> >/lib/libc-2.2.5.so
> 
> I've located the original files having seen your message; the problem was a 
> name change in the symbolic link files (you may have noticed this-loss of 
> one digit).  I've corrected this by creating correctly named symbolic 
> links, and the boot phase now goes past the 'No init found' message.  So 
> progress is being made!
> 
> But.  The boot process stops further on:
> 
> /bin/sh: error while loading shared libraries: libncurses.so.5: cannot open 
> shared object file: No such file or directory.
> INIT: Entering runlevel: 2
> /bin/sh: error while loading shared libraries: libncurses.so.5: cannot open 
> shared object file: No such file or directory.
> (none) login: root
> /bin/login: error while loading shared libraries:libdl.so.2: cannot open 
> shared object file: No such file or directory.
> (none) login: root

I'm using an older distro so I'm probably not totally fresh here, but of the 
files that seems to be missing for you,

libdl is I believe the most crucial one, and it has to be
the right version as well. 
It's not that large. (< 100kB)
libncurses (4.2) (< 300k

In my (very old) system libdl exists in /lib
while libncurses is installed in /usr/lib 

( I'm still puzzled as to what program it is that uses ncurses while booting ? 
I would actually consider it to be a bug.)

Other file that might be of some importance I think, is /lib/libm.so

Any way it seems like file corruption has struck you in more directories than
one. 
A guess of mine is that You have downloaded Debian from a phone line?
This would make a complete reinstall pretty  awkward. 

So perhaps it's worth some effort to try to save the remains of your in-
stallation, when facing a near 50 hour download otherwise? second guess?

I'm not saying that it is though, Do read on to see what you have to deal 
with.

You say that windows is bad for downloading large files? There are some tools 
that you can download for downloading purposes. One is called Gozilla, the 
other is called Getright. By ease of use I prefer Gozilla even tough it has 
a funny gui. I believe they work in some similarity with the wget tool
for linux, or apt-get(without being package or domain specific)


Before I Continue Tim I want to say that I wrote this in order to clear
my own point of view regarding some of the Debian installation philosophy.
So All of this text is not really just for your eyes. mostly it's there for 
my own an perhaps for a few others.



If you are just interested in specific info that might be of interest 
to you regarding savouring your broken file system look a head for the word: 


`sorry-bout-that-tim'


File system corruption really shouldn't mean that you are forced to do a
full re-install, especially not when it takes 50 hours to download the stuff
This is no better than f ex The Redhat or Suse philosophies.

Yet Debian developers say that they want to  bring a distro with  quality 
assurance. I think that Debian developers should at least try to make their 
system just a little bit more failsafe than the others, just because of
the network download and install issues.

I run on a tripple backuped system (yes I have a dos rescue partition
of 15MB with loadlin and root ramdisks (hda1), One 50 MB linux Resque 
only partition (hda3), as well as a fairly resent bzipped image of my 
install(hdc2), Yes forgot I also have some boot floppies that I will 
probably never need ) I always use this install scheeme when I install 
linux nowadays. And I need to have things this way, as I have noticed.

There fore anyway, I will probably never have to fear the trauma that 
you are having right now. I have been close to it, in the beginning 
before I built my resque scheeme but even then I always had an Installation 
cd to use as a last resort.

This funny situation that you seem to be in is some what due to Debians
(lack of ?) philosophy. Every body seems to recommend every body else Not
to buy CD:s but instead download the needed software from the web. at the 
delight of Many of debian unsupportive ISP:s   Why?



sorry-bout-that-tim


I am only collecting mail from debian-user once a day, so I will not be 
able to help in any  step by step issue. You will need someone that runs
almost exactly the same kind of system that you had your self, since you 
would want to compare shared library sizes, etc.  I don't have.

I can point out a few interesting things: 

If you have run e2fck, and it has made severe repairs to your file system,
you will probably find a whole bunch of numbers in the directory

/lost+found

Theese numbers represent (I believe) Inode numbers.
Every one of theese numbers is a file that once had a name and lived happily
in your file system. If you are in the least lucky, then most of theese 
files are actually intact with size, owner rights ??? and all. Your main 
problem will be to pair each one of these files with a file name and a 
directory. This is not hopeless, but it will take time (lots), and effort. 
Some of theese files might actually be directories. (I don't know the likely-
ness of this, but if I'm not right then some one will complain to this. ) 
Any way If you happen to find a directory file Then you have hit a small 
jackpot. 

A directory file: Basically Combines three things : Inode-number- the lengh 
of a directory record, the lengt of a filename, and the filename it self 
This is repeated for every single Inode - filename pair entry in it.
(This I know for sure) The first name record in a directory file is always 
the directory files own inode, the name record is a simple ascii "." . The 
next record is the inode of the parent directory the name record is in
ascii ".." theese two records are created when you mkdir. The following 
records are the inodenumbers of files that you copy into the directory, 
paired with filename lenghts and the filenames them selves (they are also 
written in ascii)
So if you do  cat one of these files you will see a lot of filenames.

You will only be able to see the Inode numbers, and lenghts that is in between
the file names in a hexeditor or similar. To determine what is an inode 
number and what is a record lenght you will have to know that an Inode
takes up 32 bits of space (4 bytes) a name will only take up 8bits of 
space (1 byte) while the directory record lenght is I believe: 16 bits
(2 bytes) 
There are some tools for file system and file (directory)  snooping and 
editing in linux that I know of. One of theese tools is usually shipped 
together with e2fck, 

It's called debugfs. I don't really  like it my self but I believe 
that you can use it ( with some care though. Read manuals.
Theese tools are made for unmounted file systems, which you open read only
unless you really know what you are doing.
 
Another program is ext2ed. A problem with ext2ed is that it only works on 
smaller partitions, (2GB) same here read manual carefully. ext2ed
has a very nice overview of the ext2fs storage structures.


Other files of interest:

A binary compiled file always begins with sequence ".ELF" .This makes it 
possible to actually "grep" sort out all your lost libraries and 
binaries. A few other useful tools: 

useful commands
You have probably come across ldd all ready


the file command by which you can also determine filetypes.

the stat command will perhaps give you other file characteristics 
such as file creation date file modification date, file size, 
file type, etc.

nm tells you what variables a binary file such as a shared library contains.
This will give you a good fingerprint id on a binary.

file type, etc


/got to go now Good luck What ever you choose to do.

/Daniel Mose


-- 
To UNSUBSCRIBE, email to debian-user-request@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org



Reply to: