I have a dual-boot system on two hard-drives… Win XP on primary HDD, Fedora 10 on slave HDD (which doesn't matter as I change the HDD boot device as needed in BIOS). So, previously, I had Grub installed, with Fedora, on the slave HDD, and the BIOS booting this HDD. When attempting to backup this HDD (and the Fedora system), using the default "Clonezilla advanced extra options", my Fedora /boot partition was lost and Grub was moved to the Win XP MBR (on the opposite/primary HDD). Since then, I have re-installed Fedora 10 on the same HDD, but this time installed Grub/bootloader in the MBR (primary HDD). I would like to backup each system partition again using Clonezilla, but would like to seek advice/help regarding what could have caused the previous problem so it won't happen again. I assume it had something to do with the Clonezilla Live CD "Clonezilla advanced extra options" default setting for restoring the MBR, but am unsure, as I am still a bit of a Linux newbie. Can anyone please help?
Thanks for your question and using Clonezilla! You may recall during the clone process there is a point where it mentions the exact command used, I believe that gets saved in with the image file if one is made. Perhaps, if you share that command, it may help diagnose what exactly happened.
Thanks!
Alan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
All other files either could not be opened by gedit, or simply contained basic hardware information on my computer (that I really would consider useless).
Thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Oops, sorry about sending you on a wild goose chase! I just took a look at my archives and realized the command line parameters given to Clonezilla are not saved with image, I'm not sure why I thought they were! (Maybe they should be? Like a log? Steven?)
Anyway, I thought it might help if we understood the specific commands issued. From what you describe, it sort of sounds like you went the 'device-device' route, but if you did that, then there wouldn't also be a folder with files (aka the 'image')? If the image was made at some other time, perhaps an attempt was made to restore the image to the wrong (primary) drive? I still find hda/hdb and Linux mount points a bit foreign so, I could see how this might happen. But, I'm not really sure how the Grub/MBR could could get moved to another drive without multiple steps or some defect.
On the other hand, it may be silly to try to recreate the exact previous situation, since your set up sounds pretty normal and *shouldn't* be a problem. So, here's what I can recommend. First, since there was some trouble before, it'd probably be a good idea to back up any critical data until the process and any defects are sorted out.
Get the latest version of Clonezilla (1.2.3-14), as it seems you are a bit out of date and there have been many fixes and improvements (Thanks everyone!). Then, try going through using the 'device-image' route and 'beginner' mode. I've been enjoying 'beginner' ever since it showed up and it's taken care of everything I need! Keep track of your choices as you go along and/or the command line parameters. That way, if there is trouble, we can diagnose things a little better.
If anyone has other suggestions, please chime in, thanks!
Alan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks guys, though I haven't tried to save an image again yet. I am still scared to try it at this time. So, after looking up information from various sources, it seems that the problem I had may be explained here:
The section "Why Grub may break"; subtitle "disk cloning: you may want to clone your partitions to another disk or another computer for some reasons. If you just clone the partitions of the disks, the sectors where Grub is installed may not be copied (eg: sectors before the first partition, or MBR). "
though, when this first happened Grub was still available, though it lost the boot partition, and therefore, Grub couldn't boot Fedora. Though, I still do not know how to apply this information to the use of Clonezilla. I could not find Clonezilla instructions for the advanced parameters. It would be nice if someone could explain/add this to the online instructions for the Clonezilla site, though I know this is all purely volunteer work and a lot of people may not have the time.
Thanks again.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have a dual-boot system on two hard-drives… Win XP on primary HDD, Fedora 10 on slave HDD (which doesn't matter as I change the HDD boot device as needed in BIOS). So, previously, I had Grub installed, with Fedora, on the slave HDD, and the BIOS booting this HDD. When attempting to backup this HDD (and the Fedora system), using the default "Clonezilla advanced extra options", my Fedora /boot partition was lost and Grub was moved to the Win XP MBR (on the opposite/primary HDD). Since then, I have re-installed Fedora 10 on the same HDD, but this time installed Grub/bootloader in the MBR (primary HDD). I would like to backup each system partition again using Clonezilla, but would like to seek advice/help regarding what could have caused the previous problem so it won't happen again. I assume it had something to do with the Clonezilla Live CD "Clonezilla advanced extra options" default setting for restoring the MBR, but am unsure, as I am still a bit of a Linux newbie. Can anyone please help?
My result of "df -h":
bg3075,
Thanks for your question and using Clonezilla! You may recall during the clone process there is a point where it mentions the exact command used, I believe that gets saved in with the image file if one is made. Perhaps, if you share that command, it may help diagnose what exactly happened.
Thanks!
Alan
Alan, this below was in a file (within the image directory) titled "Info-packages.txt":
Image was saved by these Clonezilla-related packages:
drbl-1.9.3-43 clonezilla-2.3.2-80 mkswap-uuid-0.1.1-1 drbl-partimage-0.6.7-1drbl drbl-ntfsprogs-2.0.0-4 partclone-0.0.9-4 drbl-chntpw-0.0.20040818-7 drbl-lzop-1.02-0.8drbl pigz-2.1.4-1drbl pbzip2-1.0.5-1drbl
And, below, from a file titled "hdb-pt.sf":
# partition table of /dev/hdb
unit: sectors
/dev/hdb1 : start= 63, size= 401562, Id=83, bootable
/dev/hdb2 : start= 401625, size= 17414460, Id=83
/dev/hdb3 : start= 17816085, size= 11261565, Id=83
/dev/hdb4 : start= 29077650, size= 49078575, Id= 5
/dev/hdb5 : start= 29077713, size= 8193087, Id=83
/dev/hdb6 : start= 37270863, size= 7164927, Id=83
/dev/hdb7 : start= 44435853, size= 2040192, Id=83
All other files either could not be opened by gedit, or simply contained basic hardware information on my computer (that I really would consider useless).
Thanks
bg3075,
Oops, sorry about sending you on a wild goose chase! I just took a look at my archives and realized the command line parameters given to Clonezilla are not saved with image, I'm not sure why I thought they were! (Maybe they should be? Like a log? Steven?)
Anyway, I thought it might help if we understood the specific commands issued. From what you describe, it sort of sounds like you went the 'device-device' route, but if you did that, then there wouldn't also be a folder with files (aka the 'image')? If the image was made at some other time, perhaps an attempt was made to restore the image to the wrong (primary) drive? I still find hda/hdb and Linux mount points a bit foreign so, I could see how this might happen. But, I'm not really sure how the Grub/MBR could could get moved to another drive without multiple steps or some defect.
On the other hand, it may be silly to try to recreate the exact previous situation, since your set up sounds pretty normal and *shouldn't* be a problem. So, here's what I can recommend. First, since there was some trouble before, it'd probably be a good idea to back up any critical data until the process and any defects are sorted out.
Get the latest version of Clonezilla (1.2.3-14), as it seems you are a bit out of date and there have been many fixes and improvements (Thanks everyone!). Then, try going through using the 'device-image' route and 'beginner' mode. I've been enjoying 'beginner' ever since it showed up and it's taken care of everything I need! Keep track of your choices as you go along and/or the command line parameters. That way, if there is trouble, we can diagnose things a little better.
If anyone has other suggestions, please chime in, thanks!
Alan
bg3075,
To disable the MBR restoring, you can enter expert mode, uncheck "-g auto" and check "-t".
Alan,
Yes, it's a good idea to save the comman in the image dir. I will do that in the next release.
Steven.
Thanks guys, though I haven't tried to save an image again yet. I am still scared to try it at this time. So, after looking up information from various sources, it seems that the problem I had may be explained here:
http://www.sysresccd.org/Sysresccd-Partitioning-EN-Repairing-a-damaged-Grub
The section "Why Grub may break"; subtitle "disk cloning: you may want to clone your partitions to another disk or another computer for some reasons. If you just clone the partitions of the disks, the sectors where Grub is installed may not be copied (eg: sectors before the first partition, or MBR). "
though, when this first happened Grub was still available, though it lost the boot partition, and therefore, Grub couldn't boot Fedora. Though, I still do not know how to apply this information to the use of Clonezilla. I could not find Clonezilla instructions for the advanced parameters. It would be nice if someone could explain/add this to the online instructions for the Clonezilla site, though I know this is all purely volunteer work and a lot of people may not have the time.
Thanks again.
You should have a chance to enter "expert mode" like this:
http://clonezilla.org/clonezilla-live/doc/02_Restore_disk_image/images/ocs-08-beginner-expert-mode.png
For more info, please check:
http://clonezilla.org/clonezilla-live/doc/showcontent.php?topic=02_Restore_disk_image
Steven.