[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [K12OSN] restore backup with chroot + grub-install



On Sat, 2004-12-11 at 00:14, Robert Arkiletian wrote:

> After some reading I'm going to take a guess. After I
> 1) fdisk the brand new drive to the same parameters as before and
> 2) then mke2fs -j the filesystem.
> 3) Then mount it (/dev/sda1) from gnoppix as /mnt/sda1
> 4) then untar my backup from mobile drive to the new drive
> 5) then  chroot /mnt/sda1 /sbin/grub-install /dev/sda
> 6) then umount /dev/sda
> 
> Line number 5 is the one I want confirmation on.

First make sure that you have /boot.  It is usually on its own
partition but could be just a directory under /.  When you rebuild
by hand it should be on the first partition on the drive to avoid
any size limits in the bios boot code.

The original install will have put labels on the partitions.  You'll
either have to create matching ones with e2label or edit /etc/fstab
and grub.conf to refer to the partition device names.  Note that
/etc/grub.conf is a symlink to /boot/grub/grub.conf so you have to
edit the real location or wait until you have your new partitions
mounted in their relative positions and chroot'ed to its root.

You'll probably have trouble doing the chroot after booting a
very different distribution CD.   I'd recommend rebooting with
the distribution's install CD with 'linux rescue' at the boot prompt
after you have done the tar copy.  If /etc/fstab on the restored copy
matches your partition layout (using either names or labels), the
boot in rescue mode will automatically mount the partitions for you
and suggest the right chroot command to continue.  You can probably
do the re-install from a RH/fedora boot in rescue mode but a knoppix
based CD is nicer and the reboot step gives you a nice sanity check.
If it doesn't automatically mount the system under /mnt/sysinstall you
know the problem is the mismatch between /etc/fstab and the partition
names or labels and you should fix that before continuing.

The only other trouble you might have would be if the target machine
has a different scsi controller than the source.  In that case you
have to edit /etc/modules.conf (or conf.modules on older systems) in
the CD boot/chroot step to change the scsi driver module and then
rebuild the initial ramdisk with /sbin/mkinitrd.

---
  Les Mikesell
    les futuresource com



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]