@kilua4650 Can you explain how this is related to FOG?

Hi,

i have FOG 1.5.0 running on an ESX Host and a Storage Node on a bare metal machine.
Works like a charm since years.

Best Regards X23

@michaeloberg said in Issues with USB Type C NIC Adaptors:

@kghli @george1421 @Sebastian-Roth

This could be a breakthrough. I just noticed that the system is passing the address through iPXE correctly and that FOG is what is recognizing the USB Type-C dongle’s MAC address - the exact scenario that @kghli is experiencing. I took a screen shot of the issue and here is the iPXE address (which is the correct system address):

Then when I boot to FOG (now running Debian 10.11 and FOG 1.5.9, and choose “Client System Information” then choose “Display MAC Address” it show’s the USB Dongle’s MAC:

Hopefully this is going to help troubleshoot our issues as we have narrowed it down to FOG alone, not the manufacture of the system, the BIOS configuration or the version of FOG.

Thanks in advanced!

Mike

I also recompiled iPXE from (g4bd0) to (g1844a) and verified the date (ls -la /tftpboot/*.efi) was today and it still is not working.

@george1421 I pulled the latest build of Ipxe and the build number did update and had a different build number but it still did the same thing.

I’ve reimaged using deploy image about 5 times now and it consistently works now go figure!

Luckily in my environment we don’t have any old computers, this moving forward will be the lowest spec machine we will have.

One other thing that was strange was when doing a full registration of the host and I was asked would I like to deploy an image if I said yes it accepted my username and password using Ipxe.

Thanks for explaining why Ipxe was picked as a default efi image too. I just wonder how many others will be affected by this change in firmware by HP and what it is changing in the NIC!

David

@wt_101 When I say heavy lifting is done by the client computer, I mean all of the work and the actual performance of fog imaging is directly impacted by the target computer’s capabilities and components. While I understand this is technically impossible, but if you have 2 computers that are exactly matched, except for one has DDR3 1600 and the other has DDR4 2133 RAM, the second computer with the faster ram will deploy the image faster because the transferred image is decompressed in ram on the target computer (more on that in Q2).

Q1 To be honest I never paid attention to what the web ui says for size vs what is on the disk. Off the top of my head having a 3:1 compression ratio seems a bit high in my estimation. Is it possible, yes. What really is a metric is what is the size of actual data on the target computer vs the size of the image files. Its possible that the web ui is recording something different that raw source disk vs compressed image file. There is a compression slider in the image definition. This tells the compressor what compression metric to use (not the right words) during compression. The higher the number the more compression methods it uses to compress the data. i think the slider is set for a default of 4 or 6 for gzip that value is a good balance between compression size and speed. For zstd the Goldilocks number is 11. Where the gzip compressor has a range of 0 to 9, zstd has a range of 0 to 22. I don’t think anyone has done any testing to find the actual Goldilocks number in a quantitative way though. I suspect they found a number that worked well for them and called it good.

Q2 Option A is correct. The image is compressed/decompressed on the client so only a compress image is ever communicated with the client. This saves on storage image size on the storage node as well as transfer bandwidth. From a metric standpoint I know that a 25GB target image can be transferred in about 4 minutes. The only way that’s possible on a 1 GbE network is to transfer a compressed image.

Q3 See that is where the magic of FOG is. The developers created a custom version of linux. That version of linux is called FOS (FOG Operating System). That OS has all of the tools built in that FOG uses to image a target computer. Yes FOS has zstd and gzip compressors built in. When you pxe boot a computer during image, first the iPXE boot loader is transferred to the target computer. iPXE is responsible for the FOG iPXE menu. Once you make a menu selection (like registration) you will see two files transferred to the target computer if you have a fast eye. You will see bzImage (the kernel) and init.xz (virtual hard drive) send to the target computer, that IS FOS linux being sent over. The OS is very small and very fast.

For Point 4, that is more of a question for the developers. I don’t look under the hood for statistics settings. I just know that on the Partclone screen what that speed number means. I don’t know if the FOG program as a way to record that speed or not. As for taskelasped time I think that means something else. As I mentioned above, on a 1 GbE network a 25GB image should take about 4 minutes of transfer time. 16 seconds seems a bit quick.

For Point 6, The fog client is used for more than just renaming the client and connecting the target computer to AD. Its also used for application deployment and some rudimentary system management. You do not need to run the FOG Client if you don’t want to manage the target computer after image deployment.

Q1 yes there is a way. On my campus, which is mostly MS Windows based, I don’t use the fog client at all, yet I still have a touchless deployment. I leverage a feature in FOG called a Post Install Script to make changes to MS Windows unattend.xml file just after the image is pushed to the target computer. For a linux client it is just as easy most of the things that configure linux is just in text file, and FOS Linux is… wait for it… linux, so the possibilities are endless. The concept of a post install script is that you would create a bash script on the fog server that is executed by FOS Linux. That bash script would mount the target computer’s hard drive (post image deployment) and make the necessary adjustments to the hostname and any other deployment specific settings. The post install script can have access to fog host definition variable so you can leverage some of the extra fields in the host definition for specific uses (like other1 and other2 fields).

No idea anyone?

Quickreg Pending MAC Filter doesn’t seem to ignore MAC Addresses starting with 54 when i delete the host, restart the FOG Client i can see that the pending client still want to add a mac starting with 54:

The Most strange thing is that it tried the VPN Client MAC as primary while it’s not connected, i would expect the Cable NIC which is also connected while the FOG client reports the client to the FOG’s Webif.

I need to finally ban MAC from interest from FOG that are starting with 54, how can i do that?

Best Regards X23

@vertimyst said in Running both CloneDeploy and FOG?:

but since I have CD on our server already I can’t get anything to boot to FOG over our network - it all defaults to CD.

Its not clear exactly what you are doing here. FOG doesn’t use a CD/DVD it boots over the network. FOG is similar to CloneDeploy or Clonezilla but different.

For FOG you will set dhcp options 66 to the IP address of your fog server and dhcp option 67 to the boot file name. The boot file name depends on what format your computer’s firmware is in. For a BIOS computer, dhcp option 67 is undionly.kpxe and for a UEFI computer the boot file name is ipxe.efi.

Once those values are set in your dhcp server then you pxe boot your target computer into the FOG iPXE menu.

I have a feeling since you referenced CD several times you might be doing something non-standard with FOG. Can you explain a bit more of what you are trying to do?

@lerne-nie-aus if i give static ip, than i can ping 8.8.8.8 and surf in internet.

I dont know why:(

@danboid said in Restore BIOS W10 image onto UEFI machine:

First, why is there so little content on the FOG wiki FAQ page?

Would you be keen to help work on the documentation?

@george1421 said in User defaults to root on image capture:

The root of the issue is that when FOS Linux (which runs on the target computer) clones an image it runs as root (to have full control of the target computer during imaging), that is why they are being created on the FOG server as the root user.

That’s correct, though not the whole truth. FTP is used within the FOG server internally to move the fully captured image files from /images/dev/… to it’s final destination /images/IMAGENAME/. It’s been a long time since I looked at that part last time but I think it was actually meant to do a chown operation alongside those FTP move and rename operation. But I can’t remember why this wasn’t actually working from the top of my head. It’s probably still the case because it works in pretty much all cases since then.

I guess it can be changed to chown fogproject user If you can explain why it causes issues on deploy in your case. What’s special about your setup? Modifications?

@george1421 I just tested it out on a PC outside of our IT vlan with success. I hard coded it already, but I have a habit of not disclosing our IP addresses even if they’re private. I get the Press ESC to show the menu option for one second, then it boots to the hard drive. Now I took the modified bootx64.efi from my usb drive and copied it to the Windows EFI partition, replacing the existing one (renamed the old to bootx64.efi.bak), made sure that the UEFI is pointing to the file, and now the PC boots the fog process without USB.

@george1421 well, I am excited to say that it is working. I literally just readded what was already added, and re-tested. Could have been gremlins or lack of sleep, whatever the case, I am about to capture my image, and do a test deploy. I will ping you back shortly and you can close this as solved I do believe.

Thank you so much for the assistance. Ping me anytime you need a tester.

@sebastian-roth May have just fixed it - had to set the server I restored from snapshot to the correct location in “Location Management” on the master server. Will update thread once I get an opportunity to test.

@george1421 Hello! I fired up a new VM and installed Debian 10.11 (buster). I did a modified installation from the YouTube video you shared, I did partitioning based on this video - https://wiki.fogproject.org/wiki/index.php?title=Debian_8

I installed 1.5.9 and setup the DB and changed the fog default password.

My next question is - can I export my settings off of my old FOG server into the new one? Currently I have both VMs fired up so I can simply toggle between the two IPs in a tabbed browser.

Once I get the new server setup, I am going to change my DHCP and PXE settings on my Windows network to test PXE booting my new computers that use the USB dongle. I am going to be beyond thrilled if this works as I have several hundred of these machines that need imaged.

Thank you so much for your help and look forward to your response!

Gratefully,

Michael

Sorry, I only noticed after posting that I accidentally removed a single ’ character when I edited my tokens for the post.

@lerne-nie-aus said in Deployment without Register and credentials:

Or where i can find some batch file or unattendend.xml to check for zero touch deploying?

This is a MS Windows thing and not really anything that FOG cares about. The unattend.xml and sysprep there are many examples of how to do that part on the internet. How I do this is I use MDT to build the golden image then sysprep and power off the golden image VM. Then reboot the golden image VM and capture with FOG. So FOG only moves the disk image from local hard drive to and from the FOG server. Once the image is copied over to the target computer and the target computer is rebooted then FOG does not touch it any more.

My Question was, if i dont need to select this image and if i can set it up somewhere else as default.

Just so I’m clear here, You want to PXE boot into iPXE and then have a single image deployed to a computer without anyone touching it? Like PXE boot then image is deployed? If you think about its like a deep freeze system restore? I’m just trying to understand your use case. Can it be done with FOG? yes. Should you do this? I can’t answer that.

@kayotte said in Lenovo Thinkpad E14 Gen 2 Issues:

I noticed that now deploying old images on old laptops is also having this same problem not joining the domain. Is it possible that the fog update I ran could’ve changed something?

It’s probably best you open a new topic for this as it doesn’t seem to be related to the issue you had before. Please grab the fog-client log file (C:\fog.log) and post that (upload to a file share). I am pretty sure we’ll find why it doesn’t join in there. As well you might also add more information on details like sysprep or what else you do to prepare your image.

@doctrg Its always best to migrate same version to same version. The issue is the database since there has been many changes between 1.5.5 and 1.5.9.

On your new fog server go ahead and install 1.5.9, then bring over the 1.5.5 database and raw image files. The first time you attempt to access the web ui it should detect and older database and try to upgrade it. It will take you to the db upgrade page instead of taking you to the login page.

@danboid said in Linux mdraid RAID-10 with FOG?:

software RAID built into the Linux kernel

These are the words I was looking for to give a direction. mdraid can be used for more than just the intel fake raid as you referenced previously.

Yes FOS linux (the engine that interacts with the target computer to capture and deploy images) can interact with a software raid.

the same rules for FOG imaging as with clonezilla. If the software raid doesn’t exist you must create it before you can image it. You could test to see if it exists in a FOG post init script, If your deployment mode is download then you could create a bash script to create the array. Post init scripts are executed just after the FOS OS inits and before any imaging begins. The tutorial you referenced before lays out all of the bits you need, just in this case you are not setting up the intel fake raid configuration.

@george1421 Nice, thanks heaps for your testing and the research! Will see if I can add this. Interesting you didn’t even get the serial in the mSATA…