Posts made by ckasdf

Sorry for the generic title. Didn’t know the best way to succinctly describe the issue. I’m on FOG Server version 1.5.7, and have been using it for a while now. For a lot of that time, it’s been working really well! (Been a minute since I’ve been in the forums, eh?)

Last couple weeks, maybe Corona is affecting FOG too … I have two primary images, and the company has two domains. I am using the persistentgroups plugin so that when I add a computer to group1 or group2, it automatically assigns the appropriate image + AD details. Group1 has always worked really well, and I build most computers using it. I have had the quick registration set to add computers to group1 and deploy.

This week, I had several computers I needed to deploy from group2, so I set it in quick registration, but once the computers are registered I see tasks to deploy images and join AD based on group1 instead. Also, if I cancel the task, correct the group on the website, and initiate a new deploy task, it will work properly.

Something else, which I’m not sure if it’s FOG related or not: within the last two weeks, computers deployed under group2 are getting domain trust issues (The trust relationship between this workstation and the primary domain failed). Generally that means the computer isn’t listed in AD, though at least once I saw that it was. I’m going to do some more testing around that to see what the situation is.

One final note regarding that group plugin mentioned above: I notice that when assigning an existing computer to a new group, it seems to wipe out Product Key information. The Product Key field is blank in the groups, so is the plugin set to overwrite every field, or only fields that aren’t empty? If it’s every field, how difficult would it be to modify the plugin so that empty fields in the group don’t overwrite fields on the host?

So following the link in list item #1, I ran into some issues. I created the fog.patch.man.reg file as directed, copying the quoted text into the file and chmod’ing it to 755. Your step 4 mentions editing fog.postinit, which is a file I don’t have. I wondered if you were missing a step that indicated to run the patch script, so I ran it with # ./fog.patch.man.reg and got the following output:

./fog.patch.man.reg: line 12: /usr/share/fog/lib/funcs.sh: No such file or directory
Testing path for our fixed file at fog.reg.man.fix
./fog.patch.man.reg: line 15: debugPause: command not found
Failed to find file [fog.reg.man.fix] sorry. Copy Failed
./fog.patch.man.reg: line 26: debugPause: command not found

I am thinking that my issue is possibly advice in this forum thread, which suggests that it’s safe to delete the contents of /images/dev/. The thread is from 2016, so perhaps dev gained more purpose than a temporary dumping ground for in-progress captures? I arrived at that thread some time ago, for the same reason as the OP - I was running out of disk space and found out it was because of occasionally-failing captures. Deleted the contents of the folder and everything was good again.

---

Following the link to list item #2, “Using scripts” was a non-starter. I have /opt/fog, but don’t have utils within that directory. Instead, I have log, service, and snapins. I ran find -iname *image* and didn’t find FOGMountBootImage.sh in the results.

I followed the instructions in the “By Hand” section for Version 1.0.0 and up. I had trouble running mount -o loop init{,_32} initmountdir as CentOS didn’t like that command, so I made the assumption that it was trying to mount two directories within initmountdir (init & init_32). I ran that command as such:

mount -o loop init initmountdir/init
mount -o loop init_32 initmountdir/init_32

I then navigated to initmountdir/init{,_32}/bin and changed each fog.man.reg to the file I had created. It sort of worked after I packed everything up, in that things did change, but the registration didn’t act as expected. I entered a hostname as requested, left image ID blank and hit Enter, then it went to a blank line. I waited, but eventually hit Enter again, which then asked if I wanted to associate with groups. After that, when I hit Enter, it dropped to a new blank line, but didn’t continue the form. I possibly have a malformed file (I had a few errors along the way, fixed based on my knowledge of what was wrong). If you’d like, I can attach it. Any thoughts on some of the other issues above?

Also, I was wondering, how would I create a new menu entry, so that my tests show up as a separate item from the primary full registration?

I was reading up at this forum post and the wiki article it linked. I put together a fog.man.reg file using this link provided by @george1421, but I got confused from there. I know the forum post and linked comments mention that the wiki is outdated in some areas, and I think it was suggesting I wouldn’t have to do some of the extra steps that were previously required.

It suggests putting the file into /bin, but there isn’t already an existing file there - is that normal? The wiki also mentions the /tftboot/fog/ directory (and sub-directories) a few times, which I don’t have this one on my FOG server. Should I create it, or am I misunderstanding something?

I seem to remember reading that I have to add the custom entry to the list of the PXE items, but I can’t seem to find how to do that, which I think is the last step I’m missing.

Hey George,

No worries on the delays. Work’s been busy for me too, but today is slow finally.

I realize I messed up how I explained things. I was creating a template host with the same exact name as the group. After not being able to get it working, I tried your example name of TemplHost01 for both a new group and new host. I set the details on the host, added it to the group, and still nothing.

So I just tried again today, and the functionality is working as expected. Curious … I wonder it just needed a little more time. I’ll play with it a bit more and see if everything seems to be good.

Yeah, it definitely seems to be working better now, including with groups/host-templates that I name. I’m not sure what was happening the other day.

One thing which seems like a bug: if I’m in a group and I navigate to Membership to then search for and add additional hosts, it only adds one at a time even if I click the checkbox for multiple.

EDIT: I think I might have figured it out. I’ll get back to this post later, but it seems I glossed over George’s first sentence (which wasn’t quoted in the quote below), which mentioned a plugin to give exactly the usage I need. Once I understood what I was reading, I found his post titled Basic Persistent groups and I will try to follow his instructions to get this working. I’ll let you all know how it goes.

EDIT 2: So I activated the persistent groups plugin, created a host called LOBmulticast, set its image association and AD details, then created a group with the same name of LOBmulticast. The group doesn’t have any of the host’s settings still. Setting them in the host and saving it doesn’t work either. Am I supposed to follow a specific pattern with the name or whatnot?

- - - - -

I’m not sure if I have had the wrong idea about the purpose and use of groups, but I’ve tried using them a couple times with varying levels of success. For example, my company has two different images (and AD domains) used for two separate lines of business.

I tried creating groups named LOB1group and LOB2group, setting image association and Active Directory info, then when registering new hosts associating them with one group or another and skipping questions about image name and whether or not I want to join the domain, but it ends up leaving those bits blank.

Today, I came across a post @george1421 made in Custom Full Host Registration Menu in which he said:

You create a template host and link it with a group. Then when you add a new host to that group, the template host settings get copied to the new host.

This morning, I created 4 new hosts, each with random MAC addresses. “LOB1template” and “test[1-4].” In LOB1template, I set its image association and AD details and then joined it to LOB1group. I noticed the group now had the proper image association, but still didn’t have any AD details filled in. I went ahead and filled those in and saved the group. After that, I added test[1-4]. The group lost its AD details and none of the hosts had image association OR AD details populated in their respective pages. Yesterday, however, I was able to add a bunch of hosts to the group, then apply settings to the group, which populated on the hosts. That doesn’t really seem to make sense though - having to set the group details AFTER adding hosts, since then it’s less automated.

Another question about the template host idea; when I go to perform a multicast, wouldn’t it never start, because it would be waiting on LOB1template to join the multicast, which wouldn’t happen since it’s not real?

Thanks. Perhaps those are less errors, and more just warnings? Is LDAP login possible with the current build? If so, I’ll open a new post requesting help with that.

They do occasionally have different or old BIOS versions, which I update after Windows is finished loading. But they all have the same settings.

I was trying to track down what was going wrong with my LDAP setup, when it was recommended here to check the Apache error log. Navigating there, I found line after line comlpaining about “proxy_fcgi:error - The Timeout specified has expired … etc.”

[Wed Aug 07 12:21:02.678201 2019] [proxy_fcgi:error] [pid 26153] (70007)The timeout specified has expired: [client 172.17.207.117:64205] AH01075: Error dispatching request to :, referer: http://172.17.207.144/fog/management/index.php?node=task&sub=active

Research on that lead me here to check the www-error.log. Opening that file, I get several lines complaining about an illegal offset type in /var/www/html/fog/lib/fog/fogmanagercontroller.class.php on line 296. It also complains about lines 1080, 1081, and 1100 of file /var/www/html/fog/lib/fog/fogcontroller.class.php (mainly about array_diff() and count()), but that’s where my eyes started glossing over. Thoughts on how I can get the errors to stop flowing, so I can better figure out what I need to do to get LDAP rolling?

[05-Aug-2019 12:57:34 America/New_York] PHP Warning: Illegal offset type in /var/www/html/fog/lib/fog/fogmanagercontroller.class.php on line 296

[05-Aug-2019 12:58:38 America/New_York] PHP Warning: Illegal offset type in /var/www/html/fog/lib/fog/fogmanagercontroller.class.php on line 296

[05-Aug-2019 15:15:31 America/New_York] PHP Warning: Illegal offset type in /var/www/html/fog/lib/fog/fogmanagercontroller.class.php on line 296

[06-Aug-2019 08:27:18 America/New_York] PHP Warning: Illegal offset type in /var/www/html/fog/lib/fog/fogmanagercontroller.class.php on line 296

[06-Aug-2019 08:27:58 America/New_York] PHP Warning: Illegal offset type in /var/www/html/fog/lib/fog/fogmanagercontroller.class.php on line 296

[06-Aug-2019 08:28:36 America/New_York] PHP Warning: Illegal offset type in /var/www/html/fog/lib/fog/fogmanagercontroller.class.php on line 296

[07-Aug-2019 09:22:35 America/New_York] PHP Warning: array_diff(): Argument #2 is not an array in /var/www/html/fog/lib/fog/fogcontroller.class.php on line 1080

[07-Aug-2019 09:22:35 America/New_York] PHP Warning: count(): Parameter must be an array or an object that implements Countable in /var/www/html/fog/lib/fog/fogcontroller.class.php on line 1081

[07-Aug-2019 09:22:35 America/New_York] PHP Warning: Invalid argument supplied for foreach() in /var/www/html/fog/lib/fog/fogcontroller.class.php on line 1100

[07-Aug-2019 09:22:35 America/New_York] PHP Warning: array_diff(): Argument #2 is not an array in /var/www/html/fog/lib/fog/fogcontroller.class.php on line 1080

[07-Aug-2019 09:22:35 America/New_York] PHP Warning: count(): Parameter must be an array or an object that implements Countable in /var/www/html/fog/lib/fog/fogcontroller.class.php on line 1081

[07-Aug-2019 09:22:35 America/New_York] PHP Warning: Invalid argument supplied for foreach() in /var/www/html/fog/lib/fog/fogcontroller.class.php on line 1100

[07-Aug-2019 09:22:35 America/New_York] PHP Warning: array_diff(): Argument #2 is not an array in /var/www/html/fog/lib/fog/fogcontroller.class.php on line 1080

[07-Aug-2019 09:22:35 America/New_York] PHP Warning: count(): Parameter must be an array or an object that implements Countable in /var/www/html/fog/lib/fog/fogcontroller.class.php on line 1081

[07-Aug-2019 09:22:35 America/New_York] PHP Warning: Invalid argument supplied for foreach() in /var/www/html/fog/lib/fog/fogcontroller.class.php on line 1100

[07-Aug-2019 09:24:35 America/New_York] PHP Fatal error: Uncaught Error: Call to a member function isValid() on null in /var/www/html/fog/lib/fog/host.class.php:305

Stack trace:

#0 /var/www/html/fog/lib/fog/fogbase.class.php(1814): Host->save()

#1 /var/www/html/fog/lib/client/fogclient.class.php(179): FOGBase->sendData(‘{“error”:"{\"co…’)

#2 /var/www/html/fog/service/register.php(32): FOGClient->__construct(true, false, true, false, true)

#3 {main}

thrown in /var/www/html/fog/lib/fog/host.class.php on line 305

[07-Aug-2019 10:55:14 America/New_York] PHP Warning: Illegal offset type in /var/www/html/fog/lib/fog/fogmanagercontroller.class.php on line 296

[07-Aug-2019 11:01:38 America/New_York] PHP Warning: Illegal offset type in /var/www/html/fog/lib/fog/fogmanagercontroller.class.php on line 296

[07-Aug-2019 12:07:46 America/New_York] PHP Warning: Illegal offset type in /var/www/html/fog/lib/fog/fogmanagercontroller.class.php on line 296

[07-Aug-2019 12:10:49 America/New_York] PHP Warning: Illegal offset type in /var/www/html/fog/lib/fog/fogmanagercontroller.class.php on line 296

[07-Aug-2019 12:11:02 America/New_York] PHP Warning: Illegal offset type in /var/www/html/fog/lib/fog/fogmanagercontroller.class.php on line 296

[07-Aug-2019 12:28:04 America/New_York] PHP Warning: Illegal offset type in /var/www/html/fog/lib/fog/fogmanagercontroller.class.php on line 296

[07-Aug-2019 16:20:10 America/New_York] PHP Warning: Illegal offset type in /var/www/html/fog/lib/fog/fogmanagercontroller.class.php on line 296

[08-Aug-2019 09:07:58 America/New_York] PHP Warning: Illegal offset type in /var/www/html/fog/lib/fog/fogmanagercontroller.class.php on line 296

[08-Aug-2019 09:08:04 America/New_York] PHP Warning: Illegal offset type in /var/www/html/fog/lib/fog/fogmanagercontroller.class.php on line 296

[08-Aug-2019 09:08:11 America/New_York] PHP Warning: Illegal offset type in /var/www/html/fog/lib/fog/fogmanagercontroller.class.php on line 296

[09-Aug-2019 09:34:55 America/New_York] PHP Warning: Illegal offset type in /var/www/html/fog/lib/fog/fogmanagercontroller.class.php on line 296

[09-Aug-2019 16:14:57 America/New_York] PHP Warning: Illegal offset type in /var/www/html/fog/lib/fog/fogmanagercontroller.class.php on line 296

Of course. The model I’ve primarily seen issues with is the Lenovo Thinkcentre M93p. It does seem to be somewhat inconsistent in terms of one working fine while several others experience the described issue. I just tried on a Thinkpad T450 and it worked just fine, though I had one that experienced the issue before.

I have developed UEFI-based Windows images, so I set the computers either to UEFI-only or UEFI-first. I have been preferring the latter in case there’s any weird things we might want to do with Legacy support, but I’m wondering if that may have some negative effect. Your broaching of this subject has me thinking, and I think the next batch of M93p’s I build, I’ll set them to UEFI-only to see if that has any different reaction.

This issue isn’t a terrible, terrible thing for my workflow, but it does disrupt it to a small degree. The issue could technically be fixed if I change the “Error” boot sequence to put the drive before the network. What happens is i switch away on the KVM, the computer detects that a keyboard isn’t connected, and it boots to the network. Long term, I like the idea of keeping this setting, as it will help with future automation plans.

@Sebastian-Roth It’s been a hot minute, but I finally had some time to test this today. I went through the entire list of Host Exit Types from SANBOOT through EXIT and none of them worked for the desktops. Different options reacted differently (one of them put it into a boot loop), but none of them allowed the computer to proceed to Windows upon allowing the PXE menu to auto-select “Boot from hard drive.”

Any other options or things I can try?

I just updated, and it was much easier than I originally anticipated. Thanks again!

Thanks for the insight! I copied one of my build images to a test-copy, then made two changes. I then ran sysprep /generalize /reboot /unattend and allowed the VM to sysprep and reboot to see what happens. I didn’t capture it to run it through FOG, but I imagine the results will be mirrored once I do.

1. I noticed that your unattend file didn’t contain a reference to SetupComplete. Therefore, I edited unattend.xml to remove the <Component> block that contained <AutoLogon> and <LogonCommands> (within which was contained the reference to SetupComplete.cmd).

2. I moved unattend.xml to the Panther directory at your suggestion. When I ran sysprep, I tested it without defining a file, and sure enough, it picked it up with no problem.

After allowing sysprep to do its job, I logged in as the local admin (since I didn’t have FOG to join the domain for me), and no command windows popped up to try running SetupComplete as the local user. SetupComplete didn’t appear in the Startup tab of Task Manager. FOGService was set to Automatic and was Running. In other words, the things that weren’t supposed to be happening no longer were, and the things that were supposed to happen WERE!

 

By the way, slightly on the topic, I know the wiki suggests restarting the computer with a command in SetupComplete after enabling the FOG Client, but Microsoft’s documentation suggests this is a bad idea:

Warning You cannot reboot the system and resume running SetupComplete.cmd. You should not reboot the system by adding a command such as shutdown -r. This will put the system in a bad state.

My SetupComplete file contains two lines:

sc config FOGService start= auto
net start FOGService

It seems to still restart if needed, so maybe the shutdown line can be removed?

 

Thanks to @fry_p, @george1421, and @Sebastian-Roth for your contributions in helping me figure out this strange issue!

True that, George. I was just surprised, as I had a few different USB-to-Ethernet adapters provided to me at work and none of those would work, and many Google searches solidified the suggestion that there were only a few USB Ethernet chipsets (chip manufacturers, chip-somethings, whatever) which were supported by PXE.

The search was made more difficult in that even in the last few years (2016-present) people seem to continue to prefer Legacy booting over UEFI. If I ever decide to get the other device, I’ll let you know how it works so it can also be added to the list, if that’s something you guys are keeping up.

Sorry for the long delay.

You guys are doing beautifully, I appreciate the work you do!

I just pushed a change to the scripts so that the output of the command checking the disk is not suppressed.

Can you provide the github link to the script(s) that were changed so I can check it out? I also need to figure out how to properly update FOG as new releases come, but haven’t had time till this week to sit down and read. I think I spotted some documentation out there on the subject though, so I’ll try to check that out today.

Would be also great to have that in the reports section of the web UI but I fear we don’t have the time to implement that right now.

Totally understand. That suggestion was more to toss on the list of future idea implementations as time allows. BTW, what language(s) is/are used for this? I’ve been interested in learning some software development. Maybe with time I could contribute back to the project.

@george1421

I wanted to update you on my progress related to this question of FOG on new devices without Ethernet. I had purchased this Anker USB C hub with an Ethernet jack for use with my personal laptop, as it doesn’t have an Ethernet jack itself. Curious, I brought it to work and plugged it into a Surface Book I had in inventory at that time, and found that it actually was recognized by UEFI and FOG, so I was able to avoid needing to boot to iPXE USB or similar. I tested it on a few thin Lenovo laptops with USB C (and without Ethernet), and it worked there as well.

This is a Gigabit Ethernet device, so it definitely has some benefits over the older but “trusty” 10/100Mb USB Ethernet devices. I think there’s a device compatibility list somewhere, so if you wanted to add this to the list, you could quote me or do whatever is needed. If you need any additional info on it, let me know.

For what it’s worth, Anker also has a USB 3.0 Type A version, though I’m not sure whether the chipset or what have you is the same, and I haven’t purchased it to try.

@george1421

Sorry for disappearing, work got extra busy. Some time freed up this week though.

was the golden image created from OEM media or did you use the MS VLK media to create this image?

I believe it was VLK media? My manager who gave me the ISO told me it was a volume license image, which he said I should use instead of the one I had downloaded from Microsoft while testing and developing. Is there a way to look inside the ISO after mounting it to determine its licensing?

Was this golden image sysprepp’d?

It was indeed. Installed Windows, pressed CTRL + SHIFT + F3 at the OOBE setup, did all the configurations within Audit Mode, then ran sysprep /generalize /oobe /shutdown /unattend:c:\unattend.xml. Booted the VM to network, captured to FOG, then deployed from there.

I find it strange that setupcomplete.cmd is only running when someone logs in.

I mentioned this in my reply to Sebastian a few minutes ago, but it seems something I did fixed the primary issue: SetupComplete is now running without needing to log in. However, it ALSO runs at every login, instead of quitting, so there’s still something strange afoot.

This should not happen (ever) since there should be no connection with setupcomplete.cmd and the login process.

That’s definitely my understanding, thus the confusion haha.

I could see a case if someone used OEM media where setupcomplete.cmd would not run and was using a first run section of the unattend.xml file to run it where windows would be confused and wait to start the fog service until someone logged in.

I’m pretty sure it’s volume media that I’m using, but as asked to Sebastian, do you know a way to check the ISO to confirm that it’s VLK media? Also, for reference, linked here is a scrubbed copy of the unattend.xml file (though I had to save it as a *.txt file to be allowed to upload it). One thing I noticed while going through is this:

        <LogonCommands>
            <AsynchronousCommand wcm:action="add">
                <RequiresUserInput>false</RequiresUserInput>
                <CommandLine>C:\Windows\Setup\Scripts\SetupComplete.cmd</CommandLine>
                <Description>Script run upon setup completion</Description>
                <Order>1</Order>
            </AsynchronousCommand>
        </LogonCommands>

I was using the Windows System Image Manager (SIM) feature from the Windows Assessment and Deployment Kit (ADK) to create the Unattend file, but perhaps I did something wrong? I would think SetupComplete being inside the LogonCommands block might be what’s causing my problem?

Hopefully this brings us nearer to resolution.

Edit: fixed formatting involved with the attached/linked file.

@Sebastian-Roth

Sorry for not having engaged in this discussion yet

Sorry, my turn to have ghosted the conversation. It’s been rather busy and rushed here, but I finally hit another slow spot. I came in with 20 computers to build last week, got those done, and worked on two more this week. No more to do probably for the next couple days.

What OS version do you use?

I have images for both 1803 and 1809, and I’m slowly moving toward 1903. When I posted this question, it seemed that 1803 had more issues with than 1809, but it may have been something wrong with the image itself.

It’s very interesting it happened to work for one out of three machines!!

Indeed. Seemed like a race condition or something, similar to what you mentioned for timing. At this point, I’ve got it consistently joining the domain without needing to use the local admin account (and I didn’t do anything significant to bring that about, oddly enough). However, SetupComplete still runs at every login, and I see that as a potential issue, if only for the confusion it can sometimes cause users to see the command window pop open and run commands (and in at least one or two cases, the window didn’t go away, resulting in helpdesk tickets being submitted).

But on the other hand “Access denied” is a pretty clear statement as well. Possibly the system account is not ready yet or the windows services framework?!?

I’m definitely not sure what to make of it. My guess is when it’s running successfully the first time (while at the login page for the first time), it’s running with System privileges. Once it tries running when the user signs in, it might be trying to run as the user, who doesn’t have permission to modify services.

For what it’s worth, I ran the test on another disk that was causing me problems, and the screen “lit up like a Christmas tree,” as it were. So my assumption of “no news is good news” seems to have been correct. My suggestions still stand:
A) the “press any key…” interrupt should be on by default instead of needing to edit a couple text files (with 500+ GB drives, who has time to watch in the event the drive isn’t totally rotten, and errors don’t start until half-way through?)
B) it would be cool to be able to store the results in a text file linked from the site somewhere.

I ran a Disk Surface Test (DST) and noticed that it sits at the “* Disk Surface test for /dev/sda” line with no status output. I researched online, found that the status is given at the end of the test, and that it automatically reboots, so I followed the instructions to force a keypress prior to the reboot.

This morning I came in, and the line quoted above finished with “…Done” and then the line below that was “* Task Complete” - no explicit confirmation of pass or fail. I suppose it could be following the Linux way of saying nothing if nothing went wrong?

Several people have commented in the past, and I agree with them - it would be nice to link the test results to the Reports section, as well as some field on the host somewhere, perhaps the top or bottom of the Inventory details (ex: Disk Surface Test: [Passed / Failed]).