"A disk read error occurred" Windows 7
-
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!
-
@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?
-
@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
-
@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. -
@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!
-
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! -
@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.
-
@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! -
@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?
-
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!
-
@arduinoAndMore lol OK, glad you found AN solution.
-
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
