Getting "disk read errors have occurred" after image completion on Fog trunk v7198

[Zourous]

So I’m on Fog trunk version 7198 on a Ubuntu 14.04 LTS. I’ve recently upgraded from v1.2.0 which was recently before that upgraded from 0.32. Images were working fine on v1.2.0 upload and download. Now I’m trying to deploy on v7198 and am getting “disk read errors have occurred” directly on the first boot after the imaging process on 2 different “partimage” images at least. I have always use “single disk” resizeable and the images are set as this in v7198. If I try to switch to any other option the task errors out before starting so I’m sure this is all correct. Is there anything you need to do to the old 0.32 \ 1.2.0 images before you use them in v7198 other than pointing to them and setting them as “partimage”?

[Sebastian Roth]

@Zourous said:

… disk read errors have occurred …

Please run dmesg on the FOG server to see if the server disk is causing this. Could you please upload a picture of the error on screen. That is very helpful for debugging in most cases.

[Zourous]

@Sebastian-Roth

I would post a screenshot but there isn’t much to see. It’s a black screen with the error mentioned which also says " Ctrl alt delete to restart". I’ve booted the PC with a windows PE Ian and both the boot partition and the windows partition are intact. It’s like it isn’t copying the MBR over or something. I’ve just rebuilt the whole server with the same build of fog, to get the same thing again. I copied the image file back from a backup I had before I moved off of v0.32. I feel like I’ve done something unique here as I can’t find anyone else with the same issue. Maybe I’ll try the newest build to see if this helps.

[Wayne Workman]

@Zourous said in Getting "disk read errors have occurred" after image completion on Fog trunk v7198:

Is there anything you need to do to the old 0.32 \ 1.2.0 images before you use them in v7198 other than pointing to them and setting them as “partimage”?

Can you list the contents of this particular image’s directory? The command should be something like this:
ls -laht /images/ImageNameGoesHere

[Zourous]

“Can you list the contents of this particular image’s directory? The command should be something like this:
ls -laht /images/ImageNameGoesHere”

total 21G
drwxrwxr-x 2 build build 4.0K Jun 19 2015  .
drwxrwxrwx 5 root root   4.0K Apr 29 09:05 ..
-rw-rw-r-- 1 build build  21G Jun 19 2015  sys.img.000
-rw-rw-r-- 1 build build 8.7M Jun 19 2015  rec.img.000

I tested one of my old backed up old 0.32 images back on Fog v0.32 and it imaged fine. Have just built a new fog server and now on v7356 and I’m back to the same issue again upon first boot after image deployment of “disk read errors have occrred”

[Wayne Workman]

@Zourous I think these are partimage type images, instead of the newer format partclone.
FOG 1.2.0 and FOG Trunk support partimage but I think you have to tell it to use partimage for that image - or maybe even for the whole server, not sure. Asking @Sebastian-Roth or @Tom-Elliott to clarify.

[Zourous]

@Wayne-Workman said in Getting "disk read errors have occurred" after image completion on Fog trunk v7198:

@Zourous I think these are partimage type images, instead of the newer format partclone.
FOG 1.2.0 and FOG Trunk support partimage but I think you have to tell it to use partimage for that image - or maybe even for the whole server, not sure. Asking @Sebastian-Roth or @Tom-Elliott to clarify.

Just to reiterate, I have set the old 0.32 images to “partimage” instead of “partclone” in the image properties. I’ve tried a brand new image upload and download in Fog trunk and this worked fine, it just doesn’t seem to like my old images at the moment.This means I’ve got a separate server build on 0.32 so I can just restore old images. Trouble is I also need to play with W10 so appreciate the new stuff in the trunk version.

[Wayne Workman]

@Zourous apologies. @Sebastian-Roth ideas?

[Sebastian Roth]

@Zourous Would you please be so kind and upload a picture of the error on screen or at least post the exact error message here in the forum. I try google for “disk read errors have occurred” but there is not much I can find.

If FOG wouldn’t copy the MBR there wouldn’t be a partition table and no partitions…

Thanks for testing (re-capture and deploy in trunk) and elaborating (images worked in 1.2.0) as this is viable information! Hope we can find out a little bit more about the error message and we should be able to find what’s wrong. One possible problem could be the newer version of partimage in FOG trunk not handling your images properly - I really hope this is not the case.

[Zourous]

@Sebastian-Roth said in Getting "disk read errors have occurred" after image completion on Fog trunk v7198:

@Zourous Would you please be so kind and upload a picture of the error on screen or at least post the exact error message here in the forum.

This is the message (replica grabbed from the internet) and happens straight after the first reboot from the image completing. I think there might have been a message at the end of the image process before the reboot, but I missed it due to a distraction at work. If I get a chance I’ll try an image again and see it I can catch the message at the end on my camera.

[Sebastian Roth]

@Zourous I have to admit that I obviously didn’t properly read all your posts from start to end, sorry! Nothing personal, just me having a lot less time lately. As I have a quiet moment right now I try to get my head around your issue.
A lot of our script code that does all the deploy stuff has changed since FOG 1.2.0 - so I guess we just haven’t tested all the code handling those legacy image things.

I think there might have been a message at the end of the image process before the reboot

Please schedule the next deploy as debug (right before you click create deploy task in FOG trunk there is a checkbox for debug mode). This way you need to step through the process and you can read all the messages on screen. You could actually connect to the client via SSH to be able to copy&paste all the messages on screen when running the fog command via SSH.

Ok, from what I get between the lines this could be an issue in how we handle the partitioning of legacy images. Good to know that you are able to do a fresh capture/deploy on FOG trunk without a problem.

Important information we need is the OS ID configured for the “old” image on the new FOG trunk server!
As well I need to ask you to deploy that image via your old 0.32 or 1.2.0 FOG server so the client can boot properly. Then schedule a debug (capture or deploy does not matter) task on that client and run fdisk -l /dev/sda when you get to the shell. Please take a picture as we need the exact numbers (no typos allowed!

[Zourous]

@Sebastian-Roth

Ok, rechecking with debug mode it doesn’t look like there is any specific error message as I thought using FOG trunk and an old 0.32 image. Here is the screenshot any way. Not sure it tells you much

“Important information we need is the OS ID configured for the old” image on the new FOG trunk server!”

OS ID on the new server is “Windows 7 (5)” just like it was on 0.32 & 1.2.0

“As well I need to ask you to deploy that image via your old 0.32 or 1.2.0 FOG server so the client can boot properly. Then schedule a debug (capture or deploy does not matter) task on that client and run fdisk -l /dev/sda when you get to the shell. Please take a picture as we need the exact numbers (no typos allowed! ;-)”

See below, hopefully it will help:

[Sebastian Roth]

@Zourous I think we found it! From what I remember looking through our latest script code FOG trunk defaults to start sector 63 for legacy images where we don’t have any partition layout information. As your first partition starts at sector 2048 (which is perfectly fine!) FOG’s assumption is simply wrong and therefore fails to image properly so that the OS can boot. Please give me a little more time over the weekend and I am sure we’ll find a nice solution for this.

[george1421]

@Sebastian-Roth Could this case be the issue with this one too? https://forums.fogproject.org/topic/7299/deploy-problem-with-optiplex-3020/39 It might explain why the two drives of the same size but different models would give different results.

[Sebastian Roth]

@george1421 Good catch! But taking a closer look I kind of doubt that this is the same issue. Here we have a legacy image (partition layout information not available!) but with the Optiplex 3020 the image seems to be a fresh new one from what I understand - totally different I guess.

@Zourous To get around the default start sector 63 you can “simply” add partition layout description files to your image on the FOG server. Create two text files with the following content (make sure you get all the numbers right!):

• /images/BASE32STD2015/d1.fixed_size_partitions

1:

• /images/BASE32STD2015/d1.partitions

label: dos
label-id: 0x86308630
device: /dev/sda
unit: sectors

/dev/sda1 : start=        2048, size=      204800, type=7, bootable
/dev/sda2 : start=      206848, size=   312374960, type=7

Then try deploying the image again. Please let us know if this is working for you!?

[Zourous]

Success!

Thanks very much for your prompt responses and efforts which is better than some of the paid support I have to face on a day to day basis as a technician. I can now move all my use all my old images over to the fog trunk server.

[Tom Elliott]

@Zourous I don’t know that I am able to automate a process for this as we don’t know it won’t work until after the first time image attempt. In most cases older images from 0.32 and before always defaulted to a start sector of 63 as @Sebastian-Roth stated. This wasn’t ALWAYS the case, but it was more often than not which is why it got setup in such a way to begin with.

@Sebastian-Roth Do you know of a way I might be able to take this information and use it within the inits?

[Sebastian Roth]

@Zourous Great to hear that this has worked for you. Please be aware that the information I posted might only match this one particular image you gave the information. It might work with other disks (disk size…) and images if you are really lucky.

@Tom-Elliott said:

Do you know of a way I might be able to take this information and use it within the inits?

I have thought about this as well! Looking at the 1.2.0 version to see why it worked for Zourous I was in hope to find a special trick that was made back then. But unfortunately it was pure luck because in 1.2.0 we simply dump the win7.mbr (which has 2048 set as start for the first partition) to disk and only recreate partition number two. Now in FOG trunk we re-create both partitions - which is not a really bad idea. Just the fact that we guess the start sector is not wise.

I am trying to see if we are able to extract the original partition start sector information from the rec.sys.000 file. That’s our only hope I suppose.
@Zourous Would you be able and willing to upload your rec.img.000 file and send me a private message on where I can download it? I will have a look and see if I can find a general solution to this problem.

[Zourous]

@Sebastian-Roth

Hi Sebastian, Yes, the file is only 8.5mb so can probably send as a attachment. I’m not sure how I private message you on here?

[Sebastian Roth]

@Zourous See in the top right corner there is a speech bubble, that’s for private chats. I just sent you a message.