Depends on if the capture completed or not. If it completed, the files are gone. If it didn’t complete, then the old image should still work without doing anything special.

What is the latest version of FOG? We need exacts, numbers. The latest version changes daily, sometimes even more often.

In FOG 1.3.x, there is a feature called “Protected” for images, use this for any image you don’t want accidents to happen to:

I would not advise using windows as a storage node though. Not worth the hassle to me.

You can however mount an iSCSI volume as a local disk on the fog server and export that via NFS, because iSCSI is block-level. smb/cifs/nfs is not block level, therefore cannot be re-exported.

@HaRD If you enable hiding the boot menu, this will require entering a key-combination during the “Hide Menu Timeout” window - it will display on-screen something like “Enter key combo for menu”. Once you enter the key combo, you then must authenticate with a valid FOG web-interface user in order to get to the boot menu. This does not affect scheduled/automated operations. See the below picture:

For future readers, the way to recreate this if you accidentally delete /images/dev is:

mkdir -p /images/dev
touch /images/dev/.mntcheck
mkdir -p /images/dev/postinitscripts
echo "#!/bin/bash" > /images/dev/postinitscripts/fog.postinit
echo "## This file serves as a starting point to call your custom pre-imaging/post init loading scripts." >> /images/dev/postinitscripts/fog.postinit
echo "## <SCRIPTNAME> should be changed to the script you're planning to use." >> /images/dev/postinitscripts/fog.postinit
echo "## Syntax of post init scripts are" >> /images/dev/postinitscripts/fog.postinit
echo "#. ${postinitpath}<SCRIPTNAME>" >> /images/dev/postinitscripts/fog.postinit
chown -R fog:root /images
chmod -R 777 /images

It might be load related - if the server is simply too busy to respond at the particular moment FOS is trying to mount, then it’d throw that error. Try turning down your max clients.

@Sebastian-Roth fixed.

To avoid this issue altogether, I’d suggest your next FOG server use Debian or CentOS.

@robtitian16 Is the disk running out of space? What kind of disk is in it? It could be that the FOG Server’s HDD has some bad sectors in the spot where it fails, and it is repeatedly trying to read them but can’t.

@chrispy I think you’ve mixed up UEFI and BIOS. This machine really looks like it’s a UEFI machine, and your DHCP server is telling it to use a BIOS boot file. You’ll probably want to go over this document and that should put you on track: https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence

A bad FTP password for the storage node would cause this. Also if you’re out of space too.

@salted_cashews said in Is a direct upgrade possible in this scenario while retaining all previous configurations and images?:

in the past it was understood a complete rebuilding of the server was necessary to upgrade.

That’s no longer true (and I’m not sure it was ever true). A fog server on any version can be updated to the latest version.

does the integrity of images in this process depend on how the images were stored in regards to the storage type?

No.

Below is a link on how to get the latest FOG version:
https://wiki.fogproject.org/wiki/index.php?title=Getting_FOG

Below is a link to article explaining how to migrating a FOG Server from an old one to a new one if you are interested. While a FOG Server of any version can be upgraded to the latest version - there are times in the past where this has failed - and there are times when your old server (for whatever reason) is not operable/broken and an upgrade can’t be done. This is when you’d do a migration.
https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG

@johnny-t You should mount your /images directory to the 5TB partition in order to utilize that space.

I can test this tomorrow.

Hello @rogalskij

Please post a copy of the fog client’s log file. It’s typically at C:\fog.log unless you set some other path during installation. Posting this log will allow the community to better help you.

Double-check that you’re entering the right IP/name for the fog server during fog client installation.

@fog_newb This is why it is recommend to run FOG in a VM. Simply snapshot before doing stuff like major upgrades. If it goes south, roll back to your snapshot. Also, both 21.04 and 21.10 are not LTS editions. I would generally advise against running FOG on a Non-LTS version of Ubuntu. In addition, the daily installation tests (link in my signature) do not test non-LTS versions of Ubuntu.

I suggest you fall back to 20.04. We have a migration guide:
https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG

@sebastian-roth said in How to disable "password viewing" in the web UI:

Would be interesting to hear what others think about this.

Couple thoughts…

1. You can create an Active Directory service account with pretty limited permissions, only allowing it to join systems to the domain, and use this for FOG. This is something everyone can begin doing right now. This reduces the blast-radius should the credentials that FOG uses became exposed or compromised.

2. In the great majority of enterprise I.T. systems I work in, you can retrieve a credential “ID” (like username or access key) but cannot retrieve the credential “secret” (like a password or secret key). FOG is unique in this area, because the FOG Client needs the complete credential. Though, users should be entirely prevented from retrieving this credential… more on this in points below.

3. Merely concealing the password with the UI, someone who already has access to the FOG server could still potentially use the API to get the password. So, concealing via the UI is just obfuscation and not real security. Concealing via the UI is likely fairly easy to do and would result in less bugs to work out, but this isn’t real security.

4. Best solution in my view is to store the password within the database using reversible encryption. The encryption key should be generated by the FOG Installer, and put into /opt/fog/.fogsettings. The API / web components would then use one of several ways to handle encrypting and decrypting using this key. A quick internet search reveals lots of options:

• https://stackoverflow.com/questions/9262109/simplest-two-way-encryption-using-php
• https://www.educba.com/php-encryption/
• https://www.tonymarston.net/php-mysql/encryption.html

After implementing, the ability to retrieve the password in any form/nature should be secured… which leads into point 5 below.

5. The transport layer between the FOG Client and FOG Server is already encrypted, but should someone call the server endpoint to get the credentials, we don’t want the password to appear plain-text within the server response. I’ve not looked into how this currently works so I’m unsure in this area. But, I’d think the FOG Client would first prove it’s identity with client-based authentication, and after this the FOG Server would provide the password to the FOG Client. Maybe it already works this way? No idea. I’m remembering @Joe-Schmitt talking about this, and how he worked with @Tom-Elliott to solve it… This was a long long time ago though, and my memory of it is super fuzzy.

@Jean-Jacques-Morda As a side thought to all this,

Because you have a 1000/100 mixed environment, maybe you should not group your machines just by model…

Maybe… say… you have a building full of nothing but Dell 9020s.

So… You’d actually have two different groups for those… 9020s with gig, 9020s without gig… Don’t mix computers with different link speeds… keep them separated in their own groups - this should solve your issues.

Keep checking back here…

But I don’t have one… you might have better chances in the SpiceWorks community…

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

You have to turn on a check box somewhere in settings to get the field - firstly.

If you still get all zeros, This is an FTP issue. FOG uses FTP to get the size.