# kernel panic - not syncing: no init found [solved]

## dermund

Hi,

I recovered my system from an accicdental deletion (rm -rfd . is no good if there is a symbolic link to / is lying somewhere deep in this folder ;().

I still have my original boot partition with all my kernels. Everything but the dev-tree was in place in my backup of /.

So I created the neccessesary devices: console, null and so on.

If I start my system I get:

```

kjournald starting. Commit interval 5 seconds.

EXT3-fs: mounted filesystem with ordered data mode.

VFS: mounted root (ext3 filesystem) readonly

warning: unable to open initial console

kernel panic - not syncing: no init found. Try passing init= option to kernel.
```

I can fully space out my grub.conf is bad. I checked if there is a /sbin/init : k. Checked if there is /bin/bash : k. /bin/sh : k.

My /etc/fstab is pretty straightforward. Just my three partitions: boot, swap and root.

So what the fork is goin on? Is still a device missing?

Well, that could be interesting: If I give grub a init=/bin/bash string, before the kernel panic my system cries: "Failed to execute /bin/bash. Attempting defaults..."

But /bin/bash is there and executable!?!

This can't be something big - but I'm clueless right now. Can someone help? Maybe a good site on the net where the startup process is described in detail.Last edited by dermund on Sun Nov 02, 2008 8:26 pm; edited 1 time in total

----------

## poly_poly-man

post grub.conf.

are you mounting / corrrectly?

----------

## dermund

So this is a 1:1 copy - I am booting the 3rd entry by default. But it can't be the grub.conf as I didn't changed anything on it. The boot-partition wasn't touched.

What do you mean by mounting correctly? Where and what?

```
# Config file for GRUB - The GNU GRand Unified Bootloader

# /boot/grub/menu.lst

# DEVICE NAME CONVERSIONS 

#

#  Linux           Grub

# -------------------------

#  /dev/fd0        (fd0)

#  /dev/hda        (hd0)

#  /dev/hdb2       (hd1,1)

#  /dev/hda3       (hd0,2)

#

#  FRAMEBUFFER RESOLUTION SETTINGS

#     +-------------------------------------------------+

#          | 640x480    800x600    1024x768   1280x1024

#      ----+--------------------------------------------

#      256 | 0x301=769  0x303=771  0x305=773   0x307=775

#      32K | 0x310=784  0x313=787  0x316=790   0x319=793

#      64K | 0x311=785  0x314=788  0x317=791   0x31A=794

#      16M | 0x312=786  0x315=789  0x318=792   0x31B=795

#     +-------------------------------------------------+

# general configuration:

timeout   5

default   3

color light-blue/black light-cyan/blue

# boot sections follow

# each is implicitly numbered from 0 in the order of appearance below

#

# TIP: If you want a 1024x768 framebuffer, add "vga=773" to your kernel line.

#

#-*

# (0) Arch Linux

title  Arch Linux

root   (hd0,0)

kernel /vmlinuz26 root=/dev/sda3 ro

initrd /kernel26.img

# (1) Arch Linux

title  Arch Linux Fallback

root   (hd0,0)

kernel /vmlinuz26 root=/dev/sda3 ro

initrd /kernel26-fallback.img

# (2) Arch Linux

title  Arch Linux 2.6.24

root   (hd0,0)

kernel /bzImage2.6.24 root=/dev/hda3 ro

#initrd /kernel26.img

# (3) Arch Linux

title  Arch Linux 2.6.24.4

root   (hd0,0)

kernel /bzImage2.6.24.4 root=/dev/hda3 ro

#initrd /kernel26.img

# (4) Arch Linux

title  Arch Linux 2.6.24.4 sda

root   (hd0,0)

kernel /bzImage2.6.24.4 root=/dev/sda3 ro

#initrd /kernel26.img

# (5) Arch Linux

title  Arch Linux 2.6.24.4 sda 2

root   (hd1,0)

kernel /bzImage2.6.24.4 root=/dev/sda3 ro

#initrd /kernel26.img

# (1) Windows

#title Windows

#rootnoverify (hd0,0)

#makeactive

#chainloader +1
```

----------

## poly_poly-man

First of all, I'm going to assume that you just misspelled gentoo as "a-r-c-h"  :Wink: 

What are the permissions on /sbin/init? /bin/bash? the directories /bin and /sbin?

----------

## dermund

 *Quote:*   

> First of all, I'm going to assume that you just misspelled gentoo as "a-r-c-h"

 

Damnation...you got me  :Cool:   But I love Gentoo and hate Arch   :Wink: 

File permissions were somethin like 522 or so and I changed my whole root for testing purposes to 777 recursively  :Smile:  But same error  :Sad: 

----------

## dermund

No idea? I'm still clueless...

In fact I have the same problem on my gentoo system after a backup.

Help kindly accepted  :Wink: 

----------

## poly_poly-man

 *dermund wrote:*   

> No idea? I'm still clueless...
> 
> In fact I have the same problem on my gentoo system after a backup.
> 
> Help kindly accepted 

 look up the exact permissions of another system, and match them on your own.

Sometimes, either too liberal or too conservative a permission set will not work.

----------

## cyrillic

 *dermund wrote:*   

> In fact I have the same problem on my gentoo system after a backup. 

 

Did you perform the backup in a way that preserves permission information ?

tar -p

cp -a

rsync -a

dd

... 

----------

## dermund

 *Quote:*   

> Did you perform the backup in a way that preserves permission information ?

 

No   :Twisted Evil: 

For the arch system I copied everything to a fat32 usb disk. Worst case. So I don't really know - but I guess permissions are set to default somehow if I copy it back to ext3 partition. BUT I guess the permissions of just a few files are of interest at startup (when INIT is loaded) 

For the gentoo system where I accidently did a rm -rfd to symlink to /  -> I rescued all my data through the "ext3grep"-tool which should preserve the permissions. I looked over different parts of my root partition and it seems like that.

Can you perhaps explain me the behaviour I posted at the top. That could be the key to the problem!?!

 *Quote:*   

> Well, that could be interesting: If I give grub a init=/bin/bash string, before the kernel panic my system cries: "Failed to execute /bin/bash. Attempting defaults..."
> 
> But /bin/bash is there and executable!?!

 

----------

## poly_poly-man

sure it's executable, but that doesn't *really* mean anything if the directories or some files themselves are incorrect... either too high (777 will not work for many files/directories) or too low (are all your directories executable by all)

----------

## dermund

So based on one file I have a total of 4096 possibilties to set my permissions. I am unsure if I have enough time on my weekend to do this for several files.

Nah.. I guess I have a linux on a virtual machine somewhere lying around to take my permissions from.

For academic cause - if you want to - can you explain me WHY 777 doesn't work for this stuff.

----------

## poly_poly-man

 *dermund wrote:*   

> So based on one file I have a total of 4096 possibilties to set my permissions. I am unsure if I have enough time on my weekend to do this for several files.
> 
> Nah.. I guess I have a linux on a virtual machine somewhere lying around to take my permissions from.
> 
> For academic cause - if you want to - can you explain me WHY 777 doesn't work for this stuff.

 

well, it technically should, but it is a safety feature that it doesn't.

For example, ssh is super-mad about this. If anything in /etc/ssh is 777, it complains. If your .ssh folder is viewable to others, it won't let you run. Same for vsftpd.... if the ftp server root is 777, it won't run.

Basically, somewhere something has a safety measure implemented.

----------

## dermund

I totally understand this since it concerns security based features - but that has nothing to do with the system startup.

So it's just a presumption from you that 777 prevents system startup, or can you give the exact reason?

----------

## kevstar31

You need to do this in a chroot from a livecd.

1. Backup /etc and /var/lib/portage/world

2. extract a stage3 tarball in the root directory

3. restore /etc and /var/lib/portage/world from your backup

4. emerge --sync

5. /usr/portage/scripts/bootstrap.sh

6. emerge -e world

----------

## poly_poly-man

 *dermund wrote:*   

> I totally understand this since it concerns security based features - but that has nothing to do with the system startup.
> 
> So it's just a presumption from you that 777 prevents system startup, or can you give the exact reason?

 I do believe that parts of either the kernel or the other programs you mentioned have this check...

I've hit this same problem before

----------

## dermund

okay found the problem. The system missed libraries which is needed by init. I manually copied all necessary libraries for init.

Now init works (altough I get thousands of "failed to open shared library"-errors at startup for /bin/ls and so on).

I really don't understand, why these libs weren't copied with the backup.

For my backup I just did a normal cp -v (nothing else) while the system ran normal.

----------

## dermund

Seems some of the symlinks have been lost through the backup: all the libraries were there but in form of xyz.so.5.2.x and not in symlink form xyz.so.

I did a ldconfig -r /mnt/pathtomountedroot. Now nearly everything works. Some of the binary symlinks are still missing though.

But this is a minor problem, so I close this.

Thanks all!

----------

