Issues importing /images since new fog server build

[jahilton2002]

Now first of i must apologize, it’s been a very long time since i’ve needed to troubleshoot FOG.

I’ve used FOG 1.2.0 with Ubuntu 14.04 for many years without an issue. I’m convinced it’s something i’m overlooking as quite a lot has changed since 1.2.0!

Long story short, our 15 year old fog hardware was on it’s last leg, so i decided now would be the best time to update the latest ubuntu LTS version along with fog. I have done this before with 12.04 and fog 0.98 i think it was.

I have copied the images to the new server into the /images folder.
Recreated the image definitions in fog UI along with the correct case sensitive file names.

This worked on older versions, so i guess i’ve missed something or i can no longer use that method.

I’ve noted that on the new install, “image size” is 0.00iB which i guess isn’t right. I’ve also noticed it takes a very long time to delete the MBR when attenpliting to reimage.

They say pictures speak a 1000 words, so i’ve added some into this post.

Thanks in advance for taking to time to view this.

[Quazz]

I’ve noted that on the new install, “image size” is 0.00iB which i guess isn’t right.

FOG reports the size of the image during capture I believe, so if you got a clean database, then it won’t know about the size of those images.

I’ve also noticed it takes a very long time to delete the MBR when attenpliting to reimage.

This is a Linux kernel bug. I think 4.12 was the last one before this started happening. (you can download those on the Kernel Update page under Settings)

If you still have your old fog server, you can export your image definitions, just a fyi.

Partimage images should still work as far as I know.

What’s the output of ls -lah /images/StonePC1210h110ma on the FOG server?

[Quazz]

@jahilton2002 Try doing

chown -R fog:fog /images

That should fix ownership on the files and hopefully resolve your issue.

[jahilton2002]

Thanks for having a look

[jahilton2002]

@Quazz no joy thanks for your input

[Sebastian Roth]

@jahilton2002 Impressive to see people having used FOG for such a long time! I am wondering if you still have the master machine and could capture a fresh image (please change to partclone as Image Manager before you do). Would save us all a lot of time. But if you can’t, we’ll take a look and see what we can do.

What do you have on screen right before you get that “A warning has been detected!” message? Blue window? Can you take a picture of that or does it move too quickly? Maybe take a video (make sure to rest the camera on a pile of books to get a steady picture)?

As well, please post the contents of the files d1.fixed_size_partitions and d1.original.partitions!

[jahilton2002]

A little update here.

I noticed a screen flash up really quickly, but managed to get a pic of it.

Is referencing “d1.partitions” in “/images/StonePC1210h110ma/”

But that file doesn’t exist.

I’ve added a screenshots and the contents of “StonePC1210h110ma” in the /images location.

Thanks again if you’re able to help.

[jahilton2002]

@Sebastian-Roth Sorry missed your last post.

See screenshots below… also see my previous post about the screen that flashes up very fast.

[Sebastian Roth]

@jahilton2002 Let’s see if we can fix this. Try creating that file by hand with the following content:

# partition table of /dev/sda
unit: sectors

/dev/sda1 : start=     2048, size=   204800, Id= 7, bootable
/dev/sda2 : start=   206848, size=251658240, Id= 7
/dev/sda3 : start=        0, size=        0, Id= 0
/dev/sda4 : start=        0, size=        0, Id= 0

It’s pretty much a copy of the other file BUT sda2 is shrunk. As I am not exactly sure how much data you have in that partition (image file is 40 GB but compressed - could be way more) I calculated a number to match 120 GB. This should be sufficient. It only means that you can’t deploy the image to a disk smaller than 120 GB. As it is a resizable image it should expand to any size disk above 120 GB on deploy. Give it a try.

[jahilton2002]

@Sebastian-Roth Again thanks for your help. But it hasn’t worked, same error

contents of d1.partitions;

[jahilton2002]

@Sebastian-Roth Hi Sebastian.

Just wanted to say thank very much on trying to sort this issue with our old 1.2.0 images on 1.5.4

After talking to my tech team here, we’ve decided to “take the hit”. We have a live golden instance of a windows 7 VM running on Hyper-v that we can recapture with the new instance of fog. We just need to add hardware specific drivers etc.

So not to take anymore of your time and the fact we will be moving to windows 10 anyway very soon. I say thank you very much for all your effort however we are no longer pursuing a fix to this issue.

thank you once again.

[Quazz]

@jahilton2002 I recommend setting your image manager to Partclone ZSTD with compression level 11 for best results. Should save you some time and disk space!

[Sebastian Roth]

@jahilton2002 said in Issues importing /images since new fog server build:

But it hasn’t worked, same error

Which error do you mean? I can’t believe you are seeing the same “Attempting tp expand/fill partitions…awk:…” error.

After talking to my tech team here, we’ve decided to “take the hit”.

Probably a good idea!