SOLVED W7 Image: Disk read Error after imaging
- FOG Version: Running Version 1.4.0
- OS: Ubuntu 14.04
- Service Version: -
- OS: Windows 7 Professional x64
I am currently having an issue deploying a certain type of image. It only happens whenever i try to use
Single Disk - Resizable. I tried with non resizable methods and it works nicely but it’s not what I am looking for. I’ve also been looking for a solution for a couple of days but all post messages end without a conclusive result .
I get the “Disk read error” message after imaging and the computer won’t boot ( DELL Optiplex 3020 ) and the OS i try to deploy is a Windows 7 Professional x64 - non OEM.
These are the things I’ve already tried:
- Repair Windows using installation CD / DVD ( to no avail ).
- Use other imaging non resizable methods. ( It works but I would want to optimize deployment time ).
If you need additional info feel free to ask.
@Sebastian-Roth This fixed the issue! Thanks and keep up the good work!
sudo -i cd /var/www/fog/service/ipxe/ mv init.xz init.xz.1.4.2 mv init_32.xz init_32.xz.1.4.2 wget https://fogproject.org/inits/init.xz wget https://fogproject.org/inits/init_32.xz chown fog:www-data init*
Then try deploying your image again.
@george1421 @roger-jsf Hopefully I can give some more answers… I think I was able to replicate the problem and I guess it’s within our magic-calculate-partition-resize-awk-script. I might figure this out in the next hours. Please give me a bit more time.
As well I am still trying to figure out why this issue is not more common but only seems to come up with this particular partition layout.
@roger-jsf Ok here is what I’m thinking.
I’m trying to apply logic to this because the issue can be anywhere. At this point we don’t know if the image is at fault or FOG why this target computer doesn’t boot.
If you told me, this is the same reference image that we clone using clonezilla then I would know the image itself is good, then we would focus on FOG as being the bad guy here and try to understand why.
At this point we have to question everything. Was the master image created incorrectly for this hardware? Is the OS missing boot time drivers (like disk controller drivers)? Was this reference image sysprep’d? Was the image taken from another working 3020 and its failing to deploy to another 3020? How are you injecting the drivers for the 3020. Is FOG messing up expanding the disk after being compressed? Is there a hardware issue with the disk in the target computer?
As you can see right now I have more questions than answers?
I don’t understand exactly what are you asking me, so please forgive me.
Are you asking me to replicate the image captured by FOG using clonezilla or if it works capturing and cloning the same machine with clonezilla ?
@Quazz You can exclude this option! I noticed the drive letter issue in WinPE environments and didn’t remember to delete the comment, my bad!
Can I ask how you figured out the disk letters were swapped? Please note that in WinPE enviroments (bootable USB, recovery mode, etc) the drive letters aren’t necessarily representative of what it would be if the system itself booted!
Just want to see if we can exclude a possible issue or not.
Machine used as fog Server: Ubuntu DESKTOP 14.04 LTS.
Link to d1.mbr:
Ls-la of image:
@roger-jsf OK, I just wanted to know if this was a new problem (as compared to a previous version of fog).
So if you use clonezilla to copy the same master reference image it works correctly? Or did you use a new reference image for FOG too?
I’m trying to rule out the reference image being at fault here. There are some drivers that must be embedded into reference image before capture.
@roger-jsf Could you please upload /images/<IMAGENAME>/d1.mbr somewhere and post a download link here. Plus run
ls -al /images/<IMAGENAME>/and post the output here. I’ll try to replicate this issue then.
@george1421 I’ve always used clonezilla for imaging, and wanted to try out FOG because I’ll have to image a large quantity of computers shortly.
In behalf of the FOG installation itself, it was a clean install in 1.4.0 and then I upgraded to 1.4.2 .
@roger-jsf Is this a new install of fog, meaning you haven’t used fog before for imaging? This is your first system or do you have history imaging with FOG?
@george1421 It’s a sata disk.
@roger-jsf Forgive me if I already asked this. What hard drive is in the 3020? Is it a nvme or sata disk?
The reason I ask, for nvme you need to have 2 fixes for Win7 installed in the reference image or Win7 will not see the nvme disk.
@Sebastian-Roth Following Goeorge’s advice I updated to 1.4.2, created a new image , redeployed the image and it didn’t work.
@roger-jsf Ok, now I see why things go wrong. The start of the partitions are being moved. See the different numbers in the picture you posted.
Re-reading your initial post I just saw that you are using FOG 1.4.0. Sorry but I didn’t notice this earlier. Could you please upgrade to the very latest version. Tom has worked on this stuff and we need to see if the issue is still persistent in the current code. So please upgrade and re-deploy that same image to one of your clients.
@roger-jsf Thanks for posting the picture and listings. To me this looks pretty good. Nothing out of the ordinary as far as I can see. We were fighting with
type=departitions about a year ago but FOG should handle those properly since then!
Can you please boot up this client that you deployed to with a debug deploy task again (normal deploy in FOG web GUI but check the debug checkbox in the view just before scheduling the task). Let the client boot and it will ask you to hit ENTER twice and drop you to a command shell. Run
sfdisk -d /dev/sdathere, take a picture and post it here.
By the way: Which setting for “Operating System” is set for this image in the FOG web GUI? Is it “Windows 7 - (5)”?