@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.

@george1421 You were right! It worked. I didn’t know that I should run it again to complete the installation, my distraction, I lost about 40 hours to solve something that wasn’t even installed! Thank you very much @george1421. You saved my job.

@quinniedid Ok, looks like this is not due to the picture you used but a general issue with displaying the image on the HP ProBook 445 G2. So far I have not found any hint on other people reporting this issue to iPXE and I would suspect this to be kind of an endeavor to figure out even with the help of iPXE developers. Though you can still report it on github or the forums.

The easier way is just using the workaround that George came up with. Not fancy but way less effort than figuring this one out I suppose.

@sebastian-roth Thank you and @george1421 for your assistance it this matter. It worked great!

Thanks again and keep up the great work!

@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

@bluedude For a longer term solution I would implement the dhcp policies from the document Sebastian provided. That solution will help you when you have a mix of bios and uefi systems on your campus.

BUT for a test right now, replace undionly.kpxe with snponly.efi then try to pxe boot that troubled target computer. Understand when you move away from the bios boot loader the bios systems will fail to pxe boot. But what we are looking at right now is/does snponly.efi resolve uefi booting on this troubled computer. Once you find out then put back the undionly.kpxe file until you can get the dhcp policies setup. I can tell you they do work because I have them setup in my environment.

@sebastian-roth Thank you.

It’s the 1.5.9 version. Not tried with a different browser, only Chrome for the time being.

I’ll dig through the logs but if the page is a redirect I guess that’s where the problem lies.

That’s what I need it! Thank you for your post roro, I was trying to fix it during days!

@vemoya We have seen hosts go pending but that seemed to have been cause by the PowerShell module API calls.

We shall try to figure out if you have entries in the DB that are obviously not correct:

shell> mysql -u fogmaster -p Password: ... mysql> use fog; ... mysql> SELECT hostID,hostName,hostPending FROM hosts WHERE hostID NOT IN (SELECT hmHostID FROM hostMAC); ... mysql> SELECT hostID,hostName,hostPending FROM hosts WHERE hostID NOT IN (SELECT hmHostID FROM hostMAC WHERE hmPrimary = '1'); ... mysql> SELECT hostID,hostName,hostPending FROM hosts WHERE hostPending = '1'; ... mysql> SELECT * FROM tasks WHERE taskStateID IN ('1','2','3'); ....

You find the password for the “fogmaster” database user in /var/www/html/fog/lib/fog/config.class.php. Please run the queries and try to copy&paste all the results here in the forums. Use PuTTy or some other SSH tool to connect to your server so you can copy&paste text.

@will Well the issue is on the target computer side. If the ssd was always disk 0 then it would be easy because in the host definition you could say to deploy the image to /dev/sda but the issue comes when there is two hard drives which one is detected first. The first detected (sata) hard drive is /dev/sda and the second detected hard drive is /dev/sdb This most of the time corresponds to which sata cable is connect to the drive. The cable for drive0 is usually detected as /dev/sda and the cable for drive1 is usually detected as /dev/sdb but only when there is a drive connected to the drive0 cable.

So can you have fog image properly, sure. You just need to tell it on a host by host basis when the ssd is connected to any other cable than the one for drive0.

@sebastian-roth I have not, it seems to have just been that one time.

@epsilon52 First let me say that I 100% agree with Sebastian, but I also know a secret for the Dells.

Using the Dell CCTK (Command and configure tool) you can instruct the bios to pxe boot on the next boot up. This is totally outside the scope of FOG and not something that FOG is capable of, but the cctk tool has the ability to update/change bios settings from inside windows. So using that thought one could create a snapin (FOG deployable program) to run the preinstalled cctk command with the proper parameters to pxe boot on the next reboot only then instruct the computer to reboot. You would deploy that task after you have created an imaging task. I have not personally do this on my campus because I have other rules, but it should be totally possible with snapins and the fog client (I don’t use either in my environment).

As I said before I require the Imaging Tech to sit in front of the computer being imaged so they are 100% certain on what computer they are imaging. Because once in the past with the fully automated process we had an Imaging Tech pick the wrong computer and reimaged (i.e. erased) a VIP’s computer.

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.

@plegrand Groups do not track what snapins are associated to them. It’s just too complex to get right and extremely error prone. Even the things that do track it’s extremely tedious.

Why you ask?

Well, let’s just use some medium numbers to show what I mean.

Let’s say you have a group with 500 hosts in it.

You originally setup the group so all hosts had the same snapins. (Easy to do, just update the group accordingly.)

Now you go to one of the hosts directly, and you remove the snapin from that host. Now you go back to the group, and the group now doesn’t know anything about the snapin on all 500 hosts.

Remember, groups in FOG are not a persistent thing. This is because you can associate a host to multiple groups. Groups, in FOG case, is basically a mechanism to mass update hosts.

For example:

One group to set machines up for specific snapins, but another group that you want to set machines printers, (the machine sets are different, but you might want to cross machiens.)

@olsen Yes that is what I was thinking of. Read over that document and understand the caveats. Look at the fog forum chat bubble for a few more hints to get you a jump start.

@sebastian-roth great, thank you!

@george1421 Oh, thanks for the info. Is there a way to use an AntiVirus to check the HDD?

@george1421 It worked. Thanks !