can't seem to stop clonezilla from including MBR in partition image
 

I've searched around some, and most every thread I can find involving both "clonezilla partition images" and the MBR are about people who are having trouble getting clonezilla to include the MBR. And the prevailing wisdom seems to be that clonezilla only does that when cloning whole disk {as in /dev/sda rather than /dev/sda1...

I've quoted one good concise example of said prevailing wisdom from the thread at:

http://www.linuxquestions.org/questi...loader-835139/

I like kbp's clear instructions on how to use dd to clone an MBR. In fact I've added that part of this quote to my personal help files.

However, so far what little experience I've had with clonezilla is that partition images do in fact include and restore the MBR. And that fact is making me consider looking for another back-up tool...

Does anybody know how to force clonezilla to NOT write to the MBR???

The longish explanation below includes a detailed description of what I did...

I've been multi-booting Linux for years. I don't consider myself a programmer, but I'm very comfortable with installing a Linux distribution to any one of the 5 30 gig Linux partitions I multi-boot my desktop from, making sure to only allow it's installer to install its bootloader to the 1st superblock of it's own partition. This allows me to use one of the 5 standard chainloader entries in my manually maintained grub {legacy} boot menu to boot the new Linux, while allowing each Linux distribution's package management system to automatically update it's own kernel and/or initrd files as needed.

I prefer grub legacy because I have difficulty getting grub2 to use LABEL=SomeUniqueHumanReadableLabel rather than UUID=UnreadableGarbage to identify the root partition.

I occasionally bother to dig out my notes to remember how to make a tarball of a Linux partition (using numeric-owner) but it's such a pain that I don't do it often enough. And I'm none to sure the tarball method would restore a bootable windows partition. So when I recently found out about clonezilla I downloaded & burned a copy. I then experimented, using an old win95 era Toshiba Satelite laptop as a testbed.

I made only partition images. (Specifically of /dev/sda1 & /dev/sda3) But in both cases, when I restored them clonezilla also wrote to the MBR. Which is something I need it to NEVER do unless I'm restoring a "whole disk drive" image...

The old Toshiba laptop has 6 gig HD, which had Bodhi Linux on /dev/sda1, and /dev/sda2 was a swap. I cloned /dev/sda1 to a usb drive. Then I used gparted to shrink it to make room for a 1 gig fat32 partition on which I installed FreeDos to /dev/sda3. Note the physical partition order was:

/dev/sda1
/dev/sda3
/dev/sda2

I then used apt-get to convert Bodhi to from grub2 to grub legacy. But I forgot to properly purge the "grub-pc" & "grub-common" configuration files. This resulted in update-grub being unable to create or maintain a "menu.lst" file. I was able to cobble together something to boot with, but it was going to make system updates cumbersome, and switching back to grub2 didn't help. And then switching back to grub legacy using the --purge option didn't work either. And after that, I couldn't do anything with apt-get without it complaining about some incompletely installed/removed package... At this point I was glad that I'd cloned Bodhi before butchering the bootloader etc... Unfortunately I was going to have to restore /dev/sda1 to it's original size to restore it. And I'd already spent many hours installing configuring and several utilities and games to FreeDos. So I cloned /dev/sda3, before deleting it, and resizing /dev/sda1 back to it's original size.

Then I restored the clone of /dev/sda1, expecting to have to use a rescue disk to reinstall it's grub2 to the MBR. But to my surprise, the MBR that had been pointing at grub legacy's stage1, was replaced by one that pointed at Grub2... ???

At this point I again switched to grub legacy (making sure I properly purged them pesky configs). Next I resized /dev/sda1 to make room to recreate /dev/sda3. This time when I booted clonzilla I 1st made a new backup of the resized /dev/sda1. Then I restored the FreeDos clone to /dev/sda3. Clonezilla proceeded to trash my working grub legacy MBR with some garbage from FreeDos partition image... ???? Oh {expletive deleted}

Now I like the idea of clonezilla including the MBR data in a "whole disk" image, but I need to know how to tell clonezilla to NOT molest the MBR of the target drive when restoring a partition image that may or may not have come from that same drive, and/or which MBR may not be pointed at the same {currently working} bootloader as was in place the day the source partition was cloned. I mean I CAN fix the MBR when that happens. but it's such a pain that having to do that all the time will make it hard for me to get in the habit of making regular backups...

In all this I get the feeling that you put grub on the partition in question maybe?

Not too many other people have issues with this. Most people in fact do not copy the mbr and get into trouble.

That could maybe have something to do with why restoring the image of the /dev/sda1 partition containing Bodhi Linux complete with /boot/grub also restored the MBR

But that wouldn't account for why restoring the FreeDOS partition, /dev/sda3 also overwrote the MBR...

While I'm no expert with what really happens when FreeDOS's installer writes "FreeDOS specific" data to what it calls the bootsector or "Volume Boot Record", but the functional effect was the same as when a Linux installs it's bootloader to the 1st superblock of the "/" partition, in that to boot with it one "chainloads" the partition from a bootloader that is installed to the MBR... Which is how most of my Linux are installed on the three other computers where I'd like to use something like clonzilla. And if the actual MBR gets overwritten when restoring a Linux partition containing a grub or grub2 that was installed to it's own "/" partition like what happend with my FreeDOS partition, I'll go nutz with it...

Yeah. I noticed that. Of course, it's hard to think of a Linux Distro that doesn't have at least one how-to link for restoring grub and/or grub2 to the MBR with a live/rescue cd/dvd. Though I imagine that forgetting to backup the MBR could be seriously problematic for someone using a "windows" bootloader.

BTW if they would also include a menu choice to skip restoring the MBR when restoring partition images, I'd be in favor of clonezilla always assuming the MBR should be preserved even when saving individual partition images.

Likewise I think it would have been a nice touch if there was a menu choice to save and/or restore ONLY the MBR without the user needing to understand the syntax of the dd command line.

At this point I'm thinking that I'm going to have to do some empirical testing to find out if I can get consistent results.

To do that, I think I should maybe clone my desktops entire hard drive, so that I will be able to repair any damage that may occur when I make/restore partition clones of various individual partitions. Including at least one that includes a grub that's installed to it's own "/" partition, plus my actual separate boot partition containing my manually maintained grub legacy. I'd also include the FreeDOS partition that I installed there as well, to test if perhaps it's something odd about how FreeDOS's partition bootsector is written that caused the undesirable clonezilla behavior. And, I think, at least one data partition containing no boot loader files at all...

Then I'd have to restore them repetitively in various order to see which, if any, mess with the MBR, as well as which, if any, lose the ability to be chainloaded from my grub menu. (I'm hoping that it was just a fluke when restoring the Freedos partition resulted in both an trashed MBR and a copy of FreeDOS that couldn't be chainloaded...)

This testing might have to wait till my limited resources can spring for a new USB drive however, as I doubt the one I've got has enough free space for all those image files at once...

By the way, I've read that clonezilla images can be restored to a larger partition than they were saved from. But I'm not sure if restoring a 10 gig partition onto a 15 gig target partition would waste 5 gigs of drive space? Which would be OK if qparted would be able to see the difference, and therefore resize the new partition to fill up it's available space?

In some cases you can restore to a larger disk or partition. The issue of some OS's to identify the size in some file may prevent that. Some other reason may include disk-by assignments. Then you have to check the filesystem. Not sure there is a 100% way to say. Some say clone to size and then use native tools to re-size.
I have used a bit by bit command (dd) to clone stuff. Clonezilla can do that but tries to use a file based copy if it can read the target.

I guess you could use a binary viewer or access the disk by block to see what is what.

It could be that some version or error in what you can is causing this. Worse comes to worse then you might try to use dd to copy bit by bit or other file based copy like tar.