Is there a helpful DIY on backing up your full system to protect against a HD crash? The part I don’t understand is how to restore to a bare metal drive with a different serial number, since a stock openSUSE install will not boot after such a restore.
I was thinking you would have to boot a live distro of some sort (knoppix?) and edit menu.lst and fstab to reflect the device ID of the new hard drive. It seems like there should be a python or perl utility already written for openSUSE to do this sort of thing to all the system files affected by the changed device ID.
Best would be to setup the system to access partitions by-uuid. That way, they should still be correct after a complete bare-metal restore. The most you should have to do is reinstall grub.
When you next install, there’s an option in the partitioning section where you can tell it what naming scheme to use.
I don’t know if there’s a tool. Perhaps the Yast partitioner has an option. I don’t think I would want to try it myself, even if there is an option. It is probably safest to go through manually to change them. The command “blkid” will tell you what the uuids are, or you can look at what’s in “/dev/disk/by-uuid”.
Thanks, nrickert! Thanks also for the blkid command. I will give it a try fixing fstab and menu.lst. Hopefully that is all that needs to be fixed. I don’t have any encrypted partitions on this particular install - or else the crypto file (whatever it’s called now) would also have to be changed. I don’t know what else. I have one of those eSATA bare-metal plugins so I can just clonezilla to that, then boot the main hard drive and edit the files I need before I try booting from the hard drive.
I guess my fstab and menu.lst are not UUID but “by-id” - so I opened the YaST partitioner and checked out the id’s and replaced them in menu.lst and fstab (on the cloned drive) but during boot it only says “loading operating system” and goes no further. I used clonezilla and copied the bootloader. Hmmm…
# Modified by YaST2. Last modification on Sat Jul 7 15:33:41 PDT 2012
# THIS FILE WILL BE PARTIALLY OVERWRITTEN by perl-Bootloader
# For the new kernel it try to figure out old parameters. In case we are not able to recognize it (e.g. change of flavor or strange install order ) it it use as fallback installation parameters from /etc/sysconfig/bootloader
default 0
timeout 8
gfxmenu (hd0,5)/boot/message
##YaST - activate
###Don't change this comment - YaST2 identifier: Original name: linux###
title Desktop -- openSUSE 12.1 - 3.1.10-1.16
root (hd0,5)
kernel /boot/vmlinuz-3.1.10-1.16-desktop root=/dev/disk/by-id/ata-ST1000DL002-9TT153_W1V072QJ-part6 resume=/dev/disk/by-id/ata-ST1000DL002-9TT153_W1V072QJ-part5 splash=silent quiet showopts vga=0x314
initrd /boot/initrd-3.1.10-1.16-desktop
###Don't change this comment - YaST2 identifier: Original name: failsafe###
title Failsafe -- openSUSE 12.1 - 3.1.10-1.16
root (hd0,5)
kernel /boot/vmlinuz-3.1.10-1.16-desktop root=/dev/disk/by-id/ata-ST1000DL002-9TT153_W1V072QJ-part6 showopts apm=off noresume edd=off powersaved=off nohz=off highres=off processor.max_cstate=1 nomodeset x11failsafe vga=0x314
initrd /boot/initrd-3.1.10-1.16-desktop
###Don't change this comment - YaST2 identifier: Original name: windows 1###
title WindowsXP x64
rootnoverify (hd0,0)
chainloader +1
I should have added that the grub boot line for mint also has “root=UUID=string-of-hex-stuff”. I don’t have resume= configured, so I could not check that.
I got the disk ID’s from the YaST partitioner. I looked at the listing for the source drive and compared it to the listing from the destination drive. I’m thinking there is some file somewhere I am overlooking. I never even get a grub line on the screen - just the bios, then nothing.
Nope, I’ll give that a shot. Do you know if there’s a general DIY online for this? Even if you bare metal restore after a disk crash using bacula or any other software this would be an issue with Linux. I know it’s not an issue for Windows XP or later.
EDIT: Yep - device.map has the old descriptor in it! That may be the problem!
EDIT2: Huh. I just looked into the new HD in the /dev directory and it doesn’t have …/disk (etc.) directories in it. I guess those get created at boot time.
If your clone is sector by sector, that shouldn’t be needed. But if it amounts to a file system backup/restore, then there might be some data that grub relies on, that has been relocated.
Well, that’s what’s got me bugged - I did a device-to-device clone with the latest Clonezilla, so it is indeed a sector-by-sector copy. I guess I have to try reinstalling grub but I was certain this issue would have been fixed by now since everyone restoring after a drive crash would have to deal with it… I am not sure how to reinstall grub - there used to be an option on the install disk to do that, but I think that went away… but I will check out the install disk for it.
On 2012-08-26 02:36, PattiMichelle wrote:
>
> Well, that’s what’s got me bugged - I did a device-to-device clone with
> the latest Clonezilla, so it’s sector-by-sector copy.
No, it is not, unfortunately.
Clonezilla tries to be clever and only stores used sectors; those that grub uses are “unused”, so
what it does is try to recreate grub instead using the grub that is on the live clonezilla CD.
That’s the reason I don’t like clonezilla when doing backups of Linux. Interestingly it does a
better job with ntfs boot disks.
It would be preferable that clonezilla copied as is the first 63 sectors or so. Everything at the
start of the disk till the disk structures should be cloned bit to bit.
> I guess I have to
> try reinstalling grub but I was certain this issue would have been fixed
> by now since everyone restoring after a drive crash would have to deal
> with it… I am not sure how to reinstall grub - there used to be an
> option on the install disk to do that, but I think that went away…
Right.
But you have an /etc/grub.conf file that can guide you to reconstruct it.
Also, you might have to run a “mkinitrd” on the chrooted new system.
–
Cheers / Saludos,
Carlos E. R.
(from 11.4 x86_64 “Celadon” (Minas Tirith))
Clonezilla tries to be clever and only stores used sectors; those that grub uses are “unused”, so
what it does is try to recreate grub instead using the grub that is on the live clonezilla CD.
That’s the reason I don’t like clonezilla when doing backups of Linux. Interestingly it does a
better job with ntfs boot disks.
It would be preferable that clonezilla copied as is the first 63 sectors or so. Everything at the
start of the disk till the disk structures should be cloned bit to bit.
That is good to know. (Not that I’ve ever used Clonezilla). Thanks for sharing this info.
Well, Clonezilla asked me if I want to copy the bootloader. If you’re right, it’s worse than I thought. I guess mere mortals can no longer do this trick (clonezilla backups) any more. Or any backups for that matter - it’s really about the disk-id thingie. I tried for a couple of hours with google to figure out how to “reinstall GRUB.” I’m giving up and reinstalling OpenSuSE. So far (since 10.0 anyway) that has always worked. Fingers crossed!
So I guess it’s only useful to back up data now. Is there any disk mirror routine that gets around this device issue? What is the “traditional” install option so that everything is done in terms of sda, etc.? So I can do bare-metal backups easily in the future? There are 4 or 5 options now.
Thank you very much for the time you’ve taken to fill me on the status of this issue. Have a great weekend.
EDIT: Hey - I was just looking at that Clonezilla site - I wonder if I used the 32-bit Clonezilla? It looks like that breaks GRUB in OpenSuSE12.1 x64. (is anyone running 32 bit linux any more? even most laptops are standard >4GB nowadays)
On Fri, 31 Aug 2012 21:46:02 +0000, PattiMichelle wrote:
> I just remembered ping as a sector-by-sector copier - but I remembered
> it wouldn’t boot on all systems. Is there a true sector by sector
> copier?
dd or dd_rescue will do that.
As long as you mount partitions by device rather than by label or ID,
assuming the devices are identified in the proper order, that should take
care of this.
even most laptops are standard >4GB nowadays)