Posts made by Zer0Cool

For those interested, this is the procedure I followed to update:

FOG 1.5.2 to 1.5.3
CentOS 7.5.1803

Altered a bit from https://wiki.fogproject.org/wiki/index.php/Upgrade_to_trunk
Initial install I followed this (just for reference, only needed for fresh install): https://wiki.fogproject.org/wiki/index.php?title=CentOS_7 (hence my cd line being to the directory the install directions mention)

cd ~/Downloads/git/fogproject
git pull
cd bin
sudo ./installfog.sh

A couple observations about the installer:

• It prompted to go to the url ‘ip/fog/management’ to update/create the database. Doing so just took me to the dashboard of my FOG server. I hit ‘enter’ back on the server to continue. Not sure if this prompt is just a remnant and can be ignored or if I skipped something important.
• On the step of ‘Setting up TFTP and PXE server…’ (wording may be different) it took about 5 minutes to compete. I was concerned it hung but gave it time and it moved on.
• At completion it incorrectly states my username and password as the default (fog/password). I logged out and into the web interface and checked the users section and my proper “old” username and password were there and no new user created so it appears the message is wrong.

I rebooted after completion and once back up everything seems to be in order looking at the web gui. If anything problematic crops up ill post back but seems to have went relatively smooth.

@quazz Ah ok so if I understand correctly I am pulling the new files from git (having told it the branch I want) and then running the installfog.sh script (similar to the initial install)?

Just noticed 1.5.3 is out.

I read the post and followed links as well as searching Google and cannot find anything official and recent in terms of the proper upgrade process.

I am currently on 1.5.2 (CentOS 7.5 base). It shows its out of date and that the current version is 1.5.3 but I see no option in the interface to suggest an upgrade option there.

Other than things I have customized within the web GUI the only other alteration I recall was in the dhcpd.conf to the ip range used by DHCP, which I can easily change myself.

I have taken a snapshot of the FOG VM (it runs in a ESXi 6.7 VM) and backed up the configuration from the gui.

If someone could guide me as to how to properly update or point me to a current/valid guide on updating I would appreciate it. Thanks

@quazz I feel a bit silly here, but I am really lost. A fair portion of what you are saying is over my head.

@quazz said in iPXE Menu Colors Help:

Try the fallback method, maybe:

Not all consoles support full RGB colours. You can use the basic ANSI colour as a fallback. For example, to define colour 6 as turqouise, falling back to cyan if RGB colours are not available:

Not sure were I do the above, I assume in the web gui under the menu colors/config, but not sure which field(s).

From your description it sounds like there are 2 ways of displaying the menu, the standard and a fallback in case it doesnt/wont work. How do I configure both to follow the simple format I proposed? The only potential issue with the format I proposed I can imagine is the specific shade of blue, in which case ill try and find the closest one…i just have no idea what specifically to change and what to change it to, to accomplish my goal.

Thanks

@quazz I removed the background image (the default) from the web GUI as it caused iPXE to crash when booting UEFI.

I however have the same red text/black background menu in BIOS and UEFI. I would of course like to alter this in both (if they are manipulated separately) so that it is uniform under BIOS/UEFI.

The background working under UEFI would be a cherry on top but not really important to me right now. My primary concern is getting the colors right.

Thanks

FOG 1.5.2
CentOS 7.5

For the life of me I seem to be unable to change the default coloring of the menus without completely making a mess of things.

I just dont have my head wrapped around the iPXE/FOG handles menu coloring despite reading over:
http://ipxe.org/cmd/cpair
http://ipxe.org/cmd/colour

My menus by default show up as red text, black background and selected text being white text with a red background. The title “Host is not registered!” (and the — under) are white/grey.

What I would like to accomplish is getting the un-selected text to be white, background remains black, selected text is a shade of blue (0081c6) with a white background and the title is also the same shade of blue (0081c6).

I am as of yet unable to determine what specifically to change to get this result. Everything I try either has no effect or does not result in the desire element being changed or with the right color.

Any help would be great, Thanks

@george1421 All good, got it!

This is what worked for me:

kernel http://${fog-ip}/fog/os/fedora/ws28/images/pxeboot/vmlinuz
initrd http://${fog-ip}/fog/os/fedora/ws28/images/pxeboot/initrd.img
imgargs vmlinuz initrd=initrd.img repo=http://${fog-ip}/fog/os/fedora/ws28
boot || goto MENU

my repo=http://${fog-ip}/fog/os/fedora/ws28 line is the path to where I have rsyncd the mirror path/releases/28/Workstation/x86_64/os/ to.

Thanks again.

@george1421 Yea That was my point the repo has a different structure than the DVD. I rsyncd the repo and am trying the install now but it looks like it may have hung during booting Fedora…ill see if I can work it out.

EDIT: yea starting getting dracut initqueue errors just repeating.

@george1421 So this is a bit weird (to me at least), but Fedora only seems to offer a net installer iso or a Live iso, the Live iso doesnt have the os directory.

I have been digging and I could probably just rsync the repo (the portion I need) like I do for CentOS and use it as the install media but was wondering if I am missing something more simplistic?

The net installer isnt an option and I couldnt find a “self contained” iso like the CentOS DVD.

Any advise?

PS: no one is perfect…but you are certainly awesome

@george1421 As always, you are a great help! I will give it a shot shortly and report back.

My menu entry, by the way, is based off your guide you may consider updating it if I may be so bold. Did they change from 27 to 28 how you PXE boot?

Thanks

@kleber I’d recommend removing the background image via the GUI under Settings | iPXE General Config. I just removed the background image name from that field entirely. The default background prevented certain machines from being able to boot for me as UEFI. Figure its a quick enough thing to check.

Are there other machines that do boot ok with your setup or are you not able to boot any machine via iPXE?

Do the machines you have issues on have any BIOS settings specific to PXE booting (enabling it, authentication, etc)? If you you may want to check the configuration there.

Have you tried UEFI boot instead of BIOS boot, I have found sometimes the error is more descriptive in one vs the other (or even that one way has no error and the other does). I have found it especially helpful to have a camera/phone camera with high speed video recording, ie 120/240 fps and record the screen after I make my selection to catch any brief messages on screen.

FOG 1.5.2
CentOS 7.5

Trying this on a physical host, a Dell 3620 in UEFI and in BIOS modes. When I select my option from the iPXE menu to install Fedora it boots up to basically the Live CD instead, giving me a desktop, letting me pick some of the post install options (like data collection and creating a user). I do not however have any options to install to disk. A reboot effectively destroys the environment as it was running in memory.

here is the menu entry:

kernel http://${fog-ip}/fog/os/fedora/ws/images/pxeboot/vmlinuz
initrd http://${fog-ip}/fog/os/fedora/ws/images/pxeboot/initrd.img
imgargs vmlinuz initrd=initrd.img root=live:http://${fog-ip}/fog/os/fedora/ws/LiveOS/squashfs.img ip=dhcp repo=http://${fog-ip}/fog/os/fedora/ws splash quiet
boot || goto MENU

I would suspect it has to do with the root=live portion of my entry, but its almost identical for CentOS and that starts to the installer as expected.

I have been scouring for documentation or any reference online to a working iPXE entry for Fedora but they all basically look like what I have.

Any help would be greatly appreciated, Thanks

@george1421 Ok so not an issue with the network, R620 works just fine off the same switch.

I am gonna chalk it up to the Dell 3620’s firmware (which is the latest) being problematic. Its not the first time it proved to be, likely wont be the last.

I guess I can live with the issue as it always eventually runs setup.exe. As long as its not a wide spread issue and limited to that model machine I am gonna move on and just live with it.

Thanks for the help though, always good to have another person to bounce ideas off and to get other ideas from.

@george1421 So I tried it on an R620, booted multiple times and connected to share and ran setup.exe almost instantly. Granted the machine takes ~4 mins to reboot and cycle back to the pxe menu.

I injected the drivers from the pack into the wim and just tried again on the Dell 3620, “same” problem in that it had issues. Actually (likely coincidentally) at the worse end of the spectrum of problems. Got error 53 trying to mount share, my loop took 12 cycles to finally connect, then setup.exe took roughly 1 min to show up.

So it looks like drivers may not have resolved things. I am beginning to think its these Dell 3620 workstations and their firmware thats just bad.

I am also wondering if its a networking issue as the data passes through a dumb swtich to where I am testing the 3620. Ill roll a R620 over to it and see if the R620 suddenly has issues then maybe its a network issue and not specific to the machine.

If all else fails ill try a share on a windows server to serve the install media.

Thanks

@george1421 I didnt feed it any drivers, was hoping for a machine agnostic winpe image…maybe wishful thinking. I can add the drivers to it.

Dell Precision 3620 is the box with the delay, ill try something else see if its an issue.

The image I am using starts up to a command prompt and runs the commands. When it fails to connect to the share I can manually type in the net use part and get it to connect.

setup.exe however appears to hang in the command window but given enough time eventually runs. I havent had an instance of it failing yet (as long as the share is mapped).

Gonna try another machine first, if it works on another machine differently I will try drivers in PE.

I am starting to lean towards a possible samba issue. I am considering even placing the Windows installation/winpe stuff on a windows server machine and serving them from there (I had this when I initially started this, then moved the install media to my FOG server). If it works from the Windows based share I will know its a samba issue on the FOG/CentOS server.

@george1421 Ok scrap some of my prior comments…I went for a “sanity check” only to have it backfire on me.

It is now happening in BIOS boot as well, however seemingly not as slow (1-3 mins when the issue occurs vs 5-10 mins under UEFI).

The observation that seems the most sure is that time between runs appears to have an impact. If I run it and have not done so recently it works pretty much instantly. If however I run it, cancel and reboot and run it again I then have issues. Giving it some time between attempts appears to have the most noticeable impact of anything I have tried yet.

Does samba server (run from CentOS) have anything about it that may cause slow auth, prevent multiple connections from the same user, etc.?

Does the act of mounting the share in winpe in any way get stored server side? Like if I reboot and dont give it time to flush out it thinks its still connected or wont let it reconnect right away?

@george1421 Also, timeout 10 game the same “command not recognized error” as sleep.

Still, if it was a SMB issue wouldnt it be a problem when BIOS booting the machine and running winpe via pxe?

Its odd that BIOS booted it works instantly every time as expected but when UEFI booting it works right maybe 1/10 times.

I could live with an extra 1-2 minutes to run setup.exe, maybe, but waiting 5-10 minutes for it is a no go (especially if other are to use this).

Its also weird that when the share will mount but then the setup.exe takes forever to execute. In other words the command to run setup.exe is executed but it then takes a long time for the setup dialog to appear.

Is it possible winpe uses different NIC drivers under BIOS/UEFI?

The BCD, boot.sdi and boot.wim are the same for BIOS and UEFI correct? I dont need to pass iPXE a different set for BIOS vs UEFI do I?

I am kind of grasping at straws here

@george1421 Set logging to 10 and added a line to smb.conf to generate a log for each machine. Reviewing the log for the problem machine doesnt appear to reveal any clues.

I get some lines about it finding the user, then something like adding homes service for user... and lp_servicenumber: couldnt find homes.

When it booted and connected instantly and ran setup.exe within seconds it was the same thing as the last pass when net use worked within about 30 seconds and then setup.exe took ~5 mins to run.

It seems to me almost as if it runs fine after a period of time has passed but if I exit the setup and try too soon it has issues.

I am still at a loss with this, gonna try the timeout option peppered in, not sure what else to do beyond that.

Thanks

@george1421 you know, you keep helping me you are gonna have to start charging me

Some of your ideas where thoughts of mine too, but have since realized some of them are not the culprit.

For example, wpeinit I would presume has the network up since the ping command works prior to net use. I will give timeout a try however as its basically the same concept I was trying with sleep.

I think the ping command is in that script mostly to add a delay and the verifying connection is kind of secondary. That was the only rationale I could come up with for pinging 4 times or as you pointed out I could simply ping 1 time and use it to verify the connection.

I am curious about your DNS statement though. Since I am using IP instead of hostname, shouldn’t that “circumvent” the DNS being an issue? If not maybe some sort of delay as you mention is needed, however I found ping -n 20 to not be long enough to make a difference. Also, doesnt explain why its not an issue BIOS booted.

My samba entry is super simple, just:

[global]
unix extensions = no

[pxeshare]
comment = PXE Server SMB Share
path = /pxeshare
valid users = @smbgrp
guest ok = no
browsable = yes
writable = yes
follow symlinks = yes
wide links = yes

I will take a look at the samba logs and see if any errors are present.

Thanks

FOG 1.5.2
CentOS 7.5
DHCP, HTTP, NFS, SMB etc. (another server is DNS)
single subnet.
All the above is on ESXi as a VM, test host is a physical Dell 3620 Workstation

So my question(s) pertain to using FOG to PXE boot Windows installs using wimboot, winpe, etc. The Windows version doesnt really matter (as the issues are pre-windows) at this rate however in the end ill want it to work with 7, 10, Server 2012 R2, Server 2016.

I am running a Server 2016 VM with latest MDT, ADK, etc. I followed this thread and am using the batch file to generate the winpe image with the startnet.cmd batch file in it.

So here is the strange bit. If I boot the machine BIOS boot everything works with the script pretty much as is. WinPE boots, the startnet.cmd starts to run and it almost immediately (after pinging) connects to the share and runs setup.exe.

My issue is mostly when booting UEFI (secure boot off). WinPE boots, and then its inconsistent.

Sometimes it hangs for anywhere from 1-3 minutes at the ‘net use’ command. At this rate it will either; connect and move on or give me an error 53 (something about not finding path). If I get error 53, I can then in that window type the command by hand and it will work.

If it does move past the ‘net use’ command it will execute the setup.exe command and usually nothing happens right away (on rare occasion it will open as expected quickly), I have let it go for anywhere from 1-10 minutes before the setup actually opens and runs after this line executes.

The real odd part is if I actually move on through the setup the setup is super slow after the previous slow behavior as well when typically its not.

Here are a few things I tried:

• Adding ‘sleep 2’ lines in between ping, net use and setup.exe. I get errors when it runs that ‘sleep’ isnt recognized. However the error alone seems to increase the rate at which this succeeds. Could be placebo.
• Adding -n 20 to ping. Making ping run 20x instead of the typical 4x, making for 20 seconds between initial run and trying to ‘net use’ connect. May marginally increase success but not substantially enough.
• I have created a loop in which ping and ‘net use’ re-run if ‘net use’ didnt connect. Re-running ping only for a reasonable delay. This works in that it always eventually connects, but still puts me in the 1-10 minute time frame to get to setup.exe running.

my startnet.cmd looks basically like this:

wpeinit

:loop
ping 10.0.0.2
net use i: \\10.0.0.2\pxeshare\os\win\s16 /user:username password || goto :loop
i:
i:\setup.exe

The user is a user I setup on the FOG server, in a group created for smb (smbgrp) specifically for startnet.cmd (as the password is visible). This user has smb credentials and access to the \pxeshare folder and its sub folders, which I have used from various other linux and windows machines to connect to or map to the share without issue.

Any help would be greatly appreciated, I have been struggling with this for a couple days and feel like I am just spinning my wheels at this rate. Thanks