Posts made by Zer0Cool

@scojo said in New Fog Install, No Fog on Boot:

I am unable to get the FOG menu to show up.

Can you clarify this in specific terms, what does happen is more helpful than what doesnt happen.

• Does DHCP assign an IP?
• Does iPXE pull down the NBP file?
• Do you get an error?
• Does the computer do something after not presenting the menu? (beep, reboot, show something else, power off, etc)
• Do you have SELinux set to permissive mode?

What machines are you trying (make/model), what GPU are they using, how is the monitor connected (HDMI, DP, DVI, etc)?

@george1421 said in New Fog Install, No Fog on Boot:

Remember the prerequsites are to disable the OS’ firewall

I dont know about for other OS’s, but not CentOS 7. The instructions provide directions for opening the proper ports/services.

@wayne-workman I have gone through both and unless I am missing something neither speaks to how often they run or when really.

As far as I can tell after testing and researching on google they appear to run after the machine boots and the typical FOG client post deployment events happen (domain join, Windows activation, etc) if you have added them to the host/group. They also appear to run once.

As far as I can tell, when using multiple snapins for a host/group they run in order by name (of the snapin). So naming conventions like; 1-snapin, 2-snapin, 3-snapin, etc…can allow one to determine the order they run in.

I haven’t found any evidence of having snapins run on a schedule, so it seems they run post deployment 1 time or they can be run manually at any point post deployment.

I would also be interested in knowing what permissions the FOG client runs these tasks with, be it the currently logged in account, a system account, elevated admin, etc. I think I glanced over this in the documentation so I will re-check it. Basically I am wondering if a local/ad account needs admin to run the post image FOG client routine and any snapins (like mine deleting a user account). Ex: the ad account I assigned FOG is not an admin, but the local account is, so if I got my batch file/snapin to login to the ad account and then try and delete the local user, would it fail?

Thanks

@quinniedid said in Possible to Use Snapin Post Image to Join Domain?:

Our process is we have a domain account already setup on the “golden” image. All we do to prepare the OS for being imaged is simply remove it from the domain and pull the image.

My process is basically this. However my machines need some coxing to pull gpupdate right away, idk why just how it is.

I am aware of being able to login local with \username or computer\username, but thanks you for offering the info as well.

Ive got FOG client setup now and it is joining domain, changing host name and activating Windows. I have created a batch file snapin that deletes the local account and does gpupdate /force then reboots.

However since its logged in on the local account when deleting the account it does leave a small remnant behind. I have confirmed the same batch file properly clears out the local user when using a domain account instead.

So the domain user I setup and have in FOG to join the domain with doesnt actually get logged into, just used as the account to join the machine to domain. Any way to get FOG to login to the domain account instead of using the local account?

I am now researching adding the login as part of my snapin but wondering if I missing something more simple than this. Thanks

FOG 1.5.3
CentOS 7.5

I have created a snapin that is a batch file. I have 3 hosts placed in a group. I have within the group went to snapins and added the snapin as an available snapin. I can on each of the 3 hosts in the FOG gui see that they have the snapin as available.

So my question is, do snapins run automatically, do they need to be run manually, are they run a single time or run on some sort of schedule?

The snapin/batch file I created I want to only run one time on this group, essentially right after deploying to them. I wasnt sure if the snapin was kicked off by the deployment process automatically, in which case does the FOG client do things like domain join and change hostname prior to running my snapin?

Otherwise I presume I manually run the snapin on the host/group from the tasks menu?

Any clarification on if its automated or manual, 1 time or repeating would be helpful. Thanks

@joe-gill I am working through it now, basically its the same. The variations come from differences in the environments and goals people have.

I have a Windows Server 2016 box with WDS and WSUS roles (only as they are needed for my process, I dont functionally use them directly) with ADK installed.

I have a powershell script that take the install.wim from my Windows OS (7,8,10,server 2008, 2012, 2016) and patches it with all the relevant updates from a WSUS server on the network (so installing Windows 7 or server 2012 doesnt require 1,000 updates out of the box). I use manual commands in dism to add drivers to the image if its for a specific set of machines (like USB 3, NIC drivers or printers).

I then rebuild an ISO from that install.wim. I dump those ISO contents onto my FOG server as the sources to install from via iPXE.

I also on the 2016 server have a batch file I use to create the winpe stuff for each Windows OS. I also have an unattend file for sysprep with an entry in it to run SetupComplete.cmd to enable the FOG service as mentioned in OP.

I install via FOG/PXE to a machine to create the initial image, add the FOG client, disable its service and capture the image.

When deploying the image, first boot runs the batch file and enables the FOG client thus joining the machine to AD, changes the host name and activates Windows.

I created a batch snapin to delete the local user and its profile folder that was created by the unattend file, push gpupdate /force and reboot. So after the images deploy, having all the machines needed in the same group in FOG i just push the snapin to the group and then they are done.

I probably do somewhat less automation than the OP but its a lot better than a month ago when I had to do most of the post deployment stuff manually. Hope this helps

@john-l-clark If your image was from a machine that was in BIOS mode and the media to initially install was BIOS media as well, then the image is being deployed to the HDD/SSD with BIOS partitioning and not UEFI boot partitions. In this case the UEFI/BIOS would not consider it a UEFI bootable device (as it has no UEFI boot partition). Presuming your image is whole disk and not a single partition.

I have seen posts around about converting images that are BIOS to UEFI, but didnt pay much attention to them. If the process of setting up that machine with a new image isnt too much of a burden, that may be your best bet. Fresh install OS with UEFI settings/media, setup what you need and capture.

Hope this helps

Looking like my issues with FOG client and domain join may be due to the computer being registered to the domain already and/or with a different AD account. When I tried manually I got an error message that seemed to indicate this.

I am going to remove the machine from AD server side, reboot and see if it can join then.

EDIT: it now joined domain, looks like a Windows issue in which it cant join (or re-join) domain using the same host name but a different AD account (initially).

I removed the machine entry from AD and rebooted the machine, FOG client asked for a reboot and it had joined the domain.

Oddly enough, logged into local account but domain joined, I was anticipating it either logging into or prompting to log into the domain account.

In any case I logged off local user and logged into domain user and all is good it seems.

I may be able to then use FOG client to change machine host name, activate Windows and join domain pretty easily and then maybe use a snapin to delete local user, clear out the unattend file and run gpupdate /force.

I guess if I really had to, I could also remove FOG client after the staging process is complete but I may be able to keep it on systems after all.

Ok, so I am testing out FOG client, as I may be able to use it after all.

I so far have an image with it installed and disabled, then have the SetupComplete.cmd to start the service (basically with the 2 lines the wiki has for it).

I have in FOG for the host the Windows 7 product key, host names (obviously) and the domain, user and password.

I believe I have set everything required to pass that along via the FOG client after deployment, but only 2/3 take effect.

After booting Windows 7 post deployment, the machine reboots several times whereas it did not prior (without FOG client) and then I will get a notification from FOG client that it needs to reboot/shutdown the machine. I allow it to and it reboots.

At this stage it has changed the hostname properly and activated Windows, but did not join the domain.

I am wondering if this is because my unattend creates a local account and auto logs into it on first boot (after which reboots require login). Even rebooting manually after all of the above doesnt seem to have any effect. Leaving it sit for ~30 minutes doesnt see any action on joining the domain either.

Trying to log out I dont have any option to log in as another user, so it seems to only be allowing local account login.

Any advise/help for getting it to doamin join would be great. Thanks

@quinniedid Interesting approach, but some of the stuff I install requires a domain connection. I actually do image it off domain. So Sysprep doesnt properly leave domain and fails. I have found I have to leave domain, delete domain account/folder from the machine prior to sysprep. I then image the machine and have so far deployed it, re-join domain, etc. I am hoping to be able to change the post deployment so that joining the domain again isnt a manual process. I also agree, Windows 7 seems to be very finicky where Windows 10 seems better able to handle sysprep.

@george1421 Ill check it out, thanks for the info!

@george1421 Would you mind sharing your unattend.xml (sanitized of course) or whatever script you are using to domain join (or both lol)?

I couldnt get it to work when I tried, and at the time I gave up and just dealt with needing to do it manually.

@wayne-workman Ah ok, makes sense. I then presume also that if I could use the FOG client many parts of my question wouldnt require a snapin as the client can change hostname, domain join and activate Windows right?

My fallback was to have sysprep run a batch file on first login, seems I may have to go that direction.

Thanks

FOG 1.5.3
CentOS 7.5.1803

Client: Windows 7 Pro x64 based image.

Note: Installing the FOG client on hosts isn’t going to be an option for me unfortunately.

I currently have an image I use across identical machines (Dell Precision 3620’s) that is Windows 7 with drivers, updates and some programs installed. I then take it off the domain (and delete ad user from machine) and sysprep it oobe/shutdown (sysprep fails with it domain joined, leaving domain was only solution I found). After sysprep/shutdown I capture the image.

My unattend file really doesnt do anything. It only serves to allow sysprep to do what it needs. I pass a generic CD Key (official MS install key, which doesnt activate), give it a local user named ‘Temp’ and provide it a password for said local account.

My typical process when deploying the image is to change the machine name, domain join (I setup an AD account just for this), reboot, delete temp local account, delete the unattend file, run gpupdate /force and logout/in (or reboot) and then activate Windows with a valid key. I do this all manually as of now.

I am just starting to look at various forms of automation (previously I just wanted to confirm manual basics worked before trying to automate). I am wondering if its feasible to use a Snapin for this purpose?

Could I do a .bat file as a snapin to have it run the batch file first boot to take care of the manual steps I mentioned? I am unclear if Snapins are meant to be run multiple times on a machine or 1 time use like I need.

I have been reviewing documentation but most examples appear to be for installing programs, so not exactly an apples to apples comparison. Any input would be great. Thanks

@quazz Alright that appears to work. symlinks in /var/www/html are working. Thank you!

@quazz said in HTTP Redirects After Upgrade 1.5.2 to 1.5.3:

@zer0cool I think it will redirect anything with url/fog so try going one directory higher.

Since I appear to be unable to mark moderators responses as the solution I have quoted your solution and will mark this solved. Thanks!

@quazz Ah ok I will give that a shot. Rolling back to my snapshot of 1.5.3 now, ill give it a shot and report back. Thanks

@quazz Not sure I follow,

In 1.5.2:
10.0.0.10/fog/os - works

in 1.5.3:
10.0.0.10/fog/os - redirects to management

Are you saying add an additional folder or remove one?

IE:
A) 10.0.0.10/os
or
B) 10.0.0.10/fog/subdir/os

@quazz Yea I took a peak at that change and figured it may be it. However, Apache should be able to find these directories, so I am not sure why it redirects.

I cant find any reason that the 3 folders I symlinked to wouldnt be seen by Apache and be valid. Just for kicks I put gibberish after url/fog and got the exact same result as when trying to get to one of my valid urls (symlinks).

I just cant put my finger on the missing piece here. Its not SELinux, nor firewall. I reverted to 1.5.2 (from snapshot) and permissions are the same. It doesnt appear I altered the httpd.conf or any other httpd related conf file to make this work in 1.5.2.

In 1.5.2 it seems it was as simple as create symlinks, SELinux = permissive, firewall allowing http, restarting httpd and good to go. In 1.5.3 it would seem something in the confgs like the change you point out has caused a problem in which my symlinks are not able to be followed causing it to redirect.

For me its kind of a big deal as all of my iPXE stuff is using http, specifically these symlinks (as http is much faster than tftp in my testing). Without it working I would have to spend hours re-doing my menus, config files, etc.

I can stay on 1.5.2 for now, but thats not a long term fix. Any help would be great. Thanks

FOG 1.5.3
CentOS 7.5.1803

Did the upgrade via git. Seemingly everything went ok.

I now realized I lost my symlinks in the /var/www/html/fog directory. So what I had done is place a directory in tftpboot called ‘os’. In this I placed sub-directories for each OS’s installation files. I also have a folder /pxeshare which is a samba share, in which I have a folder for ISO’s and scripts, /pxeshare/isos and /pxeshare/scripts.

I wanted these to also be available via http but to not duplicate the information, so i used ln -s to create sym links within /var/www/html/fog to each of those folders. IE:

/var/www/html/fog/os
/var/www/html/fog/isos
/var/www/html/fog/scrips

This enabled me to access these via url/fog/os for example in the browser and/or my iPXE menu entries/installations via http.

After the update these symlinks were deleted. No big deal I went back and created them again. Confirmed that httpd is running, confirmed my firewall-cmd rules are still in place, restarted the httpd service, reloaded the fire wall, confirmed/set SELinux to permissive and have even rebooted multiple times.

When I try to navigate to url/fog/os now, it instead redirects me back to url/fog/management/index.php.

I have glanced over my httpd.conf and nothing stands out as being something I had to alter before. Did something change in the way FOG works with http to cause it to redirect like this?

I am sure I am missing something silly, I just cant see it. I will keep digging but any insight into resolving this would be great. Worst comes to worst I may simply roll back to a snapshot prior to the update and check more conf files to see if I did alter something to make this work.

Thanks

@george1421 I am pretty sure it comes down to the Nvidia NVS 310 GPU’s for me. It may even come down to the specific make/model of them, but all of my Dell Precision T3620’s have them. The i7-6700 in each also has built in Intel iGPU.

The NVS 310 has 2x DP connections, and when connected to either the UEFI menu renders scrambled and vertically smashed. Switching to a motherboard output, using the iGPU, it renders as expected. Come to think of it, it was also scrambling and condensing the ESXi installer…at the time I presumed it was ESXi, but now I am certain it was the specific GPU.

You may even recall me “complaining” that the text size/resolution was different in UEFI vs BIOS. This is not the case using the iGPU for me. Now BIOS and UEFI are identical in size and format.

@george1421 said in iPXE Menu Colors Help:

I know messing with the iPXE colors is a bit mind blowing

Its especially hard when half the settings dont change anything because your GPU/background removal has rendered them moot (and your not aware of it). For me the problem was even with documentation and going through it meticulously as soon as I would start to wrap my head around it I would make a change and nothing would happen (or something other than expected), which would lead to presuming I didnt have my head around it. For example setting rgb either has no effect or results in transparency or a default color when in fallback mode. So imagine setting an rgb value to what you know is blue and getting white instead. Makes you question things lol.

After switching GPU’s and getting it to render in normal mode and not fallback, I have sorted out the formatting and added my own background.

Like you I have the multi-gpu setting on auto, have been using BIOS 2.6.1 and 2.8.1 (thats how long I have been working on this lol) and had leading up to this a single monitor connected DP to the NVS 310 (now the iGPU motherboard DP port).

To be honest, if it was my personal computer I would likely look into firmware updates for the NVS…but in my case I am happy just using the iGPU for staging. Thanks for the input

So I am pretty mad at Dell/Nvidia right now. I think the console command using x/y resolution works. The scrambled screen appears to be an issue with the GPU. Not a FOG issue (I think) but a Nvidia or iPXE problem?

When the monitor is connected to the Nvidia NVS 310 the UEFI menu is scrambled. However switching the monitor to be connected to the onboard (CPU built in Intel GPU) then it boots UEFI with the expected colors with no problem.

So I think the line "console --x 1024 --y 768 --left 100 --right 80 && goto console_set",

In place of the default using the default that loads the background has resolved the problems for me, letting me use the graphical console with access to rgb colors.

EDIT: and switching to the iGPU…also resolves the issue with loading the background in UEFI. I changed the php back to the default and UEFI now boots with the background.

Moral of the story…it appears the GPU can have drastic effects on the iPXE menus loading at all/correctly.

If anyone finds a work around let me know, otherwise I just have to note on my end that these machines with this GPU need to have the monitor connected to the iGPU while pxe booting.

@Quazz @Tom-Elliott @george1421 I hope you guys dont mind me directing this post towards you guys, but you have proven knowledgeable and I am sure one of you most likely can solve this.

I reverted my changed in the web gui under iPXE General Settings to the default colors/pairings.

I have made some “discoveries” as to why the formatting is giving me trouble. The below points led me to this:

• Out of the box, the iPXE menu will load fine in BIOS but not in UEFI due to the background image. Removing the “bg.png” from the web gui under iPXE General configuration and leaving it blank then allows booting in BIOS or UEFI.
• The above results in red text, black background. It is my understanding this is due to the “fallback” colors/pairings being used.
• The fallback colors are very limited, seemingly not allowing for using rgb defined colors.

With the above, and looking at the boot.php in the browser this line stood out to me:

console --picture url/ --left 100 --right 80 && goto console_set || goto alt_console

As I understand it, console is trying to load nothing as the picture, failing thus evoking goto alt_console, essentially the fallback settings. So by removing the image that was preventing UEFI booting I have forced it into booting in this fallback mode.

That has led me trying to alter /var/www/html/fog/lib/fog/bootmenu.class.php at roughly line 1905:

default

array(
 'goto MENU',
 ':get_console',
 "console --picture $this->_booturl/ipxe/$bgfile --left 100 "
 . "--right 80 && goto console_set || goto alt_console",
)

What I have tried:

• "console && goto console_set", // this would load BIOS/UEFI with all white text, black background. Thus not following any color settings.
• "console --x 1024 --y 768 --left 100 --right 80 && goto console_set", //this loads with the expected colors in BIOS (blues and whites) but loads messed up in UEFI (colors are there, but its vertically smashed taking up maybe half the screen vertically and all scrambled). In other words you can tell its the menu, with the expected colors but you cannot make anything out in a legible way. Note: other resolutions like 640x480 would cause UEFI to reboot, similar to with bg.
• same as above but without offset left/right. Wont boot (system beeps and reboots while ipxe loads menu)

So long story short, it seems the root of my issues are the background image and console command in the menu. Leaving the image out allows booting to the menu but only in fallback. Trying to alter the console command to not load a background leads to partially working results.

Any help would be great. In the mean time I am going to test UEFI boot with the resolution parameters to make sure its not an issue specific to the machine.

I guess my goal here is simply to boot iPXE UEFI or BIOS to the “graphical” console/menu, which should allow me to apply a wider range of colors via rgb to the text on the menu.

Thanks

@tom-elliott I expected that may be the case. I did not mean to imply any issue, just observations in case someone is impatient (I almost tried a reboot while it was on #2).

Now its back to trying to get the colors of the menu the way I’d like (https://forums.fogproject.org/topic/11972/ipxe-menu-colors-help).

Thanks