@emreonder said in Need to install Fog Server. Urgent remote support needed.:

nomater all the options i try with the Host Bios Exit Type or Host EFI Exit Type ( i guess i tried all the combinations) but never passes this step.

Ok the first thing we need to know is the gigabyte mobo in bios or uefi mode. Knowing that then you can focus on the right Host Exit type.

The default for bios exit type is SANBOOT. That works 95% of the time. For the UEFI exit type that is typically rEFInd.

So if you have a uefi type firmware and rEFInd hangs on exit there are a few things you can try with refind to make it work. The first thing I think I would have you do is update a few settings in the refind.conf file to see if adjust refind to locate your boot media.

@Oleg I hope you can read patch/diff information. Here are the changes you need to make to /var/www/html/fog/lib/pages/hostmanagementpage.class.php to add the “System Product” column to the host list output - this is for FOG 1.5.9 and would probably work in 1.5.8 just as well:

--- fogproject-master/packages/web/lib/pages/hostmanagementpage.class.php 2020-09-14 01:00:12.000000000 +0200 +++ /var/www/html/fog/lib/pages/hostmanagementpage.class.php 2020-12-19 17:03:24.225580767 +0100 @@ -175,7 +175,8 @@ _('Host'), _('Imaged'), _('Task'), - _('Assigned Image') + _('Assigned Image'), + _('System Product') ); $this->templates = array( '<i class="icon fa fa-question hand"></i>', @@ -223,7 +224,9 @@ _('Goto task list') ), '<small><a href="?node=image&sub=edit&id=${image_id}">' - . '${image_name}</a></small>' + . '${image_name}</a></small>', + '${inventory}' + ); unset($up, $down, $mc); $this->attributes = array( @@ -259,6 +262,9 @@ ), array( 'width' => 20 + ), + array( + 'width' => 120 ) ); /** @@ -281,6 +287,7 @@ 'image_id' => $Host->imageID, 'image_name' => $Host->imagename, 'pingstatus' => $Host->pingstatus, + 'inventory' => $Host->inventory->sysproduct, ); unset($Host); };

I suggest you keep a copy of this information somewhere so you can apply the changes whenever you update to a new version of FOG.

@sebastian-roth Yes resolved.

@DJslimD1k Yes there are two ways of achieving this. The first one is kind of static where you modify the init.xz file. You need to re-do the modification as soon as you update to a new version of FOG. Find instructions on how to do that in the wiki: https://wiki.fogproject.org/wiki/index.php?title=Modifying_the_Init_Image

But as you seem to use the latest dev-branch version (great!) I would suggest you use the more dynamic way of “patching” the inits on the fly while it boots up. George posted instructions on this in the forums: https://forums.fogproject.org/topic/13500/dynamically-patching-fos-using-a-postinit-script

In your case you want to edit fog.reg.man.fix and delete lines 286-294 as well as 250-268 (note I am listing the lines numbers in reverse because when you start deleting in line 250 the later line numbers will change).

As well I suggest you keep an eye on the commit history of this particular file on github (https://github.com/FOGProject/fos/commits/master/Buildroot/board/FOG/FOS/rootfs_overlay/bin/fog.man.reg) - whenever we commit a change I suggest you re-download and modify your fog.reg.man.fix again. Last change was March 2018, so changes to this file are kind of rare but you never know.

@boriquaboy115 I would like to say yes for LUKS encryption. I created a one off kernel for that a while ago for a specific use case.

Part 2: LVM isn’t a problem for FOG, it just can’t resize the disk image, so you can only deploy it to the same size disk or larger if you have an LVM partition.

ref: https://forums.fogproject.org/topic/13845/error-decrypting-luks-partition-prior-to-capture-imaging/8

Found the answer:

The master server polls the storage node web server. (/fog/status/bandwidth.php?dev=eth-device-name)

If the master server is HTTPS enabled, the storage nodes must expose the APIs in HTTPS too.

Hi, I have solved the problem. I have followed an article which has helped me to solve the problem I had, right now FOG is able to answer both networks without any problem.

I leave the article here: https://jensd.be/468/linux/two-network-cards-rp_filter

Thanks for everything!

@bmick10 said in Deleting Hosts:

If I delete a device that is still in production on the network. It will not remove from domain or lose connection?

Correct. The only impact to the target computer is that if the fog client is installed on the target computer it will no longer get instructions from the FOG server. The FOG Client will be abandoned with no instructions.

If I have a machine named ittech20 and remove that from database when I restart in pxe will the computer still be named ittech20.

Yes the computer will remain untouched. The only thing you will notice is that in the fog iPXE menu the computer will appear as unregistered.

So if I delete all of them since the machine still has service running on will it talk back to server and sync to database?

If the FOG Client is installed on the machine but they are no longer in the database the FOG Client should reregister the computer. Now that I think about it. BUT they will be registered in a pending state and must be approved before you can work with them in the FOG Gui. Its been a while since I did this part so its not as clear in my mind. But they should go into the database again in a pending state.

@george1421 Thanks for your reply.

Out of all the replies on updating FOG all of them refer to the git method, and never a clear answer on the tarball/zip method. So thank you for that. Looks like my original install my boss did was from the tarball so I’ll stick to that for now. Thanks again!

@sjensen Just as a precaution - make sure you have a backup copy of all your important data from this system. I won’t be made liable for any steps you take!

So let’s take a look at the whole process of resizing which involves several “layers” - see below.

In the output of pvscan we see that the physical volume on /dev/sda3 is 400 GB in size and has 100 GB free/not in use. So gparted has extended the partition but not the physical volume (in LVM terms). To do that run:

pvresize /dev/sda3

The next step is to tell the logical volume (LV) to use that new space:

lvextend -l+100%FREE /dev/FOGServer-vg/root

As a final step you need to extend the filesystem.

resize2fs /dev/FOGserver-vg/root

Finally check the partition size in the output of df -h.

As far as I know, if you use Big Sur Beta to create a machine, you don’t need to do any other specific settings.
If you don’t know much about it, you can take a look at this tutorial.
It will tell you what you need to do .
I did what it said before,the methods it provides are all helpful,i use method one, which is fast and simple, without me doing too many useless things.

@sjensen FOG 1.5.0 is years old and I can’t remember if multicast worked perfectly fine in that version or if there was an itch with that in 1.5.0.

@george1421 Obrigado

It’s been a few days and I just wanted to thank everyone for the replies. I am giving the scripting a whack and will report back if I make some progress with it.

@ddavis The MAC address is still used as unique identifier by FOG as being the most reliable. Changing that would mean working with the code. Feel free to work on this considering all the things mentioned on github: https://github.com/FOGProject/fogproject/issues/198

The question is what your goal is in the end. Should those devices be imaged and then handed out and never some back? Or do they stay in your network and re-imaged from time to time? If so which kind of network connection will they use in the future?

There are two other routes you can look into:

Register the device with the the USB adapters MAC address and let it do the imaging. Rename the host manually or by OOBE. Install the fog-client service and enable that after deployment so it will automatically register other MAC addresses like wireless, approve those. Some USB adapters have the capability to pass-through the MAC address. This feature allows the MAC address of the native ethernet network device on the system to be used for imaging. Depends on the hardware you have.

@sebastian-roth Thank you! I am going to give this a shot.

@sebastian-roth It’s beautiful!
Thanks for figuring that out!

@chris-whiteley said in API Help:

The only thing I can’t figure out is how to make that host be associated with a SnapinID. For instance, I want it to be associated with a SnapinID of 1. How can I do that?

While I haven’t tested lately I would think you should be able to create a snapin association like this:

curl -X PUT -d '{"snapins":[1]}' http://x.x.x.x/fog/host/33/edit

Assuming the host you want to associate the snapin (ID 1) to has host ID 33. Don’t forget the API tokens in the call.

@kevinnew22 You need to explain what sda and sdb in your case are. Both are named “virtual disk”. Which one is iSCSI and what is the other one based on?

When you want to extend your image space it’s usually best to mount the /images folder on a separate disk. So in this case you would create a partition on sdb, format with a filesystem and move your images over to that new disk - e.g.:

use at your own risk!!

parted -s /dev/sdb mkpart primary 0% 100% mkfs.ext4 /dev/sdb1 mkdir /images_new mount /dev/sdb1 /images_new/ mv /images/* /images_new/ mv /images/.mntcheck /images_new/ umount /images_new/ rmdir /images_new/ mount /dev/sdb1 /images/

As well edit /etc/fstab to mount this nuew partition on boot up as well.