1 Attachment(s)
With apologies aforehand...
For saikee...
I've avoided this inquiry in hopes that I might either get this (frikkin') boot on or run out of ideas. Well, that happened.
I've read all 5 of your major instructionals in hope that I might avoid bothering you with yet another uninformed inquiry, but...
So before getting in too deep it's important to know that I will be happy with a simple reference to an applicable post I might have missed.
And to admit that I may have broken a rule or two in the get go.
Box is a 2002 Compaq/HP running XPSp3. Original partitioning on the original included a C: with the usual complement running on ntfs. And a D: (Presario-RP) with restore/repair/renew capabilities on Fat32. Pretty standard I think.
Following what I thought might be an allowable and also operational dd which worked amazingly well (great technique and advice!) and exactly as predicted. It was a lovely dd.
The D: was put on a FAT32 partition in the beginning of the recipient drive and the C: onto the 3rd primary in ntfs. The D: wasn't helping boot (it just wanted to wipe the whole recipient disc) so I took that out but left the FAT32 format as is otherwise.
I worried that the D: was in a first primary (where? windows likes to boot) and the C: was in the third...separated by an extended for the two Linux)
(As you will see from the Parted Magic image I've included or the table from the same source)
The Linux OSs I'm running on the recipient disc (Kubuntu & Mepis) BOTH
list the Windows partition correctly in their respective GRUB menus.
And both will access and manipulate files in the unbootable M$ partition..
all the data seems entirely ok.
I've tried changing the boot flag, getting Mepis to put GRUB at root (which it seems to refuse to do?..I don't know how to 'make' my distros do as you've suggested. I also don't know how to use the Kubuntu 9 to tweak the GRUB location. It no longer has a GRUB application evident in 'system'. Both /boot/grub/menu.lst(s) seem o.k.
Tried several boot codes (mostly just uninformed mimicry from codes I've seen or made up on the fly or) using the SuperGrubDisk and its GRUB command. line (which is also unable to get Windows up).
SGD is otherwise very useful...if I corrupt (usually the Mepis) GRUB.
The original M$ disc is fine..has never been alive with the recipient disc
from the beginning. I just switch the plugs back and forth when I decide to.
Pain.
So this is getting long and I guess my questions are:
-Any sorta easy fix..I'm not so great on scripting or compiling unless I can straight copy it? Like a fresh boot code from the information I've forwarded
-Can I just switch partions around...if its just a matter of the order of things
-Or should I best just get another clean disc and so do - as you've advised in your B: instructional - Whole disc t=>o whole disc. Regardless of the formats thereupon.
-Or any other[IMG]/home/Owner1/Desktop/PNG image - 839X504 Pixels[/IMG]
thanks very, sorry to be a trouble
P.S. Can't seem to attach the Ksnapshot .png of the partitions screenshot/ Parted Magic.
Will e-mail if it'll help
saikee -- Just an hypothetical and...
...having abandoned that fruitless effort.
-IF I had dd'd the C: into a capacious ntfs partition to follow immediately the D: (utility) partition
which I did put first in the recipient disc,
which did clone functionally in that FAT32 pre-formatted partition?
-WOULD that more likely have worked for a good M$ boot?
Since that would have replicated the original order & placement configuration.
There would still have been other stuff in the following partitions.
[I just read your nice reply post more carefully and wondered]
Per your second nice reply...
And I have decided on disk to clean disk on your good advice.
And will not persist on this topic after this final inquiry .
But -- sticking [hypothetical] wonderment Re:
Quote:
as you "do" have other partitions in the original disk which is not available in the target (or recipient) disk. Thus the first sector or MBR of your two disks will be different.
My source/origin disk has NOTHING on it but the FAT32 D: utility (first)
and the ntfs C: operating main (second).
I proposed:
To first fill a clean first FAT32 partition on the recipient/target disk with the D: contents from the source/origin; as I did before.
To then fill a clean second ntfs partition on the recipient/target disk with the C: contents from the source/origin.
The target/recipient disk DOES/would have some other stuff...but only on latter partitions.
I am dependent on a live/CD Parted Magic for most of these machinations, having had good luck
with that external operator and uncomfortable as generally I am with command line operation
(absent specific, almost cut & paste guidelines), so....'nuff sed.
And ALL of that said...I am done troubling this issue and you, who I am sure have much better things to do.
I wish there were a way to donate to your nice resource but have been politely declined in that.
So --cheers anyway, then and most gratefully, yours...