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

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



Les Mikesell wrote:

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.



Does line 5 look okay?



First make sure that you have /boot. It is usually on its own
partition but could be just a directory under /.



Yup, /boot is just a dir in / (not a seperate partition)


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.



Yes, I know, / is on the first scsi drive /dev/sda1


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.



Yeah I noticed this label business. Here is fstab from the server


==========================================
LABEL=/ / ext3 defaults 1 1
none /dev/pts devpts gid=5,mode=620 0 0
LABEL=/home /home ext3 defaults 1 2
none /proc proc defaults 0 0
none /dev/shm tmpfs defaults 0 0
/dev/sda2 swap swap defaults 0 0
/dev/cdrom /mnt/cdrom udf,iso9660 noauto,owner,kudzu,r
o 0 0
/dev/fd0 /mnt/floppy auto noauto,owner,kudzu 0 0
==========================================


I thought it should have looked like

========================================
/dev/sda1 / ext3 defaults 1 1
none /dev/pts devpts gid=5,mode=620 0 0
/dev/sdb1 /home ext3 defaults 1 2
none /proc proc defaults 0 0
none /dev/shm tmpfs defaults 0 0
/dev/sda2 swap swap defaults 0 0
/dev/cdrom /mnt/cdrom udf,iso9660 noauto,owner,kudzu,r
o 0 0
/dev/fd0 /mnt/floppy auto noauto,owner,kudzu 0 0
========================================


Would I still need to edit fstab and grub.conf if I chroot to the newly mounted and untared drive and do a grub-install from there?


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.



Good advice Les thanks. But the reason I chose gnoppix (Ubuntu) is that it has a relatively up to date adaptec aic79xx driver since it uses kernel 2.6.7. If I use the RH9 install disc in rescue mode it has an old/buggy scsi driver for the aic79xx. That's why I was scared to tar/copy the entire fs with it. Needless to say I have the latest scsi driver running on the server now but this was installed with an rpm update. Reading your post carefully I can imagine myself using gnoppix to fdisk and untar/copy to the new drive (with the advantage of the new scsi driver) . Then as you suggest reboot again with the RH9 cd to rescue and then finally just chroot and grub-install. Hopefully, I should not have to mess with labels. Is this all correct?



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.



Wow you really have experience Les! But if we had a catastrophy like a burglary then I would repurchase the same components. I am mainly afraid of the scsi drive dying. I would just go and buy the exact same drive and restore. Feels good to have a backup.


--


Robert Arkiletian C++ GUI tutorial http://fltk.org/links.php?V219


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