open source partition tool

[zlim]

I was catching up on my reading and came across this http://partitionlogic.org.uk/about.htmlFor those people that only use windows, it looks like it might be useful.Has anyone tried it?I downloaded it and will run it in the next day or two. My main computer has a 120gig hd that I'd like to partition so I can install a few more linux distros. I know if I really mess up the partitioning, I can boot a live PCLos CD and correct my mistakes.

[b2cm]

Be careful. If you can, use a cloning tool to back up your partitions first. Partition manipulation disasters can make partitions inaccesible (in which case you will need a partition recovery tool as rescue cds will have nothing to mount and boot).

[zlim]

I was just coming back to report that I didn't use it - I backed out.I downloaded Rawwrite so the img file would fit on the floppy. I rebooted, entered the BIOS and set it up to boot from the floppy first. The tool loaded and found my hard drives. I wanted to resize my 120 Gig, 117000+ in mb.I decided I'd like to downsize it to 60000MB (more than enough room for windows 2K) then went I went to do it, it issued a warning that this hasn't been well tested! Yikes. I don't want to be the person to discover this without extremely good and current backups that I can install if my windows install gets trashed.I think I have True Image on this computer and a backup image (not recent) on my external storage. I'll make a current image and burn it to CDs.What do I need to do to be sure that my mbr can be recovered if it gets trashed? I'm booting a choice of win 2k and pclos with pclos on a separate hd. Before I do anything, I'll be sure I have all the tools I need and in working order.

[burninbush]

What do I need to do to be sure that my mbr can be recovered if it gets trashed? I'm booting a choice of win 2k and pclos with pclos on a separate hd. Before I do anything, I'll be sure I have all the tools I need and in working order.

Boot a linux, logon as root, and then #dd if=/dev/hda of=hda.mbr bs=512 count=1 (assumes hda is the one you want to save)# mount /dev/fd0 /mnt/floppy# cp hda.mbr /mnt/floppy Note well, you gotta store this mbr copy off the hard disk! If something goes wrong, you won't be able to recover it, if it is stored on the same disk. If you do need to restore it, just run dd again, and reverse the 'if' and 'of' parameters. (if means input file, of means output file)

[zlim]

Thanks, burnbush. Although I've decided not to use the partition tool on a floppy, I will definetly make a floppy copy of my mbr because there is no such thing as too many safety nets.How do I actually restore it if the mbr is trashed? Do I boot a live CD, put the floppy in after I've logged in as root, reverse the if and of. Then assuming the live CD helped me fix it, remove the floppy, shut down the Live CD and remove from the drive and reboot the computer?

[burninbush]

How do I actually restore it if the mbr is trashed? Do I boot a live CD, put the floppy in after I've logged in as root, reverse the if and of. Then assuming the live CD helped me fix it, remove the floppy, shut down the Live CD and remove from the drive and reboot the computer?

OK, so you have hda.mbr on a diskette, and your hard disk tool is telling you that there are *no* partitions or files on your hda disk -- or more likely, you installed some linux distro, gave it permission to write to the mbr, and it did that but screwed-up some way and now neither linux nor windows will boot -- or, the lilo write worked, but you don't like the linux, and installed something else in the same part the first linux was in, and that one failed -- So, get out any live cd, boot with that, logon as root, stick in the diskette and #mount /dev/fd0 /mnt/floppy#dd if=/mnt/floppy/hda.mbr of=/dev/hda bs=512 count=1 #umount /dev/fd0Note in the dd command, hda.mbr is now the 'input file' and /dev/hda is the 'output file'. Block size and count are the same as in the first dd command, i.e., exactly one disk sector of 512 bytes size. At that point, remove the diskette, push the reset button, remove the livecd, and you should have back your partitions, and it'll boot again to windows, or however it booted at the time you took the mbr copy. This is a way of 'getting back' to a previously working boot system.Note, if you change to some later working system -- say, the linux install worked and you have lilo booting OK -- then at that point you must take another copy of the mbr -- it will be different now that lilo wrote over the first part of it. Same if you resize and/or make another partition on the part of the disk past windows. As always, put the copy on a diskette or usbstick, or onto your backup cdr, whatever -- just not on the harddisk you intend to protect. As always, when you change either the partitions or the booting scheme, take a fresh copy. Probably be a good idea to make yourself a little text file describing exactly the conditions at the time you took the mbr copy. One mbr looks pretty much like another from a file manager -- and putting the wrong mbr on a disk is certain to fail in ugly ways. As long as windows is your first partition, you can use that first mbr copy to get back to windows booting, even after a successful lilo write to the mbr. Enjoy --

[b2cm]

Partition manipulation always rewrites the MBR. Restoring a pre-manipulation copy of the MBR after partitions have been resized and data moved will only complicate, not solve a trashed MBR problem. If you have backup images, the clone utility will update the MBR when it restores those images.

[burninbush]

Partition manipulation always rewrites the MBR. Restoring a pre-manipulation copy of the MBR after partitions have been resized and data moved will only complicate, not solve a trashed MBR problem. If you have backup images, the clone utility will update the MBR when it restores those images.

Not sure what 'clone utility' you are talking about here; Ghost certainly will not rewrite an mbr if it is restoring to an existing partition. Got an example of what utility you are speaking about above?

[b2cm]

Ghost certainly will not rewrite an mbr if it is restoring to an existing partition.

It updates the partition table and signatures.

[burninbush]

QUOTEGhost certainly will not rewrite an mbr if it is restoring to an existing partition.It updates the partition table and signatures.++++++++++Well ... do you mean to say it *changes* an existing partition table? What rev of Ghost does that? And to what end? Two situations ... 1) restoring an image to the partition it originally came from, or 2) restoring an image taken on machine X to an existing partition on machine Y -- why would it do anything to the mbr in either case? Obviously, if you are using Ghost restore to change the size of your partitions, it would have to rewrite the mbr, and/or if you were restoring an image to a raw disk -- but that isn't what I said at top.

[zlim]

burinbush, I made my MBR on a floppy but it said - no free space left so I hope it's ok. I also remembered, belatedly, that I had to umount the floppy. I didn't remember to do it in a terminal and it told me only root could umount - linux is smart, LOL. Umounted as root and labeled!I guess there is no way of seeing it is correct short of booting a live CD and using it?

[burninbush]

burinbush, I made my MBR on a floppy but it said - no free space left so I hope it's ok. I also remembered, belatedly, that I had to umount the floppy.

Uhmmm... that sounds ominous. Take a look at the diskette with Win Explorer -- that mbr file should be exactly 512 bytes size -- not nearly big enough to fill a diskette, unless it was already almost full with other stuff. So .. do it over. Stick a scratch diskette in your drive, and root@slax:~# dd if=/dev/hda of=hda.mbr bs=512 count=11+0 records in1+0 records outroot@slax:~# ls -l hda.mbr-rw-r--r-- 1 root root 512 Apr 12 15:47 hda.mbrroot@slax:~#root@slax:~# mkfs.msdos /dev/fd0mkfs.msdos 2.10 (22 Sep 2003)root@slax:~# mount /dev/fd0 /mnt/floppyroot@slax:~# cp hda.mbr /mnt/floppyroot@slax:~# ls -l /mnt/floppytotal 1-rwxr-xr-x 1 root root 512 Apr 12 15:51 hda.mbr*root@slax:~# umount /dev/fd0root@slax:~# Edited April 12, 2006 by burninbush

[b2cm]

Maybe you should ask Symantec folks these questions. Let me just say that if you want to preserve the MBR on the destination disk (no updating) when you restore an image, you have to use the -pmbr switch. That should mean that, by default, Ghost updates the partition table and signature data.

but that isn't what I said at top

Actually, my post 7 wasn't a response to your #6, but to Liz' post 3. Except for post 9, I wasn't commenting on any of your ideas.

[burninbush]

Maybe you should ask Symantec folks these questions. Let me just say that if you want to preserve the MBR on the destination disk (no updating) when you restore an image, you have to use the -pmbr switch. That should mean that, by default, Ghost updates the partition table and signature ideas.

No. That switch modifies standard behavior when =cloning= a disk -- not the same operation as restoring an image, for which you need to use no switches at all.

[b2cm]

Well, suit yourself.

[b2cm]

Ghost documentation calls restoring an image 'cloning':"You can create an image file from a partition to use as a backup, or to clone onto another partition." (Ghost_guide.pdf, p.36)"Cloning a partition from an image file"Once you have created an image file from a partition, you can clone apartition onto a partition on another computer with the image file.To clone a partition from an image file....." (Ghost_guide.pdf, p.38)Ghost documentation says -pmbr switch applies to image-to-disk cloning operation:"-pmbr"Specifies that the master boot record of the destination disk be preserved when performing a disk-to-disk or image-to-disk cloning operation." (Ghost_guide.pdf, p.82)

[zlim]

burinbush, I put the mbr disk I made yesterday into a windows computer and it said almost the entire disk was used with 3kb left. I did get the record in and out yesterday. In any case, I formatted it under windows and I shall try again. This computer has two hard drives. linux is loaded on hdb but of course, the mbr is on hda so that's what I made the copy of. Would the fact that I have two hard drives have any effect on the amount of info in the mbr?Thanks for the walkthrough. I didn't get any messages about the floppy being full...now that I think about it, I typed the first line yesterday and forgot to put in count=1. I realized my mistake and then redid it so let's chalk that one up to user error! Who knows what I had on that floppy. All is good now. I'm going to print out those instructions because when I do this for other computers, I know I'll forget all about the list command so I can see what is on the floppy. (Chalk that up to to many years of using windows gui and forgetting all the DOS I once knew).b2m, I have Boot magic and Partition Magic on one of my computers so if that one goes haywire, I have recovery floppies to get in. That computer also has Ghost installed but my other computers don't.

Edited April 13, 2006 by zlim

[burninbush]

This computer has two hard drives. linux is loaded on hdb but of course, the mbr is on hda so that's what I made the copy of. Would the fact that I have two hard drives have any effect on the amount of info in the mbr?>>zlim+++++++++Nah, each disk has exactly one mbr -- its very first sector -- and it is always 512 bytes size. So ... sounds like you should make an hda.mbr and an hdb.mbr -- one for each of your drives. Don't forget to leave yourself notes!

[zlim]

Always lots of notes - the problem is finding the exact note I need, LOL!My hubby built me a special wooden box that holds my 3x5 index cards with my alphabetized notes plus I have several file folders - all labeled with printed instructions in them.

[burninbush]

Ghost documentation calls restoring an image 'cloning':"You can create an image file from a partition to use as a backup, or to clone onto another partition." (Ghost_guide.pdf, p.36)

OK, back to this topic -- I wanted to run a couple real tests before posting again. Dug into my oldstuff box, found a Quantum 5.1gb disk from the 1998 era, and a cdr holding a win98se image made sometime around 2000; my scribbled notes say it came from a Micron p5-classic box, and occupies ~900mb on disk. In what follows below, all 'msdos' is that from a w98 boot diskette, same for fdisk. Ghost is the dos-mode version from the SystemWorks Pro 2003 edition. In everyuse, it was started with no added switches, and at no time did I go into its options menus to change any default parameters. Msdos was booted with no config.sys or autoexec.bat files. In sequence ... - boot msdos, run fdisk, delete all partitions on 5.1gb disk- reboot msdos, run fdisk, create one partition of 1,111mb, set active- reboot msdos, run format c: /s, reboot- new-old 5.1gb disk boots into msdos OK. - run fdisk, verify drive has one partition, 1114mb reported, 3773 unused- run ghost to restore old 98se image to single 1114mb partition[note "local partition from image" -- call that a clone or a restore as you might like]- 3 minutes later, reboot- win98se comes up -- lots of complaining and loading from the on-disk cabs,but shortly I am seeing a screen from a lab computer of the late '90s. Reboot.- run fdisk again, to check partitions. DRIVE STILL HAS ONLY ONE 1114MB PARTITION! - while in fdisk, create an extended and a logical of size 3773mb. Exit fdisk.- reboot to msdos, run fdisk, verify drive has 2 partitions. Format 2nd partition. - reboot to win98, verify two partitions. MBR has obviously changed with 2nd part. - reboot to msdos; run ghost to make fresh image of C: 1114mb partition- exit ghost, run fdisk, delete extended and logical partition- reboot to msdos, run fdisk, verify drive is back to one 1114mb partition, 3773 unused- run ghost, restore the freshly made image to the 1114mb partition.- reboot to msdos, run fdisk; DRIVE STILL HAS ONLY ONE 1114MB PARTITION! +++++++++++OK, that's enough. There are two places above [lines with CAPS] where the partition info should have changed -- if ghost was overwriting the MBR with a copy fromthe image. But it didn't, it worked exactly as I stated up the thread, no -pmbr switch used. I invite any who care to try this for themselves.

[b2cm]

It does not follow that if you load an image of a disk to a 1114mb partition, and thereafter see the same 1114mb partition with a working Win98, then Ghost did not update the MBR. You would see this result whether or not Ghost updated the MBR, and even if you rewrite the MBR with 'fdisk /mbr' operation.To prove your point that Ghost does no updating when cloning from image to partition, compare the MBR before and after you cloned that image to the 1114mb partition. Try something like:Convert that 1114mb to Ext2. Restart.Backup MBR (pretest) to a file.Clone ghost image to the 1114mb partition. Restart.Backup MBR (posttest) to a file.Compare the pretest and posttest MBRs.

if ghost was overwriting the MBR with a copy from the image

This adds a new dimension to the discussion. I don't think Ghost ever does that. Ghost images contain disk and partition information. The Ghost executable uses that information, the disk and partition information on destination disk, and any specifications the user inputs during the cloning process, making the necessary adjustments to make the clone work.

[burninbush]

QUOTEif ghost was overwriting the MBR with a copy from the imageThis adds a new dimension to the discussion. I don't think Ghost ever does that. Ghost images contain disk and partition information. The Ghost executable uses that information, the disk and partition information on destination disk, and any specifications the user inputs during the cloning process, making the necessary adjustments to make the clone work.+++++++++++++Well, that's a fascinating theory -- can you point to some Norton / Symantec doc that elaborates this? I think you are saying that ghost will always rebuild the mbr -- but I know from experience that you can't recover a lost partition table by restoring a first partition, leading me to wonder about how much partition information is stored in the image [obviously, made at a time when the part table was valid]. I have put my test box back together -- I'll get around to trying your test tweak sometime soon -- or you could try it and tell me the result. I might still have a mobo here that has the bios sector-zero write-disable feature -- would be a sure way to test the notion that ghost always rewrites the mbr.

[b2cm]

can you point to some Norton / Symantec doc that elaborates this

I wish I could. The Ghost executable code and image format are proprietary and not open source. I doubt they would give away trade secrets by publishing details on how their program works. But if you study the documentation on command-line switches you can gather that the program reaches deep into disk subsystem such as the MBR (it even patches the LILO if installed there), extended partition table and partition boot sector. For example:"When Norton Ghost restores from an -id image, it relocates partitions to cylinder boundaries and adjusts partition tables accordingly. Head, sector, and cylinder information in partition tables is adjusted to match the geometry of the destination disk."

you can't recover a lost partition table by restoring a first partition

I'm not sure what you mean by 'lost'. If you mean that if you run a partition utility partitions that used to be on the disk are now missing (and the disk is now all unallocated space), the partition table is still there, only that its records are missing. If you clone an image to this disk, Ghost will supply the information for the first partition. Partition table records for the missing partitions will remain empty. If you have the info on paper, you can use disk editors like the Powerquest Partition Table Editor (Ptedit.exe/Ptedit32.exe) or the Acronis Disk Editor to copy back the information, save it and reinitialize the MBR. Or you can use Acronis PartitionRecovery to scan for and restore those partitions.

leading me to wonder about how much partition information is stored in the image

This is a good point. We will never know if the Ghost image contains a copy of the MBR of the disk when the image was made. Even if it does, it appears that Ghost does not 'restore' (in the sense that it just copies back) the MBR. Instead, it looks like the executable takes the destination disk MBR as it is, and updates it according to the cloning work. Implication is that if you have multiple partitions and want to 'backup the MBR', clone the whole disk, not just one or two partitions. So if an os install or partition manipulation blanks your partition table records, you can get all your partitions back.

or you could try it and tell me the result

The partition table will change in its partition1 type value: from 83 (or 083h) to 0b (0Bh). The first value is the code for the Linux native file system; the second value is the code for FAT32 LBA. (I cheated. I didn't torture myself by dumping the MBRs to file and using a hex editor to check for difference. I used Powerquest PTEDIT.EXE to quickly get the MBR info.)