0

We have ldap server configuration in centos 5.8. Server is working fine yesterday as we today restarted the server its not able to boot. Gives following error :

/bin/bash: ro : no such file or directory kernel panic- not synching:attempt to kill init

We tried to recover using rescue mode still no luck.

chroot /mnt/sysimage

/bin/sh file is available in directory still it gives same error.

This is a capture of the console showing the issue.

enter image description here

This is the content of /boot/grub/menu.lst file:

default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title CentOS (2.6.18-308.el5)
        root (hd0,0)
        kernel /vmlinuz-2.6.18-308.el5 ro root=/dev/VolGroup00/LogVol00 rhgb quiet
        initrd /initrd-2.6.18-308.el5.img
Anderson Medeiros Gomes
  • 2,477
  • 9
  • 20
Rakesh
  • 1
  • 1
  • 3
  • It sounds like a problem either on kernel's command line or in the initial ramdisk. I suggest you to check the integrity of ramdisk files in `/boot/initrd-*.img`. Also, please could you capture an image showing console's output and the content of `/boot/grub/menu.lst`? While capturing the image, please ensure that `quiet` and `rhgb` command line arguments are absent. – Anderson Medeiros Gomes Feb 08 '20 at 18:27
  • @AndersonMedeirosGomes Image URL: https://imgur.com/fXr1dS1 – Rakesh Feb 10 '20 at 11:58
  • The problem is not that `/bin/sh` does not exist, the problem is that `/bin/sh` tries to execute a binary named `ro` which doesn't exist. There is an error in your grub cmd line. Show your `grub.cfg` or `menu.lst` which you can find in `/boot/`. – Gerald Schneider Feb 10 '20 at 12:08
  • @GeraldSchneider grub.cfg and menu.lst is same. " default=0 timeout=5 splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu title CentOS (2.6.18-308.el5) root (hd0,0) kernel /vmlinuz-2.6.18-308.el5 ro root=/dev/VolGroup00/LogVol00 rhgb quiet initrd /initrd-2.6.18-308.el5.img " File url : https://easyupload.io/89w063 – Rakesh Feb 10 '20 at 14:03
  • @Rakesh Thank you. I see that the error message appears after the root partition is mounted and, possibly, after `/sbin/init` is executed. Therefore, the cause of the problem is not in grub or in the initial ramdisk. It looks like a filesystem issue. – Anderson Medeiros Gomes Feb 10 '20 at 20:36

1 Answers1

1

I think that the root filesystem was corrupted by an unclean shutdown and important files such as /sbin/init, /bin/sh and /etc/rc.d/rc.sysinit were damaged somehow. I am not completely sure about it, though.

I suggest you to reinstall bash, SysVinit and initscripts packages using the image CD. Assuming that CDROM contents will be available through /dev/hdb device node in rescue mode, the reinstallation process can be performed by using the following steps:

# mkdir -p /mnt/cdrom
# mount /dev/hdb /mnt/cdrom
# rpm --root /mnt/sysimage -ivh --replacepkgs \
    /mnt/CentOS/{bash,SysVinit,initscripts}-*.rpm

Alternatively, by inspecting the file /sbin/init, /etc/inittab and files under the directory /etc/rc.d, you could figure out why /sbin/init is calling /bin/sh and, afterwards, calling a binary named ro. This does not look normal.

PS: /bin/sh should be a symbolic link pointing to /bin/bash and not a regular file.

EDIT: once there is a confirmation that /sbin/init executable does not exist in filesystem, I am sure that such absence is the cause of the problem. CentOS booting process is probably executing /bin/sh as fallback and passing ro root=/dev/VolGroup00/LogVol00 rhgb quiet as command line arguments, thus leading /bin/sh to look for a script file named ro. Because it does not exist, /bin/sh throws the error message ro: no such file or directory and aborts.

I believe that reinstallation of the SysVinit package (which provides the /sbin/init executable) will fix the booting issue.

Anderson Medeiros Gomes
  • 2,477
  • 9
  • 20