"A disk read error occurred" Windows 7

[arduinoAndMore]

Hi all, I set up a FOG server (FOG 1.2.0, Ubuntu 14.04.3) And I’m preparing for a Windows deployment for almost 300 units. We have used MDT to lay a slightly outdated image on a Dell machine we had laying around. It was sysprep’d, and I uploaded its image to FOG this afternoon. For some reason it took 4 hours to capture a 27GB image (gigabit all the way), but it seemed to be successful. I deployed the image to one of the new Lenovo laptops (that’s what we will be imaging). The image deployed in 17 minutes (unicast) and it rebooted when done. When it came up it said “A disk read error occurred Press Ctrl+Alt+Del to restart”. This is problematic.

I found a post here (http://www.edugeek.net/forums/o-s-deployment/41560-nc10-imaging.html) where “ssx4life” suggests in a post from 2009 that FOG should capture the image using the multi-partition single disk mode rather than the single disk resizable mode I’ve been using. There is surprisingly little FOG-specific information on this error, and that’s about all I have to go on.

The plan was:

1. Image Dell machine with WDS (Lenovo machines are having trouble with PXE boot to the WDS for some reason)
2. Sysprep Dell
3. Capture image of Dell with FOG
4. Deploy image to Lenovo
5. Customize/update, sysprep.
6. Multicast deployment to the rest of the Lenovo machines.

Step 4 looks good until reboot. From what I can find there is something wrong with the disk or the partitions. I’m thankful for any advice you can give!

EDIT: Note I also use this server under the same configuration (and image type) to deploy Linux and it works correctly.

[Junkhacker]

the fog of 2009 would be from a very different version of fog.
is there a reason you’re building the image on the dell instead of the lenovo?
4 hours to capture a 27GB sounds very odd to me
did the imaging task seem to go properly when you deployed it to the lenovo?

[arduinoAndMore]

@Junkhacker Hi Junkhacker, thanks for your quick response.

1. Yes you’re right. That’s why I didn’t want to invest a lot of time trying it before asking here. The documentation of this error after using FOG isn’t documented in very many places

2. There was an issue with the existing MDT server that wasn’t letting the newer Lenovo BIOS PXE boot. We imaged the older Dell and tried to copy/paste the image. I think we are going to try to rebuild the image on a Lenovo. Lenovo tends to do interesting things with partition tables anyway, so hopefully going from Lenovo to Lenovo will be more workable. I intend to try using the resizable image unless someone has a reason to consider another option.

3. The 4 hour upload time is very odd. I can’t imagine what is causing it. Still open to thoughts. More info on that:

• Closed imaging network using VMWare Player for the Ubuntu server
• Gigabit NIC from my workstation to an HP 2650 gigabit 48 port switch, into a gigabit port on the client.
• No throttling or bandwidth limits are set on VMWare’s virtual adapter.

4. Yes. It went exactly as it does when it works (like on the Linux deployment)

Thanks again for any advice!

[arduinoAndMore]

Update: we are still preparing the base image for the Lenovo machines, so there isn’t anything new to report there. I touched on the Linux deployment I’m doing, so I’d like to expound on that a little more. I’m deploying a customized version of Lubuntu which boots to fullscreen Firefox 39 with some addins to lock it down. The distro is going on older Dell 2100 netbooks (Atom, 2GB) to be used for k-2 education websites. I have been through several deployments so far as I work the bugs out of the master image.

Issues I’ve had:

• Multicasting only likes to work reliably after running the following after a clean boot and clear task list.

mysql -u root <-p password> fog
truncate table multicastSessions;
truncate table multicastSessionsAssoc;
exit;

sudo service FOGMulticastManager stop
sudo killall udp-sender
sudo killall udp-sender
sudo killall udp-sender
sudo service FOGMulticastManager start

• Multicasting sometimes takes 3 minutes, but more recently that has jumped to 12 with the same size image.
• Capturing a 3.x GB image takes 1-2 hours, which it should not <— probably the most annoying thing.

I set up NIC bonding (mode 6) on my Ubuntu 14.04.3 server running FOG 1.2.0 but that doesn’t seem to do much. I’m not very read-up on bonding though so maybe that’s normal with multicast.

I hope someone can shed some light on these issues as well (don’t think it’s worth a separate thread). Thanks!

[Wayne Workman]

@arduinoAndMore For the multicast issues, can you try a fog server reboot and then see what speeds you get?

Also - how long have your switches been running? Maybe schedule a reboot at midnight or something?

[arduinoAndMore]

@Wayne-Workman I’m on a closed imaging network. The FOG server VM has been rebooted several times. The switch has been running <24 hrs. This morning I am capturing an image of Windows from the aforementioned Lenovo machine (30GB) and the time is looking like it will come in at around 1:10 or so. I guess that is about normal. I don’t know why sometimes it takes longer than others.

Thanks for your reply

[Wayne Workman]

@arduinoAndMore Compression has a major impact… And image type… if you choose resizeable and your source machine is extrememly fragmented, this will take a considerable amount of time to resize.

Please read through this: https://wiki.fogproject.org/wiki/index.php/Image_Compression_Tests
Those results are all from virtual FOG servers working with bare-metal hosts I think.

[arduinoAndMore]

@Wayne-Workman I never though about the fragmentation being the culprit. I was capturing that image from an old machine which probably hasn’t been de-fragmented lately. I should note that I took several uploads from that same machine, all with the same settings, but sometimes it took drastically longer. Oddly enough, my longest (and last) upload produced my fastest multicast sessions. A 2hr upload of a 4GB image (uncompressed) deployed in 3 minutes as opposed to 12 minutes with the 1hr upload. That’s actually not a bad deal if you’re doing a few batches Anyway, I’m going to guess that the fragmentation has something to do with it.

Thanks again!

[arduinoAndMore]

Update on the main topic: I finished a unicast deployment to one Lenovo, and I still get the disk read error nonsense. I’m trying another machine to rule out hardware (we are suspicious of that particular machine) but honestly I’m suspecting the image itself. So I guess we are back where the thread started Any continued help is greatly appreciated!

[Wayne Workman]

@arduinoAndMore I am assuming you’re not deploying the image to the same machine that the image was uploaded from… because you’ve uploaded and downloaded several times.

make sure the destination machine’s firmware settings match the source machine’s settings.

For example, if the source is set as Legacy with AHCI HDD operation mode, then the destination needs the same.

[arduinoAndMore]

@Wayne-Workman I deployed to a different machine with the same BIOS settings. My (new) suspicion is this: The image in question was a “single disk resizable” type, so I think (and gparted live cd confirms) that we aren’t cloning all of the partitions on the original disk. It might be rolling the old ones into one partition? It comes up with one large partition, and one partition that is about 100MB. In gparted there is a warning sign over the 100MB partition. I’m currently capturing a single disk multiple partition image that I hope will grab and restore all partitions correctly. Does this seem reasonable?
Thanks!

[Wayne Workman]

@arduinoAndMore Ok. I think I know what the issue is.

Is this image based on a manufacturer’s base image? Is it from scratch or did you just alter & configure the existing image for your needs?

[arduinoAndMore]

SOLVED: Switching to the multiple partition image type solved the problem. I’m deploying a 13.xGB image in around 20 minutes in batches of 36. It’s going just fine now. Thank you for all your help. Seems to be a good active forum

Thanks again!

[Wayne Workman]

@arduinoAndMore lol OK, glad you found AN solution.

[PenelopeHudson394Ki]

@arduinoandmore

Pointers to be looking for

1.The bus connecting the hard disk to the mother board is faulty.

2.The master boot record (MBR) on the hard disk got corrupted.

3.SMPS (Switch Mode Power Supply) failure. In this case, your computer may not boot at all. But there are times when only one of the power plugs may fail.

If anyone has encountered any other points of failure, please follow this solutions provided below.
https://www.errorsolutions.tech/error/a-disk-read-error-occurred/
Solution 1. Reconnect hard disk drive (HDD) or solid state drive (SSD)
Solution 2. Recover Master Boot Record (MBR)
Solution 3. Check Hard Disk Drive (HDD)
Solution 4. Replace the Hard Disk Drive (HDD)/ Solid State Drive (SSD) and Install Windows