during booting kernel panic

[rajesh73]

we uninstall the glibc rpm file in rhel6.3 server , once server reboot .server got panic .we received below mentioned error

Error message

Kernel panic not syncing

PID-1

call trace

Please advice

[Matti_Kurkela]

Uninstalling the glibc RPM is almost always a big mistake.

The glibc library is required by practically every command and other binary on the system, including /sbin/init.

Use a RHEL 6.x (preferably 6.3) installation media to boot the system to rescue mode (i.e. add a "rescue" boot parameter to the boot prompt). The installer will ask you the language and keyboard layout, and then mount the existing RHEL system to /mnt/sysimage and will give you a root prompt.

Find the glibc RPM on the installation media, then use a command like "rpm --root /mnt/sysimage -ivh <glibc RPM file>" to reinstall the glibc RPM to the system.

If other RPMs were also removed because of dependencies, you may have to install other RPMs in this way too. In that situation, install the RPMs required by your normal backup program, then restore your latest backup.

(You do have a backup, right?)

If you used something like "rpm -e --nodeps glibc" to remove only the glibc RPM,  reinstalling it should be enough to make the system work normally again.

[rajesh73]

as of now we did't take any backup. please advise me which type of backup method we follow

[rajesh73]

please advise me which type of backup method we follow
in future

[Matti_Kurkela]

You might still be able to fix this, by re-installing a minimal configuration of the RHEL 6.3 operating system on top of the existing installation.

If you do this, you must not let the installer partition the system automatically: instead, you should carefully choose the existing partitions and/or LVM logical volumes, and choose to mount them without re-creating the filesystem. In this way, the installer should replace the existing OS files with basically identical files, and re-install the OS files you may have accidentally removed. Most likely you will need to re-configure the network settings.

As a result, you should get your system at least functional enough that you can copy your data files and any important application configuration files to an external disk or a network share.

Applications may or may not work in this state, because some libraries that are not included in the minimal installation may still be missing. But once you have copied your data to a safe location, you can then re-install the system properly like you normally do.

It is very difficult to choose a backup method without knowing anything at all about your site.

Things like:

• do you have just this one server, or many systems that should be backed up? How many?
• How often do you want them backed up? (In other words, how many days' work you can afford to lose if a restore is needed?)
• Do you have centralized backup facilities available at your site (backup servers, tape libraries/robots)? If you have them, it might be easiest to use them for Linux too, if possible.
• Do you have databases or other things that may need special steps for backups?
• Do you want a solution only for Linux, or do you need to backup Windows, Mac or other Unix systems too?
• What is your budget? (Does it need to be free software?)

But in general, the easiest way to recover from a situation like this is with any backup solution that can do Bare Metal Recovery, i.e. booting from an external boot media or over the network and then restoring *everything*, including the basic Operating System files. One nice free tool for this is MondoRescue (see http://mondorescue.org ).

If your backup solution does not include an automatic Bare Metal Recovery feature, it is still possible to recover from a situation like this. It's just a bit more complicated: you will have to first perform a minimal installation of the OS, then install your backup tool and any pre-requisites it may have, and then restore your latest full backup, overwriting everything.

A solution that is optimal for Bare Metal Recovery may not be optimal for regular data backups. So you might want to set up two backup cycles, maybe using different backup software. First, a data backup cycle whose main purpose is to protect your data&colon; this can use differential/incremental backups, special steps for database backups, etc. It should run regularly: at least once a week, maybe every night. The second cycle would be for producing a backup that is suitable for Bare Metal Recovery. It will only need to cover the Operating System files and the backup tool you use for the first cycle. You may be able to run this much less often: maybe once a month, or just run it manually after any system update or major reconfiguration.