@sebastian-roth: yes, we have a web automation tool that deploys the images nightly.

As for contributing, I am not sure the depth of my knowledge of the project is enough to contribute as of yet. Thanks, I will contribute what I feel I can. You guys are doing great work.

@Sebastian-Roth

Found out the issue. The problem was that the drive was wiped on the machine, (some bad page navigation triggered the link ?node=host&sub=deploy&id=32&type=19 instead of ?node=host&sub=deploy&id=32&type=1 which is a full disk wipe. Note: Even though the Wipe Full Disk wasn’t visible, it was a callable and listed link on the Basic Task page.

So the error presented was due to the partition on the computer being zeroed out and not of the image.

The capture was successful, (only listed Partition 1 to be captured), as I would expect.

Some things to improve the process.

A remote wipe of the disk seems to easy to do, especially when the image Captured is only of one partition.

The error message presented can be less cryptic… maybe a listing of the expected partition table and the existing partition table and a suggestion on where and what to check would help, (currently we only dump the command used and expect the user to figure out what to do next).

I would like to see an ability to check the image integrity, (some checks to indicate if the image is corrupt or not). Not helpful in my case but prevents people from spinning their wheels.

Overall, @Sebastian-Roth thanks for your quick reply and assistance.

We upgrade in July/Aug to 1.4.3. Images were updated as recently as last week.

label: dos
label-id: 0xa67d6c3f
device: /dev/sda
unit: sectors

/dev/sda1 : start=        2048, size=   111908864, type=7, bootable
/dev/sda2 : start=   111910912, size=      921600, type=27
/dev/sda3 : start=   112834560, size=   121604096, type=7

I recently Captured an updated image of a machine, (done this about a dozen times before without issue). This time, however, the image does not restore, I get a No image file(s) found that would match the partition(s) to be restored (perform Restore)

How would I diagnose the issue to recover the image?
Is there a way to get the exact settings the image was made with?

Here are the details…

• Windows 10 machine.
• Machine the image was taken off of now no longer boots, (cannot find a boot device). From a failed Deploy???
• The image logs on the fogserver says the Capture was “Completed”
• I checked the directory and I was able to gunzip the image file without issue, (so I assume the Capture completed).
• There is a possibility when unsetting / setting the image from and to Protected I might have fat fingered another setting, (I am currently cycling other Image Types and Compression values to try to use the image).

Image structure is as follows:

-rwxrwxrwx 1 root root     1048576 Nov 13 13:50 d1.mbr
-rwxrwxrwx 1 root root 16582559265 Nov 13 14:02 d1p1.img
-rwxrwxrwx 1 root root         249 Nov 13 13:50 d1.partitions

Issue is resolved:
Our Fog server is now running and working.

The issue was that after the upgrade the new DHCP configuration was misconfigured. To what I can tell the during the upgrade process the new configurations are read from the .fogsetttings file, (which had some oddly set values, including the wrong outdated DNS server).

Going directly into the /etc/dhcpd/dhcpd.conf file and manually configuring the service worked.

As far as I know the fog account was not changed, (but cannot rule it out). Prior to upgrading, everything was working with the existing permissions. Before the current message there was another message indicating a login failure, (which I did fix with synchronizing the fog password on the system to the one known in the fog settings.

isc-dhcp config is completely different from the one saved from before, (which leads me to thing the new file is from the stock file in the 1.4.3 installation). Just more surprised that what seems to be a “configuration file syntax error” occurred.

Server

• FOG Version: 1.4.3
• OS: Ubuntu 14.04

Client

• Service Version:
• OS:

Description

I just upgrade from 1.2.0 to 1.4.3 and ran into a few issues.

1. Kernel update issues, in the web interface I’ve attempted to get a new kernel and get the following error:
   “Type: 2, File: /var/www/html/fog/lib/fog/fogftp.class.php, Line: 707, Message: ftp_put(): Could not create file., Host: 10.1.39.250, Username: fog”

I’ve added the fog user to the www-data group but there still seems to be permission issues with saving the kernel.

2. DHCP issues After upgrade, the newly placed configuration file seems to have a syntax error:

Jun 23 18:32:38 fog-server dhcpd: /etc/dhcp/dhcpd.conf line 24: expecting numeric value.
Jun 23 18:32:38 fog-server dhcpd: subnet 0.0.0.0 netmask {
Jun 23 18:32:38 fog-server dhcpd: ^
Jun 23 18:32:38 fog-server dhcpd: /etc/dhcp/dhcpd.conf line 26: range declaration not allowed here.
Jun 23 18:32:38 fog-server dhcpd: range
Jun 23 18:32:38 fog-server dhcpd: ^
Jun 23 18:32:38 fog-server dhcpd: /etc/dhcp/dhcpd.conf line 71: expecting a declaration
Jun 23 18:32:38 fog-server dhcpd: }
Jun 23 18:32:38 fog-server dhcpd: ^

I’ve tried to replace the configuration file with the original one, (before the upgrade), which allowed the service to start, but the client still doesn’t pick up and address, (getting the “No DHCP or proxyDHCP” error).

Any help would be appreciated.

Server

• FOG Version: 1.2.0
• OS: Ubuntu 14.04.1 LTS

Client

• Service Version:
• OS:

Description

Planning on switching over to 1.4.2.

How would I install a second instance onto the same machine (we want to have the existing 1.2.0 instance running as a fail over in the event the 1.4.2 set up fails)? The installation instructions doesn’t seem to have any options for multiple instances.

I have already looked at https://wiki.fogproject.org/wiki/index.php?title=Installation#Installation_manuals and https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG but it doesn’t seem to entail anything on having more than one instance on the same system.