Images not deploying after update to 1.3.5

[reprised]

I do have these images as vm’s so i guess i could recapture them (i did this when we upgraded from 1.2 to 1.3). I was just having a look in the image folder and one which is deploying contains just these files

rec.img00
sys.img.00

and the other working one (captured with fog 1.3.3) has these:

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

In the folders of the 3 images that have errors, there are extra files:

rec.img.000
sys.img.00
d1.fixed_size_partitions
d1.original.fstypes
d1.original.partitions
d1.original.swapuuids

[george1421]

@reprised said in Images not deploying after update to 1.3.5:

rec.img.000
sys.img.00
d1.fixed_size_partitions
d1.original.fstypes
d1.original.partitions
d1.original.swapuuids

In the past few days we are seeing an uptick in reporting that FOG 1.3.5 and 1.4.0-RC1 are having an issue deploying images that have the above image structures. From other posts images captured created with FOG 1.2.0 seem to be the most problematic. The developers are currently looking into why this is happening.

[Foglalt]

I think I will check this topic often, as it is a really disturbing thing and need to find good way to solve. Especially that we have many images and recapturing them on version changes is closer to impossible (take hours actually) that if here we come to a problem solving trick that would be good. btw the less problematic is if images can be converted somehow.

I think we can even accept tricks to make this steps rather than having 2 working sets of fog to retake images before and after such changes

[george1421]

@Foglalt No need to reimage anything. The developers are aware of this issue. At this point we are trying to collect as much info as possible to feed to them.

Please stand by I hope to hear something soon.

[reprised]

@george1421

Thanks, if you require any further info from our fog server then let me know

[george1421]

@reprised I just had a chat session with one of the developers. The recommendation is for you to update to 1.4.0-RC1

# Change to where your local git repository is:
cd /opt/fogproject
git checkout dev-branch
git pull
cd bin
./installfog.sh -y

[reprised]

I’ve found a work around instead of upgrading you can remove the 4 extra files after backing them up of course:

d1.fixed_size_partitions
d1.original.fstypes
d1.original.partitions
d1.original.swapuuids

Leave the image files; i have these 2 files:

rec.img.000
sys.img.000

I tested this with all of the images that were not working and they now deploy.

[Tom Elliott]

@reprised Glad you have fixed it, but the reason we asked you to update is because 1.4.0 will be released soon and the problem we believe is addressed. Knowing if things are working properly before release is more important.

[ale.com]

@tom-elliott I know that this topic is quite old, but I’ve the same issue on a freshly installed 1.4.4

Images has been captured with 1.2.0 (installed on an ubuntu 12.04)
1.4.4 has been installed on a new ubuntu 16.04 and /images folder copied from the old server to the new one

workaround proposed by @reprised doesn’t work for me (I don’t have rec.img.00 and sys.img.000)

should I deploy from old server and recapture every image or there’s another solution?

thank you!

[ale.com]

@tom-elliott wait, don’t waste your time with my previous post. It seems that something gone wrong during /images folder copy. I’m checking it. sorry.

[george1421]

@ale-com said in Images not deploying after update to 1.3.5:

should I deploy from old server and recapture every image or there’s another solution?

Moderator note: You really should start your own thread because your conditions may not exactly match the OPs post.

But to your question, if you have the capabilities to do so, you will end up with a better solution. FOG 1.4.4 has a newer and faster compression engine called zstd. You can only take full advantage of this newer engine if you capture using it. Don’t forget to set your image format to partclone zstd (the default is still partclone gzip)

[ale.com]

@george1421 I’m sorry, it really seemed (to me) that was the same issue (exactly same errors deploying an old image with a >1.3.x)

Now I can confirm that it was an issue copying the /images folder.

Thank you for your suggestion on zstd, I’ll change the compression method at the the next capture.