@ step 3, when I click "write"
![slMkZJn.jpg](http://i.imgur.com/slMkZJn.jpg)
![p4ndbpQ.jpg](http://i.imgur.com/p4ndbpQ.jpg)
![HRTEveR.jpg](http://i.imgur.com/HRTEveR.jpg)
![0eAQHR5.jpg](http://i.imgur.com/0eAQHR5.jpg)
Im running it on W7 embedded std. I can boot up XPx64 on this same machine and run from there though if it would help.
Posted 01 February 2015 - 08:26 PM
Posted 01 February 2015 - 08:44 PM
I will fix that error but I dont understand why you are getting a MBR partition table with random datas (line 2,3 & 4 in your 1st screeshot).
Since you have appended a header of 1MB filled with zero, you should have 4 partitions filled with 0.
Could it be that you did not append the header and that CloneDisk is therefore looking at sector 0 of a partition image?
Regards,
Erwan
Posted 01 February 2015 - 08:50 PM
Posted 01 February 2015 - 08:52 PM
it could be I guess. when I copy /b in cmd I do not get any confirmation in the cmd window but I do get the new .img file and I am loading that file in clonedisk.
you should get a message telling you "one file copied" like this below (sorry for the french).
if not, then you "dummy" header, i.e a 1MB file filled with zero's, has not been appended which would explain why you get random datas while editing your supposedly "blank" MBR.
Posted 01 February 2015 - 09:04 PM
Posted 01 February 2015 - 09:11 PM
attn: I added screencap in prev post after your reply.
here is shots of the usb hdd that I am cloning
ok i see.
why dont you make it easy on you and make a disk backup (not a partition backup) then?
in clonedisk mainscreen, choose physical disk 1, backup (on the right side), choose raw image, and you are done.
i thought you wanted to make a partition backup as if you had several partitions on your disk.
but from what i see in you screenshot, you partition takes all the space on your disk.
so go for it, make a disk backup
Posted 01 February 2015 - 09:15 PM
Posted 01 February 2015 - 09:21 PM
the usb hdd is a 37gb disk that has only a single 2.3gb ntfs active partition. all the rest is unallocated. if I do a disk image then I will have a 37gb file to save, no?
the procedure I gave your previously would have help you with that but the procedure does not seem to work out for you.
go for a full disk image but tick the "disk unpartitioned space" like below.
it will make a full disk image but skipping the non allocated space.
Posted 01 February 2015 - 09:27 PM
Posted 01 February 2015 - 09:45 PM
backing up now.. I want to boot this BU from grub4dos on other disk configs. just trying to boot XPx64 from raw image on any type of HDD I might need to boot it from.
if all goes well, you'll end up with a disk image of 2.x GB, bootable in G4D, qemu, etc ...
Posted 01 February 2015 - 10:12 PM
if all goes well, you'll end up with a disk image of 2.x GB, bootable in G4D, qemu, etc ...
Posted 01 February 2015 - 11:26 PM
Posted 04 February 2015 - 08:47 AM
... also wondering if anyone has made available a tool to adjust logical partitons automatically so that booting XP from them is possible without manual editing first with PTedit.
and Where's Wonko? hope you are well. I know you love this kinda stuff and can read it like the back of your hand.
Hmmm.
I would use grub4dos's partnew command.
Wonko
Posted 04 February 2015 - 08:49 AM
@Wonko : if you happen to read this thread, I'd like your input on the below approach and especially the CHS part in the MBR.
(more details here).
-backup a partition (amongst several partitions on a disk) to an image
-append a header to that image
-edit this header to turn it into a MBR
-edit the BS to make sure it is consistent with the MBR
Posted 04 February 2015 - 08:49 AM
double post...ignore...
Posted 04 February 2015 - 06:44 PM
@Wonko : if you happen to read this thread, I'd like your input on the below approach and especially the CHS part in the MBR.
(more details here).
-backup a partition (amongst several partitions on a disk) to an image
-append a header to that image
-edit this header to turn it into a MBR
-edit the BS to make sure it is consistent with the MBR
Well, apart you are using a few assumptions, the approach is OK.
Assumption #1 the "hidden sectors" (i.e. the size of the file you prepend - which is the English word for "append before" ) must (or should be ) 2048. In real world they are either 63 (on pre-Vista) or 128 (by default on smaller than 4 Gb devices) or 2048
Assumption #2 the CHS geometry can be altogether ignored and instead of a right CHS set of values corresponding to the device geometry you can fake that the volume/partition is beyond 8 Gb even if it is not and just push the 1023/254/63
Assumption #3 the 255 heads 63 sectors geometry is "universal" and can be used anyway on everything.
Assumption #1 is OK as this would probably affect only DOS 5.00 or earlier.
Assumption #2 will make the few (but not so few) people with a picky/problematic BIOS cry as the image restored to a real device won't boot without "proper" CHS addresses.
Assumption #3 will make a few more (but less few than the above) with most Lenovo or HP PC's - but not only - cry as the image, restored to a real device won't boot (those BIOS use a "fake" 240 heads geometry instead of the more common 255 one), but as well, a number of factors may create the "original" have (or the need for the image to become having) a different geometry, such as 16/63 or 64/32 (or the now rare 128/63).
I seem to remember we already had this discussion about CHS, which I believe it costs nothing (or next to nothing) to deal with properly and which you are (or were) too lazy to implement, calculating the right values is trivial:
In batch language:
To get CHS from LBA:
CYL = LBA / (THds * TSec)
TEMPVAL = LBA % (THds * TSec)
HEAD = TEMP / TSec
SECT = TEMP % TSec + 1
Where:
LBA: linear base address of the block
CYL: value of the cylinder CHS coordinate
THds: Total number of heads per cylinder for the disk
HEAD: value of the head CHS coordinate
TSec: Total number of sectors per head for the disk
SECT: value of the sector CHS coordinate
TEMPVAL: buffer to hold a temporary value
so, with a little effort assumption #2 may be corrected.
Assumption #3 is the most tricky, though it depends on actual OS and actually also specific boot code in the PBR for the specific filesystem, it is common enough to have an image not boot because of a non matching geometry.
Some references:
http://www.911cd.net...showtopic=23408
http://www.911cd.net...ic=21702&st=129
http://reboot.pro/to...32-boot-sector/
The FAT32 and the NTFS bootcode (BUT NOT the FAT16 bootcode) in the PBR for Windows 2000 and XP/2003 is affected by this.
The issue here is that "normally" (i.e. until the image is not moved "somewhere else") it is a non-issue, though it is losely connected to Assumption #2, a BIOS that expects a 240 head geometry (i.e. a max value in the Heads field of 239) may well go beserk if it finds there a value of 254 (i.e. a 255 geometry) and - for example in Qemu - the accepted/assumed geometry depends on the size of the (virtual) device (whole disk), i.e. to make an example if I make a disk image larger than 8 Gb (thus *needing* the 255/63 geometry) and in it a partition of - say - 100 Mb, it will use the 255/63 geometry, BUT IF I get just the disk image up to the end of the 100 Mb partition (corresponding to prepending to volume image the "sectros before and the MBR) it won't boot anymore, because the QEMU bios expects a 16/63 geometry for a 101 Mb (or so) virtual disk device.
Since the number of geometries actually used are no more than 4 or 5 (and of course the 255/63 one is the most used):
16/63
128/63
240/63
255/63
64/32
and a few can be directly excluded because of the actual size of the image, it would make sense to have the possibility to re-calculate/correct the CHS data (BOTH in the MBR and in the PBR).
Wonko
Posted 04 February 2015 - 07:41 PM
Hi Wonko,
Thanks for this detailed and expert feedback : this is exactly what I was looking for
About assumption #1, actually I could/should reword my procedure : it will of course work with any value (63,128,2048, etc).
All that matters is that this value is reflected both in the MBR and PBR.
About assumption #2 and #3, this is my "achilles tendon" I am always escaping this C.H.S part.
Did not you post a batch or excel sheet at some point over here? I kinda remember it (and could not find it in the links you posted).
If so, I would, in a very lazy way again, point to this nifty tool of yours.
About qemu, not that latest versions seems to ignore the C.H.S.
Another way to mitigate the "fake" C.H.S impact, would applying a NT6 PBR be a solution? or any other recommended PBR (grldr, etc) ?
I know that this is more of a workaround, not a real solution.
Posted 04 February 2015 - 08:46 PM
Yep , the point with "latest" Qemu is that it may mean *any* among the zillion builds (and of course it is not about Qemu, but rather about the BOCHS BIOS version in use) and just like the "mitigate" using the NT6 PBR (or using the mentioned patches/killchs for NT 5 ones) it means little.
I could (meaning that if I could remember WHICH ones) surprise you telling you that the same BIOS issues are present in *some* versions of VmWare and possibly (but I cannot swear by it) in some of VirtualPC, but it is "normal".
You cannot know which kind of hardware (real or virtual) a "final user" may be actually using and which specific OS he is willing to boot from the (partial) disk image....
.... and even if you go for the NT6 bootcode, then you will need to add to the volume the BOOTMGR, and then you will need to add to it a \boot\BCD (or possibly a \BOOT.INI, chainloading a grldr - which you anyway need to add to the volume - or chainloading another bootsector - which would BTW simply move the geometry issue one step up the ladder )
If you are to use a workaround, the best one would be creating the prepend image containing a grldr.mbr in the MBR+a few hidden sectors AND a very small partition that can be even FAT12, containing the grldr itself and - optionally - a menu.lst capable of directly chainloading (bypassing the bootsector) the actual OS loader.
At the end of the day that would become a simplified version of the crazy trick I put together here:
http://reboot.pro/to...in-bios-to-gpt/
http://reboot.pro/to...-gpt/?p=186471
And I will even further surprise you, telling you how the NT6 booting does not even need to have "sectors before" or "hidden sectors" corrected in the bootsector (if the bootsector is bypassed as above, at least the one for NTFS), if you prefer *somehow* NTLDR re-accesses the bootsector of the volume anyway (and *needs* the coorected "sectors before") whilst BOOTMGR seemingly does not (but it may have some other issues in finding the \boot\BCD).
Still there are a few BIOSes that will refuse (or have anyway issues) booting grub4dos from grldr.mbr....
The (rather simple) formula in batch (but can be used/translated in *any* programming or scripting language using the INT() formula where needed - as batch math is integer only) I posted above.
The Excel worksheet is here, however:
http://reboot.pro/to...a-translations/
http://reboot.pro/to...ations/?p=74116
Wonko
Posted 04 February 2015 - 09:51 PM
OK, thanks. Ive looked at Diddy's guide but seems this is a newer command. also checked steve675 site for more info and it looks like I will need to read the help file in 4.5c grub4dos (I think it is 4.5c, need to recheck that)Hmmm.
I would use grub4dos's partnew command.
Wonko
from trying to get EWF working on XPx64 by using W7 components I think this is because BOOTMGR uses disk ID numbers (GUID?) this is where Im having some difficulty adapting EWF to XPx64, I had it partially working but only by using regedit to make changes directly.*somehow* NTLDR re-accesses the bootsector of the volume anyway (and *needs* the coorected "sectors before") whilst BOOTMGR seemingly does not (but it may have some other issues in finding the \boot\BCD).
Posted 04 February 2015 - 11:30 PM
hi Wonko,
great info as usual..
OK, thanks. Ive looked at Diddy's guide but seems this is a newer command. also checked steve675 site for more info and it looks like I will need to read the help file in 4.5c grub4dos (I think it is 4.5c, need to recheck that)
wonder if erwin.I can add this functionality to clonedisk ;-)
from trying to get EWF working on XPx64 by using W7 components I think this is because BOOTMGR uses disk ID numbers (GUID?) this is where Im having some difficulty adapting EWF to XPx64, I had it partially working but only by using regedit to make changes directly.
I hope to get back to that soon (EWF working on XPx64) just thought I would toss that out there but Ive a feeling you have already considered this possibility.
thanks
Posted 04 February 2015 - 11:31 PM
from trying to get EWF working on XPx64 by using W7 components I think this is because BOOTMGR uses disk ID numbers (GUID?) this is where Im having some difficulty adapting EWF to XPx64, I had it partially working but only by using regedit to make changes directly.
AFAIK/AFAICR the particular difference has never been detailed, all I know is the info here:
http://reboot.pro/to...e-2#entry172712
http://reboot.pro/to...ical-partition/
http://reboot.pro/to...s-also-logical/
http://reboot.pro/to...nded-partition/
Particularly:
http://reboot.pro/to...e-2#entry167962
http://reboot.pro/to...ition/?p=174808
Also, if i am not wrong, a nt6 mbr can also chain ntldr instead of bootmgr.
Yes and no.
Meaning that for the bootcode for FAT12/16/32 all is needed is to chnage the name of the loader.
On NTFS there are two three possibilities:
Please also take into account how there remains however one issue, one is that the hexedits/mods need to take place on the SECOND sector of the PBR, which plainly means that you have not the last sector (outside the volume but inside the partition) backup in case of messing with it, which could be however a "feature" in the sense that you don't have to "sync" the main bootsector with the backup.
Reference to #2:
http://www.msfn.org/...vista-from-usb/
http://www.msfn.org/...-usb/?p=1082456
Wonko
Posted 04 February 2015 - 11:58 PM
On win7, look for fbwf instead of ewf.
Fbwf is available on both 32 bits and 64 bits.
There is a link in my signature on some tests i did on light win7 versions.
Also, if i am not wrong, a nt6 mbr can also chain ntldr instead of bootmgr.
AFAIK/AFAICR the particular difference has never been detailed, all I know is the info here:
http://reboot.pro/to...e-2#entry172712
http://reboot.pro/to...ical-partition/
http://reboot.pro/to...s-also-logical/
http://reboot.pro/to...nded-partition/
Particularly:
http://reboot.pro/to...e-2#entry167962
http://reboot.pro/to...ition/?p=174808
Wonko
Posted 05 February 2015 - 09:16 AM
I'll check your W7 test link. what does nt6 chainloading ntldr have todo with it? you are right about that (I think) but I just want to see where your train of thought is leading from there.
Hi Zoso,
My bad : this is me reading and thinking about 2 posts at the same time (Wonko's and yours).
Discard this statement : not related/relevant to previous post.
I aggree on the EWF part : EWF stands below the filesystem whereas FBWF is one step above (quoting from memory).
There are few examples (google) of EWF running on Win7 (x32 or x64) but many users report instability/corruption.
As for EWF on xp x64, you are using a 64bits EWF or 32bits EWF?
Regards,
Erwan
Posted 05 February 2015 - 10:03 AM
Hi Zoso,
My bad : this is me reading and thinking about 2 posts at the same time (Wonko's and yours).
Discard this statement : not related/relevant to previous post.
I aggree on the EWF part : EWF stands below the filesystem whereas FBWF is one step above (quoting from memory).
There are few examples (google) of EWF running on Win7 (x32 or x64) but many users report instability/corruption.
As for EWF on xp x64, you are using a 64bits EWF or 32bits EWF?
Regards,
Erwan
Posted 27 February 2015 - 10:20 AM
Brilliant ideas! but i want to ask actually i am usinga new software that is "Ahsay software" if anybody has any information regarding this software can certainly reply please. Heard a lot about this software.
Which is good, as I NEVER heard anything about it until you started SPAMming the board with references to it.
Now, when you want to post some SPAM, you could make up your mind and SPAM professionally, if you post once that you are a new user of the software, and once:
Try using "Ahsay software" i am actually using this software from long time and really satisfied using this softwrare.. just it guys! its worth using.
that you are a long time user, it doesn't take much to understand your intent.
Wonko
0 members, 0 guests, 0 anonymous users