No source file passed (writeImage)
-
@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.
-
@alserran Any error messages?
Was the image captured as single disk resizeable?
-
Yes, it’s the same as first screenshot in this post…
-
Any chance this has been resolved? I’m having the exact same issue.
-
@allens What version of FOG are you running?
-
Is this still happening on RC-6?
-
Hi All,
Just upgraded from 1.2.0 to 1.3.5 and am seeing the same symptoms as the OP. It looks like we may be waiting to see if this is solved in 1.4 at the moment. Let me know if there is anything I can provide to help troubleshoot this.
Server: Centos 6
Fog: 1.3.5 -
@rmmadden That issue should have been addressed in 1.4.0RC1. The developers are still a few weeks away from releasing 1.4.0 stable, just be aware.
You might want to upgrade to the 1.4.0RC6 release to ensure that your issue has been resolved before 1.4.0 is officially launched.
