@vascomorais Seems like your question has mostly been answered, but I wanted to pipe in on your comment ‘I can ask the forum’. YES! These forums are amazing. There are numerous people(Including senior developers) that will respond quickly and intelligently and assist you with problems you have with the system. I can’t say enough good about this community.

Hope FOG works for you, it’s been a lifesaver for me and my organization!

Philip

@jpaul As a test place a dumb (unmanaged) switch between one of the troubled target computers and the building switch and try it again.

If this works, then you need to get with your networking admins to check the network switches to ensure that (if) spanning tree is enabled, you are using one of the fast stp protocols (RSTP, MSTP, fast-STP, or what ever your switch port manufacturer calls it).

@skydraw35 said in Host Registration:

I put the background and it work in Legacy/Bios for me !
I have a last question, when i up/receive my image, can i put the uefi ?

Not sure I follow you here. From the sounds of it registration works for you when BIOS/Legacy booted?

Are you asking if you register it via BIOS can you then deploy/capture images in UEFI mode?

I would think so, as long as you set the host machine to boot UEFI and the iPXE menu loads up. I dont think the registration of the machine is tied to BIOS/UEFI mode at all. Images and PXE booting are however, so you couldnt for example (at least not easily) capture a UEFI image and then deploy on a machine BIOS booted for example.

With the change you made to DHCP, you should test and see if UEFI now works too for registration.

Disable Bitlocker was no alternative. That’s the result of my tests today.

At first I tried to only unlock the bitlocked drive, but this will not withstand a reboot. So my unlocked image gets locked again when I reboot.

When I disable BL that means I have to remove the BL encryption, so that the dd in funcs.sh ( dd if=$part bs=512 count=1 2>&1 | grep -i ‘-FVE-FS-’ ) is not able to find the BL-signature.
But that would mean I have to deploy truly clean images and encrypt EVERY deployed image afterwards. This is a no-go. It costs time in encryption and (even worse) it creates one dedicated key for every new deployed computer.
We need to use one remotely stored key for all deployed computers. That makes best sense in our use-case an I cannot change that decission. TPM will not work for us and would no make sense either as we need to have that mentioned key. Windows update will not hesitate us here … its an embedded W7 for dedicated systems.

Finally I patched funcs.sh (uncommented that bitlocker check) and made a new init.xz of it.

So my remaining question here:

How I have to use the setupcomplete.cmd correctly in terms of:

receive the new hostname . Here my first attempt was to wait some time as I observed that snappins take about some minutes until they get delivered … Will that naming take same time? set a static IP which depends from hostname ( I already have prepared a batch file for that …)

Will that all have to go into setupcomplete.cmd?
How and when will that get executed?

Regards

@quinniedid which is what I guessed. 🙂

From a security standpoint I dont see using NFS for imaging as an issue. As mentioned you can set it to allow only from a specific IP range. That should be enough to prevent issues (if a adversary is already on that subnet you have bigger issues). Especially if you dont have sensitive data in the share and if your FOG server is behind a firewall.

Samba would have the ability to allow only connecting from approved users or groups, the problem with that is passing the credentials to connect.

In Clonezilla I used to capture and deploy via SSH, which I really liked, but havent had any issues with how FOG handles it via NFS.

Your first warning, as it seems you have figured out, is I think kind of a basic way NFS works. Client machines have to be able to see/query the server for the share to use it. The second warning is just an extension of that, whats the point in knowing the share is on the server if you cant mount and use it.

Its a windows-service executable (exe) which I have to call with arg /install to install it.
Normaly I would install this by hand in the mother-image I deploy to all clients. But the development of that service delays, so I have to postpone that installation.
Before the install-call of the executable I have to remove the write-lock of the partition, means I have to call another system-executable in advance. After a successful installation I want to reboot.
The SW is an cmake based development. I have no cmake configs which created a Visual Studio deployment project (msi - even if an msi would be good for doing this … I have my doubts) so I have to create this afterwards in the Visual Studio. That is not a good attempt at all, no other co-worker will accept that sh***. So I am looking for an easy-going way … maybe WiX will get it. I have to read the docs, but if anybody has some better suggestions, please tell me.

@jla This is fixed in FOG 1.5.3. Because 1.5.3 was released days ago, and this post from 30 days ago says it was fixed in working-branch: https://forums.fogproject.org/topic/11875/snapin-upload-limit-of-8mb-is-too-small So my advice to you is update to 1.5.3 and see how it goes.

@wayne-workman Ok cool, I will look into it, Thank you.

@george1421

Yes, sorry to have disturbed you

@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

@steveo (I’m only considering creating fog storage nodes using fog) well since you have so many and they are all physical there should be a way to use FOG to clone the storage nodes. I need to think about the best approach here. But you should be able to install the OS, and at least download the fog repo to the system.

Here is where it get into some speculation.

Now when you install fog, it creates a .fogsettings file. The .fogsettings file lists all of answers to the questions you supplied when you first installed fog. So when you reinstall fog like during an upgrade the installer will reference that file instead of asking the user questions over again. I wonder if we can leverage that by dropping that file in the proper location during storage node image deployment. Then running the installer with the -y command post deployment?? The only caveat here is that you should only install FOG once the storage node has its forever IP address. There is a script to reset the IP address after the fact to. Its just depends on what ever is easiest. You also should probably consider how you will seed the storage node before you send it out to the remote location.

Also during image deployment, you can have the fog master node give the fog storage node its name. Once your storage nodes have been created you won’t need them in the fog database unless you want to reimage them again.

With that many storage nodes, you might consider setting up a dedicated mysql server. Remember that storage nodes don’t have a local database, it uses the database on the master (root) fog server. That will be 400 open connections.

@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

@amerhbb that’s a matter of opinion but I really like it.

@george1421 Yep they are all exactly the same hardware.

What are your thoughts on the Fedora issue I am having?

Thanks again for all your help!

@fallingwax Yes, look in the history table in the database. It’s only available via SQL.

@zago123
Here is a link that explains how to format/create partitions. You will need a Windows boot media. So when you get this up, you will need to identify which partition you want to do which task to (format, create, etc.). Make sure you are careful with this and do the wrong partition by mistake.

Links:

https://davidzych.com/install-windows-10-from-a-usb-flash-drive/

https://davidzych.com/install-windows-10-from-a-usb-flash-drive/