BASH file corrupt, and sh and init went down with it (DESPERATE)
Suse/NovellThis Forum is for the discussion of Suse Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
BASH file corrupt, and sh and init went down with it (DESPERATE)
If this is the only sentence you read, just learn the easy way: bash is a critical boot file in SUSE.
Yesterday afternoon, I was playing around with updating my system with RPMs from the openSUSE RPM Search. I had bash v 4.0.18 (I'm running a decaboot, the primary OS being openSUSE 11.2, where the issue is) and I installed a package that was bash 1.0.36. I restarted my Yakuake terminal to see the new bash. Immediately, I noticed the Yakuake terminal flashing rapidly, and the terminal wouldn't go down when I used the key that brings up and down, so I controlled-alt-escaped it and killed it off. Then I wondered if it was just me, so I hit ALT-F2 and logged in as root. It quickly said some symbol file (Something)_(Something)_REWRITE(maybe) then disappeared, giving my the login prompt. I though, well, OK maybe I have to restart it to get it to work. Init said "there is no more processes left on this runlevel" and I had to Power-Button it and reboot. When it rebooted, or tried to, I was greeted with "KERNEL-PANIC Tried to kill init"
I panicked with the kernel, and I went into my 11.3 Milestone 4 installation, tried to chroot it, but I received the same error as when I tried to log into root and was returned to my 11.3 session.
I later tried to do a mock update with the 11.2 DVD, and tried with the YaST package manager to downgrade BASH, but the RPM installation failed, even on good DVDs. I tried the rescue, but it said BASH wasn't a "critical file" while things I don't even use were checked (like openssh)
From 11.3, I tried linking sh from bash to ksh (Korne Shell). For all I know, it is just like bash. It didn't work. Same kernel error.
I relinked sh and bash together, and I am using SUSE 11.1 in the meantime, but does anybody know how to fix this without reinstalling my SUSE 11.2 completely?
Last edited by wagscat123; 05-23-2010 at 11:31 AM.
Find out Bash' dependencies from your "known good" installation, then mount the 11.2 partition and 'copy -f' /bin/bash(2?) and its dependencies over the botched one, then if that makes 11.2 accessible again, download the previous Bash package and force-reinstall it over the newer one?
I was going to suggest the same thing, but unSpawn beat me to it.
But it seems strange to me that simply installing a newer bash version would cause such problems, as they generally work hard to keep things backwards-compatible. I do know that ksh isn't perfectly compatible with bash, although they have many functions in common. Still, most important system scripts are written to stick to posix-compliant sh mode, which all shells should be able to run, so the exact shell used shouldn't matter.
Combine this with the fact that replacing the executable didn't work, and I'd say that the problem isn't with bash itself. Something about the installation of the new packages probably deleted, moved or otherwise changed something else important.
I suggest taking a look at the details of the packages themselves and see how they differ in what and where they install all the files in them.
By the way, what's up with the version numbering? Bash is currently up to 4.*, why does your post say 1.*? Is this some internal SUSE numbering system or something?
Earlier that day, I installed GRUB 2. But I booted into the system several times over a period of 12 hours before I installed the GRUB package. Sorry about the BASH, I got mixed up, I should have typed 4.0.18 and 4.0.36. I tried installing other packages, but the dependencies failed. When I had the SUSE disks, it was also trying to install Emacs on the mock-update. But Emacs didn't install. I almost think maybe the RPM base is messed up. On the DVD Repair, it said other "critical" packages like openssh and openSUSE-release were messed up.
Please don't say that. Instead please tell us exactly what you did.
Originally Posted by wagscat123
I tried installing other packages, but the dependencies failed.
IMO you shouldn't be installing packages but verifying them ('rpm -Vv packagename0 packagename1'). Bash depends on libtermcap and glibc. If you can boot the 11.2 DVD in rescue mode or via the 11.3 session you should be able to verify packages, just have the "victim" partitions mounted someplace and use the "--root" and "--dbpath" args to adjust to where you mounted "/" and where your "var/lib/rpm" directory is mounted. Say you're inside your 11.3 session, your 11.2 root resides at /dev/sda2 and your 11.2 /var resides at /dev/sda6, run 'mkdir /mnt/rescue/sda2 /mnt/rescue/sda6; mount /dev/sda2 -t auto /mnt/rescue/sda2; mount /dev/sda6 -t auto /mnt/rescue/sda6; rpm --dbpath /mnt/rescue/sda6 --root /mnt/rescue/sda2 -Vv bash glibc libtermcap 2>&1>/tmp/rpmvv.log', then 'less /tmp/rpmvv.log'. If all looks OK check the (/mnt/rescue/sda6/)var/log/messages and other syslog files for clues.