RESOVLED: Fedora 6 restore snafu

Thanks to all for their advice. Here's how I got past it:

After mounting the initrd and examining the /sbin/init script, I was
able to determine that I had no confidence that my root filesystem was
ever mounting. Since fsck had failed on both the newly formatted server
volume AND the USB drive to which I'd restored the backup, I decided to
start over.
1. Wiped the server and installed the lated Fedora 6, default install
with no packages checked. During the install I prevented it from
creating any LVM volumes, using a single ext3 partition for the root
volume. After it booted I ran yum update.
2. Installed Retrospect Linux client and restored the backup to a new
directory, /server-restore, not touching the clean system.
3. Booted off of the CD into rescue mode.
4. Moved all directories except /server-restore, /boot, and /lost+found
into a new directory, /server-new.
5. Moved everything in /server-restore except /server-restore/boot into /.
6. Tweaked grub.conf and fstab, touched /.autorelabel, crossed my
fingers and rebooted.
7. It almost worked, but it didn't have the right kernel modules--the
backup's kernel was staler than the clean install's, so I booted off the
CD again, and copied the kernel module directory from
server-new/lib/modules/ into /lib/modules/
8. After that, it came back up, give or take some tweaking to get
networking running. (Why do eth1 and eth0 always want to swap in these
situations?)

Bleah. It's running again. My feeling of accomplishment is tainted by
all the easier things I tried that _should_ have worked. The correct
procedure took only about 4 hours, but I spent a lot more time trying to
get it to boot from the corrupt file system. I know the external USB
drive proved to be flaky but now I mistrust LVM...

PM

Jonathan Loran wrote:
>
> From afar, I'm not sure where else to look. Perhaps a query to one of
> the Linux kernel lists would help, perhaps the LVM list. Maybe, you
> can try without LVM just to remove it from the equation. Good luck.
>
> Jon
>
> Paul Mackinney wrote:
>> It's an LVM volume built on top of hardware RAID, and yes, I've gone
>> over the combination of fstab, grub.conf and the volume labels that
>> make restoring Linux systems such a pleasure. I'm really pretty sure
>> that they're all OK, but I need to inspect the initrd file.
>>
>> Anyway, thanks for your thoughts. I can certainly reformat the hard
>> drive. It's pretty darn simple:
>> - primary 100 MB partition (/boot)
>> - primary 60 GB partition (LVM)
>> - VolGroup00/LogVol00 59.8 GB (/)
>> - VolGroup00/LogVol01 2 MB (swap)
>>
>> The real gotcha here is that although I can boot from the rescue disk
>> and mount the file system, I can't do any of the following successfully:
>> - run 'chroot /mnt/sysimage'
>> - run mkinitrd
>> - mount the initrd to a loop device for inspection (now that I think
>> of it, this failure may also point to a corrupt FS)
>>
>> What I can do while booted from the CD is run grub and edit files
>>
>> Both my particular boot error, and the chroot failure have been
>> reported on a couple of sites, but no one claims to have solved them.
>>
>> Thanks, PM
>>
>> Jonathan Loran wrote:
>>
>>> I'm going to take a shot in the dark here. Given that your fsck
>>> found errors, you're having trouble finding /bin/sh (other files?)
>>> and that you most likely have the correct info in grub.conf (though
>>> you should quadruple check that), I'll bet your disk label is
>>> corrupted, and you have overlapping partitions. How big is your
>>> boot disk? If it's upon a RAID volume larger than 1TB you may need
>>> to partition with parted. You may want to give parted a try
>>> anyway. It's more feature rich than fdisk, and can adjust errors,
>>> though you should really recopy your data if you find any.
>>>
>>> My 2c
>>>
>>> Jon
>>>
>>> Paul Mackinney wrote:
>>>
>>>> I'm hoping a seasoned Fedora Linux sysadmin has seen this before
>>>> and knows the path. I've Googled extensively & found several
>>>> reports of the same problem, but no solution. I have backed up &
>>>> restored many Fedora systems. I've had to deal with LVM UUID
>>>> differences, reinstalling grub, etc, but this one is kicking my butt.
>>>>
>>>> My situation: I have a backup of a Fedora 6 system that I'm trying
>>>> to restore to the same system it came from. It attempts to boot,
>>>> but stalls with the message "can't find init (/sbin/init)".
>>>> When I edit the grub line and add the boot command "init =
>>>> /bin/sh", I get a very similar error complaining that it cant find
>>>> init (/bin/sh).
>>>>
>>>> This is all very similar to this post, which remains unsolved:
>>>> http://www.linuxquestions.org/questions/fedora-35/cant-clone-fc6-using-tar-backup-and-restore-506424/
>>>>
>>>>
>>>> What I've done:
>>>> 1. Verify the listings in grub.conf and fstab are all correct.
>>>> 2. Resinstall grub.
>>>> 3. Disable selinux. Did that via /etc/selinux/config. I also
>>>> touched an .autorelabel file in the root of the hard drive.
>>>> 4. Run fsck. It found & fixed some errors, no change in behavior.
>>>>
>>>> What I can't do:
>>>> 5. Rebuild the initrd. Can't, because when I run in linux rescue
>>>> mode, the "chroot /mnt/sysimage" command fails with the message
>>>> "can't find /bin/sh". Without chrooting, I can't get mkinitrd to
>>>> work, and I can't even get the initrd mounted on a loop device to
>>>> inspect it. (I'm doing this on another computer now.) I note that
>>>> this problem is superficially similar to the problem booting in the
>>>> first place...
>>>>
>>>> TIA. Paul
>>>>
>>>>
>>
>>
>>
>

 
-------------------------------------------------------------------------
The following was automatically added to this message by the list server:

To learn more about Micronet, including how to subscribe to or unsubscribe from its mailing list and how to find out about upcoming meetings, please visit the Micronet Web site:

http://micronet.berkeley.edu

Messages you send to this mailing list are public and world-viewable, and the list's archives can be browsed and searched on the Internet. This means these messages can be viewed by (among others) your bosses, prospective employers, and people who have known you in the past.
Received on Wed Dec 24 2008 - 02:47:32 PST