Long story short, i wanted to dual boot windows xp and mint on my acer aspire one. Knowing I could bork it i did what i was told by the internet and backed up my mbr, partition one (pqservice acer hidden recovery partition, sda1) and partition two (windows xp).

So originally, it looked like this:

PQSERVICE 4 GB
ACER 144 GB

alright, so I used gparted to shrink the 144 GB to 100, then put mint on the unallocated space. worked great, but not really for me, so i think i'm gonna do ubuntu or debian.

So i said to myself, ok, let's do this later, and see if we can do a recovery for the first time! now this is what my question is: why, when I restored the MBR using DD, my computer started pretending i never shrunk the partition? as far as i know from wikipedia, the MBR holds the partition table, so it makes sense that it might LOOK like the 2nd partition is 144 GB again and there's not a third one in gparted. But by restoring the MBR i didn't need to go and reflow the Windows XP partition back onto the 144 GB partition shown? I can have an ext4 partition and swap sitting INSIDE what my computer's partition table is simply calling by name a whole NTFS partition? because as soon as I restored the MBR, my windows install sees its own partition as 144GB again, i tried a degrag and free space wipe to see if it really can do anything with that extra 44 gigs it now has, and it looks like it can.

Does anyone with knowledge on partitions and how they work understand what i'm asking maybe? It doesn't make sense to me that I don't have to reformat a partition and can simply apply the road map of an MBR on top of it and everything work right. should i still use partimage to reflow my XP partition onto the "144 GB" partition, or does the mbr pretty much call the shots and it's totally an ntfs partition now?

Thank you!

edit: oh, and what IS standard procedure for checking an mbr and making sure all the partitions are where they need to be? if it's a linux command that's fine, i have a liveUSB of mint still. thanks!

Don't always do what they tell you on the interwebs.

Why would you need a dd image for your MBR?
It's only useful as a backup. Once your partitioning scheme is changed, you'll need an updated bootloader as well.
Your bootloader tells your system where to look for bootable partitions and doesn't interfere with your partitioning scheme.

It's just the first place on your drive. Pick whatever bootloader you like and reinstall it (grub should find both Linux and WinXP without further problems).

You're easiest solution would have been allowing mint to write grub in the mbr (it would have made an entry for WinXP).

It depends on your bootloader.
Linux doesn't even need it.
Some distibutions also use a separate "/boot" with boot instructions.
"fidsk -l" shows your partition table.

PS: If you're planning to install a different gnu-linux distribution, Install it it on your "free space" and allow the installer to use the mbr, it should find your other systems as well.

If it doesn't , post the output from "fdisk -l".

Ah thanks for the reply but my question was a little different than how to make it work. i kinda want to know how the mbr works because restoring it seems to have turned a 100gb ntfs + 42gb ext4 + 2gb swap into a 144gb ntfs. see what i mean?

See the grub bootloader worked fine, it found mint and windows. however, i made the choice to get rid of mint and re-expand the windows partition. only problem is, doing that restore of the MBR looks like it turned 3 filesystems into 1. I know i can have grub boot windows but to make it the same as it was before i would have to make a usb of the windows restore cd image for fixmbr, no? otherwise my dd backup of the mbr will overwrite the mbr and give me back the windows mbr just for the hell of it. in essence i was testing a factory reset of the acer back to my backup.

So to elaborate, i'm wondering exactly why a linux partition and its swap were engulfed by the ntfs partition simply because i overwrote the mbr. essentially with no knowledge of the subject other than google i'm wondering if the mbr is supposed to have the power to say "hey, all you gigabytes after the ntfs 100gb partition, you're all ntfs now and belong to sda2" and work fine, or if there is some other logic that will eventually conflict with this as i fill the disk.

in other words, if you took a 3-partition hd and overwrote the mbr with a partition table that says there's only one partition, not 3, does that give you one partition in reality, or will your computer get confused when it writes more than 1/3 of the disk?

sorry if i'm not being as clear as possible with the question, thanks.

Did you only restore your mbr or did you "restore" windows?
The latter could have wiped your partition table if you(or it) choose so.

Your mbr can't do anything. It's no more than a reserved place at the start of your drive. The above sounds as if you fully restored your system in factory settings (repartitiong everything as well).

Boot your live linux and run fdisk -l to see if those partitions are really gone.

Those Windows recovery tools don't always behave as one would expect.

I didn't restore windows via any external method or windows cd or backup partition, I just dd'd the 512 bytes of my mbr backup to sda again, where it was before i installed mint. Then i booted onto my liveusb to find that gparted was reporting 4gb and 144gb again. that's the weird part. it went from 4gb-fat32? 100gb-ntfs 44gb-extended(containing mint ext4 and swap) reported in gparted, to 4gb-fat32? 144gb-ntfs, simply by overwriting the mbr with my backed up copy.

I didn't do anything else before checking gparted. after that though, i was worried that there may be some sort of conflict between the mbr partition table and the partitions themselves (the whole thing i'm trying to learn here, if that even makes sense) so i used partimage to restore my 144gb backup image onto sda2. now, from what i've heard if the partition was really 100 gb then partimage would fail in the first place.

fdisk just now confirms that there are 2 partitions of the correct size each, adding to 160 gibibytes.

now, maybe i'm not asking the right question. isn't the partition table in the mbr? where does a hard drive keep data that explains what size and location and filesystem a partition is at so OS's won't write ntfs to ext4 etc??

I don't see anything illogical if you did everything in the above order (even though you were playing with fire).

dd'ing all 512 bytes replaced your partition table as well (use count=1 bs=446 to exclude it).
It did not change your filesytem and data, it only made everything less readable and harder to find). At this time you could still reverse this. Booting an OS from your drive would most likely fail.

You recovered your old data using your old partition-table.
Both your mbr (boot-code + partition-table) and your filesystem (with all data) are back in order.
Windows boots again.

It's the second part from your mbr (your bootloader/boot-code being the first part).
I'm not aware of an easy way to read/edit it, but you could always use dd to write it to a file, strip the partition-table parts and read it like that using the "magic key" at end of the file (google for examples).

1 members found this post helpful.