No source file passed (writeImage)

[alserran]

Server

• FOG Version: 1.3.5
• OS: Ubuntu Server 16.04

Client

• Service Version:
• OS: Windows 7

Description

After update from 1.2.0 to 1.3.5, I can’t deploy my old images (in Fog 1.2.0 no problem)
I always receive following error:

An error has been detected!
No source file passed (writeImage)
Args Passed: /dev/sda1

Any idea??

[george1421]

would you provide a clear screen shot of the error? Sometimes the context of the error gives a clue to root of the issue.

[alserran]

This post is deleted!

[alserran]

Edit with picture…

[george1421]

@alserran will you provide the output of these two commands executed on the fog server.

1. ls -la /images
2. ls -la /images/sourcesW7PRO64CallCenter

I’m going to suspect that sources above probably doesn’t belong.

Also can you provide a screen shot of this image definition from the FOG management gui?

[alserran]

@george1421 Edit with more pictures! Thanks.

[Lombard]

Hi,
I have the same problem.
I completely reinstalled the fog server with version 1.35 and I copied the files from my old server in 1.2 to the new one, taking care to put the same parameters

[Lombard]

The format of the images should not be the same. Indeed I have the following error:
cannot open file ‘/images/… /d1.patitions’ for reading (no such file or directory)
My files’ calls d1.original.partitions like alserran.
Is there a way to adapt our image?

[george1421]

@alserran Was this image originally captured as single disk resizeable under FOG 1.2.0? I don’t remember FOG 1.2.0 too good, but I didn’t think there was a resizeable option that worked. Because when I use 1.2.0 we would build on a small disk and then use windows to expand itself.

[alserran]

@george1421 Yes, they were (all of them). Im sure resizeable option works… I use it very often.

[george1421]

@alserran Something looks strange with your files in that directory.

Here is what I have in one of my directories for Win7Pro taken in Aug 2016 (FOG 1.2.0 trunk build)

d1.fixed_size_partitions  d1.original.fstypes    d1p2.img
d1.mbr                    d1.original.swapuuids  d1.partitions
d1.minimum.partitions     d1p1.img

I don’t see the d1.mbr record in your screen shot and your image uses sys.img.000. I know the developers have changed the disk formats to improve speed and resizing capabilities so this may be normal. I guess I need input from @Senior-Developers to help identify your disk structure.

[Lombard]

I managed to restore an image of a fog 1.2 from a 1.35 fog.
I renamed the sys.img.000 file to d1p1.img and changed the partition field to Partition 1 only (3)
All you have to do is upload the desired image and you’re done

[Tom Elliott]

@Lombard You should not need to change the partition type.

Changing the sys.img.000 to d1p1.img will also not make the image usable due to how the imaging grabs the information.

That said this should work in its current state. I’ll review when I have more time tonight.

[drifter666]

I’m also having the exact same issue. We captured more info just from above the OP picture. See picture below. All our images are single-disk resize and once we upgraded to 1.3.5, they broke. All images were built in the 1.2.0 release. Thanks for the help.

[george1421]

@drifter666 While I have no basis behind this suspicion, In the image definition for students, is the field “Image Manager” (as in your OP picture) set to partclone? If so can you try Partimage instead. Then do a test deploy again.

[drifter666]

Yeah, we did try that and the issue is the same. Did you want me to capture a screen shot of this as well with PartClone selected?

Edit: Sorry, I just reread your comment and realized you asked me to try partimage. That’s what we actually have selected. That’s what the default was set to.

[george1421]

@drifter666 said in No source file passed (writeImage):

Yeah, we did try that and the issue is the same. Did you want me to capture a screen shot of this as well with PartClone selected?

Just for clarity I’m talking about Partimage the name appear similar.

[drifter666]

@george1421 Yeah, I just edited my response for clarity as well. Sorry about that.

[george1421]

@drifter666 I think we are at the point we need the developers to look at this. There was quite a bit of work done between 1.3.4 and 1.3.5 around single disk resizable speed. Something may have got lost in translation.

I know I asked this before, but its still bugging me. You captured these images as “single disk resizeable” in FOG 1.2.0? From what I remember that did not work well at all in FOG 1.2.0. But either way we’ll need the developers to dig into the code. We should have enough screen shots of your system.

For your students image, you might want to post the output of cat /images/Students/d1.original.partitions that is the disc geometry.

[drifter666]

I hear you @george1421 . The resize didn’t work for us for awhile but the technician here that does the image uploads noticed that it was working so he started using it.

If we regather and redeploy the image with single disk resize with version 1.3.5, it works fine.

Here is the output from your cmd.

root@FoG-Deb:/# cat /images/Student/d1.original.partitions
# partition table of /dev/sda
unit: sectors

/dev/sda1 : start=     2048, size=   716800, Id= 7, bootable
/dev/sda2 : start=   718848, size=972513280, Id= 7
/dev/sda3 : start=        0, size=        0, Id= 0
/dev/sda4 : start=        0, size=        0, Id= 0
root@FoG-Deb:/#