Getting "disk read errors have occurred" after image completion on Fog trunk v7198
-
@Tom-Elliott I’ve read a couple of things about windows bootup process, BCD, bootmgr and so far I haven’t found a way to extract the start sector information from rec.img.000 or sys.img.000!
The problem is actually really simple from what I understand. The boot code in the MBR (if we don’t find one in the image we just deploy our e.g. win7.mbr) is pointing to the start of the first partition to try and find bootmgr.exe. Our win7.mbr comes with start sector 2048 and we must fail if we re-create the first partition starting at sector 63.Now in FOG trunk we re-create both partitions - which is not a really bad idea.
I guess I was wrong with what I said. I think recreating the first partition on a different start sector is not very wise. I am able to reproduce the exact error in a VM. Just need some more time to play with this and I hopefully might find something we can do. The assumptions on start sector and partition size we are doing if layout information is missing will only work by pure luck.
-
@Developers Ok I actually found the information on where the first partition is meant to start within the rec.img.000 file. Well I should better say how many hidden sectors are being expected. Let me explain. The MBR code in the first sector of a disk is looking for the first active marked primary partition, reads that partition’s VBR (volume boot record) and hands off execution to it. At this stage it does not matter if that partition starts at offset 2048 or 63 or any other sector! But within that VBR the number of so called hidden sectors (sectors before the VBR starts) is stored at position 0x1C. Starting from Windows Vista this number defaults to 2048!! Although I was able to get past the
A disk read error occurredmessage (which you run into if partition start sector and hidden sector count mismatch) by partitioning a disk with sda1 starting at sector 63 plus modifying that hidden sector count to also make it 63 (0x3F) using a hex editor - just tried to proof to myself that I am on the right track with that and that Windows 7 does actually boot from sector 63 (I guess there are people around who have messed with this and we as FOG team will have to face it at some point).If you are keen to dive into this I suggest reading through those three articles: http://www.dewassoc.com/kbase/hard_drives/master_boot_record.htm, http://thestarman.pcministry.com/asm/mbr/NTFSBR.htm and http://thestarman.pcministry.com/asm/mbr/W7MBR.htm
Valuable information for the quick reader:Note: Under Windows
Vista and Windows 7, the number of “Hidden” or Reserved Sectors for the first partition has been increased to 2048 (0x800) rather than 63 (0x3F).and
Basically, since the starting offset for many disks, including the majority of Windows XP OS installs, was 63 …
So back to the very practical side of this. Instead of checking for image format or legacy type (fog.download line 99) I’d opt for defaulting to 2048 as this case branch is Windows 7/8.1/… only anyway! Sure there is a chance of people having messed things up by making it start at 63 but we should definitely default to 2048 I reckon! Hope it’s not going to break things for a lot of people out there.
For all of you who haven’t followed this all the way I have to say that this whole story is only playing a role for images that are missing the
d1.partitionsinformation where we have to make assumptions on the partition layout (FOG pre 1.2.0 I think)!!If we are not happy with the default assumption on sector 2048 I can put together some kind of code to extract the hidden sector count value from the rec.img.000 file. Any votes for this?
-