No source file passed (writeImage)
-
@george1421 Edit with more pictures! Thanks.
-
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 -
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? -
@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.
-
@george1421 Yes, they were (all of them). Im sure resizeable option works… I use it very often.
-
@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.imgI 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.
-
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
-
@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.
-
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.
-
@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.
-
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.
-
@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.
-
@george1421 Yeah, I just edited my response for clarity as well. Sorry about that.
-
@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.partitionsthat is the disc geometry. -
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:/# -
No updates or anything on this? At this point we are regathering our images to deploy them which kinda sucks. But if that’s the solution, we’ll just keep trucking.
-
@drifter666 I had a discussion with one of the developers over this issue late last week, and he recommended updating to 1.4.0-RC1 to fix the disk alignment issue you may be seeing.
-
Cool! I’ll give that a shot and report back once I test it.
-
@drifter666 Please update to 1.4.0-RC3 before you test.
-
It works with 1.4.0-RC3!!! But… doesn’t resize disk after deploy.
