Hi,
There's a RHEL5 system somewhere across the internet with a trashed root file system. I have VPN access to the subnet where it lives. But the system is not talking to the network.
The current plan is having an onsite person boot from a CentOS Live CD, copy a small script to configure networking, set a password for the centos user, start sshd, and tweak the default firewall to allow incoming ssh connections, once I have remote access to the live cd environment I'll create a new lvm logical volume, create a file system, and restore from a level 0 dump taken from a lvm snapshot just before things broke. I'm pretty confident I have all of the above under control.
The part I'm not certain about is the grub voodoo to get the system to boot to the lvm with the restored root file system.
I'm not certain of the vintage of the restored root file system it was built from an old RHEL5 installation cd and last updated a year or so ago. I have a CentOS 5.5 live cd .iso image staged for the onsite person to burn. Are there differences in the boot process for CentOS/RHEL 5.x versions that I have to worry about. Would it be better to try to get a closer match between the root file system and the live cd vintages.
At the moment I'm googling for info on the grub incantations for changing the root file system logical volume.
Any comments suggestions would be appreciated.
Thanks,
I'll create a new lvm logical volume, create a file system, and restore from a level 0 dump taken from a lvm snapshot just before things broke.
Ok.
The part I'm not certain about is the grub voodoo to get the system to boot to the lvm with the restored root file system.
Look at ./etc/lvm/backup/* in your dumped files, it will show you the VG, LV and ID. Create your new VG and LV, then edit fstab to reflect or recreate it w/ the same names. Just make sure fstab reflects whats actually in place.
Are there differences in the boot process for CentOS/RHEL 5.x versions that I have to worry about. Would it be better to try to get a closer match between the root file system and the live cd vintages.
No, you're simply booting to env that allows you to create a new FS, this might matter if the recovery env created an FS that was some revision ahead of what your dumped OS uses, but given the info you provided, I think you are fine, give'er and let us know...
jlc
On Thu, Jun 24, 2010 at 7:53 PM, Joseph L. Casale <jcasale@activenetwerx.com
wrote:
The part I'm not certain about is the grub voodoo to get the system to
boot to
the lvm with the restored root file system.
Look at ./etc/lvm/backup/* in your dumped files, it will show you the VG, LV and ID. Create your new VG and LV, then edit fstab to reflect or recreate it w/ the same names. Just make sure fstab reflects whats actually in place.
The seems to be something here that I don't get!
I have booted from a cd and am running CentOS, I'm assuming my active root file system is some sort of read/write ram disk overlaid on top of the read only file system from the cd. At the moment the right terminology to express this escapes me.
I have the original system disk that is corrupted. It needs at least two partitions since the boot loader does not yet understand lvm. There is a tiny ext2/3 file system that contains /boot which contains the boot loader/grub stuff. I assuming we are talking about "legacy grub" not grub2. And there is a second partition containing an lvm PV and within that is a LV containing the root file system.
I do have a level 0 dump of /boot in addition to the level 0 dump of /
I can restore the contents of /boot and / but things will proabably not end up in the same physical sectors. Running grub the right way should update parameter for the boot loader to first tranfer control to the right place in /boot which then accesses the right filesytem in the right PV/LV
You seem to be saying that all I need to to do is tweak /etc/fstab in the root file system in the new pvn/lvm.
Actually as I try to explain my current understanding things are getting clearer.
It seems to me that at least one more step is required. getting a proper chroot jail environment set up so I can run a grub command to update the boot sectors on the RHEL5 system disk to transfer control to the right place in /boot and update /boot so that it can mount the right filesystem on /
I'm still hoping to find complete documentation with an example of how to do this.
drew einhorn wrote:
On Thu, Jun 24, 2010 at 7:53 PM, Joseph L. Casale <jcasale@activenetwerx.com
wrote:
The part I'm not certain about is the grub voodoo to get the system to boot to the lvm with the restored root file system.
<snip>
The seems to be something here that I don't get!
<snip>
I do have a level 0 dump of /boot in addition to the level 0 dump of /
I can restore the contents of /boot and / but things will proabably not end up in the same physical sectors. Running grub the right way should update parameter for the boot loader to first tranfer control to the right place in /boot which then accesses the right filesytem in the right PV/LV
You seem to be saying that all I need to to do is tweak /etc/fstab in the root file system in the new pvn/lvm.
Actually as I try to explain my current understanding things are getting clearer.
It seems to me that at least one more step is required. getting a proper
<snip>
I think I know what you need to do: once you've got the /boot restored, and the LVM mounted (the liveCD ought to let you do that), then you need to chroot to the mounted fixed drives, and grub-install /dev/sda (or whatever it is). Then you may want to edit /boot/grub/device.map to only show (hd0,0). And DON'T FORGET to create /boot/grub/grub.conf!
That should do it.
mark "just did it last week"
-
drew einhorn -
Joseph L. Casale -
m.roth＠5-cent.us