Realize that image names in fog are just text fields used for humans. They have no impact on actual imaging since FOG uses an image ID field.

Image names do have an impact (initially) on the directory where the image will be stored on the disk. But once the initial upload is done, there is no (real) connection between the image name and the location where the image is stored on the disk.

So you can change the image name at any time, changing the image location is a little bit more trouble, but can be done.

To borrow a quote again from Sebastian:

“Could you please run a debug session on this device (WebGUI -> Host -> Basic tasks -> Debug) and run lsblk from the command line of the target computer? What do you get?”

The order reported by lsblk may give us an idea which drive is /dev/sda as well as what this drive thinks it is. If you could take a screen shot of the output and post it here, that would be helpful for the devs.

@hchchchc The FOG appliance is not supported by The FOG Project. That vm was created by a forum member.

With that said, the Distribution OS on the FOG Appliance should release a kernel update to address. I can say for at least centos and Linux Mint, there were kernel updates over the weekend.

Just to save time.

Do not deploy fog 0.27. The current release is 1.2.0 and the devs are working hard on getting 1.3.0 in a stable state. Please if you want to deploy FOG deploy 1.2.0 and then when you are comfortable with 1.2.0 upgrade to the latest trunk version.

I had rough calculations at about 2 hrs of push for 700GB of data with a 6.1GB/min transfer rate (assuming ideal conditions and not being able to compress the 700GB source data much). A lot depends on how fast the target computers can consume the image sent from the FOG server. 700GB image is a huge footprint no matter what.

@treyw00 Changing the “root” password should not have an impact on FOG, since fog has its own two user accounts that is used for FOG. What specifically breaks when you change the root password?

@george1421 This appears to be an issue with the linux kernel with a patch that appears to have been submitted to the kernel devs: https://lkml.org/lkml/2018/2/2/156

The entire thread has a bit more discussion around it.

@developers just be aware there is an issue with the realtek nics that may be resolved when the kernel is updated past 4.15.x

@sarge_212 So for the fog menu info if you press enter a few times, you should end up at a command prompt.

This is GREAT! on the positive side the fog kernel does work for the surface pro 4. Now we need to identify why the hand-off from ipxe to the fog kernel is failing, but at least the devs have a direction!!

Thank you for your help with this.

@eseelke The short answer is, it isn’t going to happen. The WIM files are windows centric. You have to remember that FOG is based on linux, and the engine that writes the image files to disk [i.e. FOS] is linux based. FOG/FOS uses partclone to capture image files, that can be expanded or compress dynamically (to a certain point) based on the size of the target media. I do agree that there would be value in integrating the WIM file format into FOG, but not enough for the developers to spend their time on. FOG has a very fast working solution today.

But, yes, if you want to tweak the golden image you can’t do it from the captured file like you can with a WIM format. The other thing you have to be aware of is that FOG supports more operating systems than just windows. The wim format is (very) windows focused.

[Edit]
Well after the above response I did a little google-fu and found there are linux libraries that support reading and writing wim files. ref: https://wimlib.net/ Briefly looking at the document it appear it is possible. I guess I’ll leave it up to the developers if they are interested, possibly for FOG-too. As for me my initial reaction still stands.

Upgrade to trunk instuctions: https://wiki.fogproject.org/wiki/index.php/Upgrade_to_trunk

You have the process backwards.

Create a .fogsettings file with your desired settings then run the installer script. You may have to do some scripting to get the right values in place. But fog will use that .fogsettings file as a seed file if it exists when the installer script starts.

I can say I have not tried to deploy fog this way, but I know on an upgrade the install script uses this file to know what the user picked when FOG was originally installed. You should be able to us that info to your advantage.

@onepotato Are you running the trunk build of 1.2.0 (a.k.a 1.3.0 beta) or just 1.2.0 stable?

With these memory disk devices, you would be better off upgrading to the trunk build since there has been great strides taken to fix these memory disk devices.

This is going to be a bit of a hackish answer.

Edit the file: /var/www/html/fog/lib/plugins/ldap/pages/ldapmanagementpage.class.php

Goto about line 208 which should look like this:

 $ports = array(389, 636);

Edit it to look like this:

 $ports = array(389, 636, 7389, 7636);

Please understand the recommendation was for you to upgrade to the latest trunk version (i.e. a pre release of version 1.3.0) not to reinstall 1.2.0. Version 1.2.0 does not work well with EFI systems. The upgrade process is outlined in the link provided by Wayne Workman: https://wiki.fogproject.org/wiki/index.php?title=Upgrade_to_trunk

Your error screen shows that the ipxe.efi does not exist on your FOG server. Which is understandable since this file did not exist in FOG 1.2.0. The file snponly.efi is the recommended file for 1.2.0.

@flo FWIW, one of the developers are adding your request to the LDAP plugin. Those should be in the mainstream code on the next release of FOG 1.5.6.

@Psycholiquid Sorry I was in error, this is on the upload side and what I was reading about was actually after the image was deployed you would have to run through some kind of disk fix to basically delete the hibernation file that was in use when the system was captured. I’m still trying to find that article (I read way to much stuff and remember way to little).

@Quazz Here are the edits (not in diff format but george shorthand) that junkhacker recommended to take advantage of new features in pigz and zstd for data dedup systems

vi fog.upload
partclone.imager -aX0 -c -s "$hd" -O /tmp/pigz1 -N -f 1

vi funcs.sh
pigz --rsyncable $PIGZ_COMP < $fifo | split -a 3 -d -b 200m - ${file}. &
pigz --rsyncable $PIGZ_COMP < $fifo > ${file}.000 &

zstdmt --rsyncable -B128 --ultra $PIGZ_COMP < $fifo | split -a 3 -d -b 200m - ${file}. &
zstdmt --rsyncable -B128 --ultra $PIGZ_COMP < $fifo > ${file}.000 &

partclone.$fstype -aX0 -n "Storage Location $storage        , Image name $img" -cs $part -O $fifoname -Nf 1

remove --ignore_crc

The cabs include all possible drivers for this model. What we need the OP to do is spin up a trunk build of FOG, then if the device won’t image we’ll need the OP to get the vendor and device code for the actual installed network adapter from windows. That way we can compare it against what linux has available.

@Quazz You might want to include the nvme package in your build too. Hopefully that will help us solve the issue with the nvme disk swapping. Its not important for this new init testing, but it may be of some use in the future.

Symbol: BR2_PACKAGE_NVME [=n] x x
x x Type : bool x x
x x Prompt: nvme x x
x x Location: x x
x x -> Target packages x x
x x -> Hardware handling x x

You can kind of do what you want with a few restrictions.

Actually I (personally) do recommend that you put the FOG server root partition on one vmdk and the target images on a separate vmdk file. This helps from a performance as well as being able to expand the /images data store. AFAIK you can’t split vmdk files across data stores, so each vmdk file must exist on a single datastore.

What you can do is this.
1 vmdk for the OS and FOG
1 vmdk for /images
and if you use snapins another vmdk for that one. You can scatter the vmdks across your datastores (realize this isn’t best practice). Its best practice to place all vmdk files in a single folder structure. Just because its best practice doesn’t mean you must.

Here is a KB to my recommendation
1 vmdk for Linux OS and FOG
1 vmdk file /opt (which will contain /images and /opt/fog/snapins)
https://forums.fogproject.org/topic/6642/moving-fog-s-images-files-off-the-root-partition