You may be right. For me collecting informations about image creating statistics, doing automation about storage spaces can be done after new images came alive. I can manage it elsewhere, just was wondering if post-upload scripting is possible somehow 🙂

Thanks Tom, it’s version1.20

@Fritch94 details as in what have you tried? What version of fog? Did you try the information in this thread.

@Tom-Elliott said:

change the /etc/apt/sources.list file
Edit the file so all the us.archive and security links are updated to old-releases.

An example?

The OS is Centos 6.7. But I think what was changed works across the linux distros. The wgetrc thing is specific to wget and I know I’ve made that change on FreeBSD as well as various flavors of linux. The environment settings should also be universal.

@Tom-Elliott Working with latest update TY

I can also confirm that version 4866 resolved the issue.

After the SVN update, there is now a new option for placing a plain-text password that will auto-encrypt. The problem was, my encrypted password before the update was placed in the new plain-text field. I just repopulated a new encrypted PW, placed it in the legacy field and that did the trick.

Cheers!
Tim

@giolnl said:

I made some tests with a “forced” configuration (meaning I actually bypassed the GUI of OMV) and everything worked

Not forced, simply a manual configuration. 🙂

The OS doesn’t care what the GUI says. The OS is going to read the /etc/exports file for exports, that’s how it works. 🙂

@Junkhacker I had multiple hard drives I was trying to image at once and once this issue started popping up I actually did switch to re sizable but it was still having that issue strangely.

IMHO this was not related to permissions as you see that pretty much all files and directories already had 777 mask.

Please help us with some more information about your system. FOG version, disk layout, operating system(s) on the client, image type (resizeable?)

This command might help you finding out what kernels you have:

$ file /var/www/fog/service/ipxe/bzImage* /var/www/fog/service/ipxe/bzImage: Linux kernel x86 boot executable bzImage, version 3.15.6 (root@debian64) #1 SMP PREEMPT Fri Jul 18 23:58:44 EDT 2, RO-rootFS, swap_dev 0x5, Normal VGA /var/www/fog/service/ipxe/bzImage32: Linux kernel x86 boot executable bzImage, version 3.15.6 (root@debian64) #1 SMP PREEMPT Fri Jul 18 23:58:56 EDT 2, RO-rootFS, swap_dev 0x5, Normal VGA

This output is on a 1.2.0 test install on my laptop. So I guess 1.2.0 came with 3.15.6

@Wayne-Workman

Model: Whitebox ASrock MB, Core i5 CPU
Winodws 7 Sp1 x64
MBR
Image: I installed from a Microsoft SA Win7sp1x64 downloaded ISO.
When I hit DEL BIOS starts in UEFI Setup Utility.
The SSD was operating in AHCI mode. The new HDD is the same.

@sudburr

I’m not taking images for distribution. I install a machine, install the OS, and install that particular users software. I then take an image of the machine in case there’s a virus or hard drive crash. I haven’t gotten to distributions yet, although that is my next step.

@Tom-Elliott OK. This makes sense. Thank you for the info!

Verified that it is working. Thanks Tom!

https://wiki.fogproject.org/wiki/index.php/Troubleshoot_FTP

Particularly, kernel updates use the FOG_TFTP_FTP_USERNAME and FOG_TFTP_FTP_PASSWORD fields. Check that these match the linux username and password you use for the fog server. Most times this is “fog” and a random password (in 1.2.0 was 6 digits).

@Uncle-Frank SWEET! It was the firewall. I’m now able to boot into Fog. Thank you very very much!!!

I have solved this thread because as @Junkhacker stated, this is fixed in the dev builds as I am not using gzip compression on the page at all any more. If you are worried about the display, please update to Dev.