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?

Thanks,
Wagscat

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?

Thanks
 

I tried it. Sorry, it didn't work.

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?

What else then?
 

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.


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.


Unlikely. If there's error messages do post them.

Thank You
 

I wasn't able to have the system down too long. I reformatted my openSUSE on Sunday and reset it up, now even better. I will save this post around in case I or anyone else runs into the same error.