is 10.6.6.6 the IP address of your fog server?
Best posts made by george1421
-
RE: RC-36 Breaks FOG Client AutoUpdater?!
-
RE: Kernel is missing the correct driver
@Nick said in Kernel is missing the correct driver:
Also is it possible to update the FOG with PHP 5 or do you need for the new Update PHP 7
I personally can’t answer that question.
As for the nics
8086:02f0 Intel wireless (wireless is not in FOS Linux)
8086:0d4f “Ethernet Connection (10) I219-V” first available in linux kernel 5.5
It should work with the current 5.6.8 linux kernel. What is the output of the
uname -a
command? -
RE: CPU 100%
@Tanguy How many client computers do you have in your environment that have the fog client installed on them?
-
RE: Server migration - Name changing issues
@Tom-Elliott So in this case its best to just remove the old fog client and then
push downinstall a new one with the proper MSI flags to point to the new 1.3.0 fog server (??) -
RE: iPXE iso vs iPXE FOG
@george1421 Following up on this a bit. After running the
buildipxe.sh
script I found that only the ipxe.efi files were updated in../fogproject/packages/tftp
directory. Digging into the script a bit more I found on my Cento 7 fog server there were some dependencies missing to properly build iPXE.To get the complete iPXE files updated I needed to add the following centos packages.
yum install genisoimage syslinux xz-devel -y
Then rerun the
buildipxe.sh
script. Once that was done I confirmed all of the iPXE files in../fogproject/packages/tftp
were correct.FWIW the fog installer script
../bin/installfog.sh
copies the files from../fogproject/packages/tftp
to the/tftpboot
directory during installation. -
RE: CPU 100%
@Tanguy OK here is what I’m thinking. We had a performance issue a while ago with earlier releases of FOG, where the default sql server data engine was being used instead of a higher performance version.
The conditions were > 300 computers with the fog client installed. When you looked at
top
and sorted byP
cpu there would be many php-fpm services running as well as high CPU usage on mariadb. This is because the default ISAM db engine uses table style locking on an update, where INNODB uses row level locking. Switching over to INNODB resolved this issue. I don’t remember which version of FOG is when the Devs switched over to using innodb by default. I did write a tutorial on how to update your db design that you might want to use to see if you are still using the ISAM engine or the INNODB database engine. If you are using the INNODB engine, then we will need to debug this issue since its something different than what we’ve seen before.
https://forums.fogproject.org/topic/16099/configure-fog-database-to-use-innodb-engine?_=1698321484681 -
RE: Server migration - Name changing issues
@Yanis-Sauve If you were handy with scripting you could just push out a new ini to each workstation to update the ini or create a snapin on 1.2.0 server to update the ini to the new server. There is a bunch of ways to update that ini file.
-
RE: DELL 5060
@tice-stan In addition to getting a clear image of the error as Sebastian recommended, I also think setting up a debug capture/deploy might give us a better understanding of what is going wrong.
After you capture the image Sebastian asks for then schedule another capture/deploy debug session. Preferably the same process you used to capture the previously mentioned error message. At the FOS Linux prompt I want you to key in the following commands and then take a clear picture like you did for the previous lsblk command.
cat /proc/cmdline
uname -a
lsblk
- Get a picture of that
- Start imaging in single step mode. Single step mode will require you to press enter between each break-point. Start imaging by keying in
fog
. - Now watch for any errors, maybe an error is displayed just before the error in your screen shot. Take a picture and post it of any new or hidden error.
This might not give us the answer we need, but this process will tell use where we don’t need to look for the problem.
-
RE: CPU 100%
@Tanguy Lets first identify that the database engine is at fault here. Lets just do the first step in the tutorial.
SELECT TABLE_NAME,ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'fog' and ENGINE = 'MyISAM';
If the query responds with MyISAM then this is the problem. If it responds with INNODB, then lets discuss.
If its the data engine, you can make this change while the system is up and running, no need to schedule downtime.
-
RE: Server migration - Name changing issues
@Yanis-Sauve said in Server migration - Name changing issues:
I migrated the configuration from the old server to it is that the old IP was still in some places. I’ll have to change all of these back again. I’ll try to find the page that helped me with that.
Wayne created a script to fix up the FOG install if the IP address has been changed for FOG 1.3.0. Let me see if I can find the link.
-
RE: Booting MDT 2013 LiteTouch with FOG
Method #2
This second method involves taking the LiteTouchPE_x86.wim and LiteTouchPE_x64.wim created in the MDT environment and combining them with elements of the WAIK to create a directly bootable MDT litetouch image that can be launch via FOG’s ipxe menu.
- On your MDT server select your Deployment Share->Update Deployment Share. This will update your litetouch boot image files with the latest settings from your MDT configuration. When the update process completes change to the DeploymentShare\boot folder. There are 2 files we will use for this method of integration. These files are LiteTouchPE_x86.On your MDT server select your Deployment Share->Update Deployment Share. This will update your litetouch boot image files with the latest settings from your MDT configuration. When the update process completes change to the DeploymentShare\boot folder. There are 2 files we will use for this method of integration. These files are LiteTouchPE_x86.wim and LiteTouchPE_x64.wim.
- Download the Windows Automated Installation Kit (WAIK) for Windows 7 from the following link: http://www.microsoft.com/en-us/download/details.aspx?id=5753
- Install WAIK on a development system (workstation). You will only need WAIK installed long enough to extract the boot images.
- Once WAIK is installed Follow this path Start menu->All Programs->Microsoft Windows AIK->Deployment Tools->Command Prompt. Selecting this menu should open a cmd shell. This next step we will create both the 32-bit and the 64-bit versions of the WinPE boot environments. In the command shell key in the following:
mkdir %temp%\fog\mdtboot
copype x86 %temp%\fog\mdtboot\x86
copype amd64 %temp%\fog\mdtboot\x64 - Download wimboot from this link: http://git.ipxe.org/releases/wimboot/wimboot-latest.zip
- Extract the wimboot file from the zip file and save the (wimboot) file only in the follow folder: %temp%\winpe\fog
- Copy LiteTouchPE_x86.wim and LiteTouchPE_x64.wim from the MDT deployment share to the %temp%\fog\mdtboot folder
- Using 7-zip or similar tool create a zip file of %temp%\fog*.* as mdtfog.zip
- Move the mdtfog.zip file to the FOG web server’s base directory (either /var/www/html or /var/www depending on the linux distrobution).
- On the FOG server navigate to the FOG web server’s base directory as indicated in step 7
- Use the linux unzip program to extract the mdtfog.zip archive to the web server’s base directory using this command: unzip mdtfog.zip (warning if unzip is not installed for your linux distrobution you will need to install it using the following command [rhel based] yum install unzip -y [deb based] sudo apt-get install unzip )
- From the FOG management GUI select the following Fog Configuration->iPXE New Menu Entry
- Fill in the following details:
Menu Item: winpe.BootMDT
Description: Boot MDT LiteTouch
Parameters:
cpuid --ext 29 && set arch x64 || set arch x86
kernel http://${fog-ip}/wimboot
initrd http://${fog-ip}/mdtboot/${arch}/ISO/boot/bcd BCD
initrd http://${fog-ip}/mdtboot/${arch}/ISO/boot/boot.sdi boot.sdi
initrd -n boot.wim http://${fog-ip}/mdtboot/LiteTouchPE_${arch}.wim boot.wim
boot
Menu show with: All Hosts - Your configuration should now be set to boot MDT via the wim images from within the FOG PXE menu.
-
RE: new NUC hangs on iPXE menu
@sebastian-roth I’ve been meaning to do this for a while: https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe
I have a feeling that we will need this tutorial in a few open threads.
-
RE: Server migration - Name changing issues
@Tom-Elliott said in Server migration - Name changing issues:
Or, and maybe just cause I like the new stuff better, pushing out a GPO remove the old client, and install the new (one time only of course – per machine).
As long as we are just throwing stuff out, this could also be done (for free) with PDQ Deploy. That is what we use for package deployment instead of snapins.
-
USB Boot BIOS client into FOG menu
Why do you need this you may ask?
I can think of two/three situations where you may not be possible to PXE boot computers into the FOG PXE menu.
- The computer is so old or has a really broken PXE boot loader
- Some third party manages your DHCP server or the DHCP server you use doesn’t have the ability to set dhcp options 66 and 67
- Your build in network device (or USB dongle) doesn’t support PXE booting.
The process steps are not hard at all. You will need to acquire these things.
- A 2GB (min) flash drive
- A pxe boot image from https://rom-o-matic.eu/
- Win32 Disk Imager from sourceforge http://sourceforge.net/projects/win32diskimager/
I do have to add this caveat, in that the rom-o-matic servers include the most of the common network drivers. They may not have every possible driver built into this kernel. If you know how to build kernels you may have to download the ipxe source code and build a custom kernel with the specific drivers for your application. In general this method will work for most applications
One time actions for this process
- Download and install the Win32 Disk Imager.
Image creation Process
- From a browser access the rom-o-matic web site at https://rom-o-matic.eu/
- Ensure that “Standard, for most common use” is selected (default)
- Set the “Choose an output format” to “USB Keychain disk image (.usb)”
- Set the “Embedded script” to (in the past your script section).
Be sure to change the ip address of **192.168.1.88** to the actual IP address of your FOG server.
#!ipxe dhcp set next-server 192.168.1.88 set filename undionly.kpxe chain tftp://${next-server}/${filename}
- Set “Which Revision” to “Master” (default)
- Press the Proceed button at the bottom of the page. It may take up to 2 minutes to build this kernel depending on how busy the rom-o-matic servers are at the time you submit your request.
- When your kernel build is done the system should prompt you to download the “ipxe.usb” file. Go ahead and download that file to a known location.
(continued below)
-
RE: Mixed driver environment
@drew_g Boy you have a lot of things going on here that we need to unpack.
-
Lets start out with asking is the FOG server and the target computers on this air gaped network. Are there any other devices on this network? Or to ask my question a bit differently, is this air gaped network specifically for imaging as in we should call this an imaging network?
-
Is the fog server the dhcp server for this isolated network?
-
From the pxe boot files you mentioned are there both bios and uefi computers on this isolated network?
-
-
RE: Server migration - Name changing issues
Here is the post that describes it https://forums.fogproject.org/topic/9103/new-script-to-update-fog-server-s-ip-address
Good job @Wayne-Workman
-
Copy Centos 7 ISO images to usb flash drive
Some systems no longer come with CD/DVD roms, to install Centos 7 on these systems we must transfer the downloaded ISO image to a usb flash (thumb) drive.
- Download Cento 7 from your favorite mirror
- Create a bootable Centos 7 image on the USB flash drive. If you are windows centric user, follow the reference link below that uses Win32DiskImager utility. Since I’m using a Zorin (Ubuntu variant) based laptop I’ll just use the dd command.
ref: http://www.sysadminguide.net/how-to-create-bootable-usb-key-for-centos-7-installation/ - Insert the flash drive into your linux computer.
To determine where the flash drive is mounted issue the following command:lsblk
Your output should look similar to this:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 298.1G 0 disk ├─sda1 8:1 0 294.3G 0 part / ├─sda2 8:2 0 1K 0 part └─sda5 8:5 0 3.8G 0 part [SWAP] sdb 8:16 1 15G 0 disk └─sdb1 8:17 1 15G 0 part /media/johndoe/BEA0-A4EA
- As you can see from the printout my 16GB flash drive is device sdb and its mounted on /media/johndoe/BEA0-A4EA. Armed with this information, we’ll need to first unmount (not remove from the computer) the flash drive before we use the dd command to transfer the image. To unmount the flash drive issue the following
umount /media/johndoe/BEA0-A4EA
- Once the drive has been unmounted I use the dd command to write the iso image to the flash drive. The syntax for dd is
dd bs=4M if=CentOS-7-x86_64-DVD-1511.iso of=/dev/sdX
where X is the device number of the usb flash drive. Get this right or you could overwrite something you might need later. Using the information from the lsblk command I know my flash drive is /dev/sdb so the proper dd command to write the iso image to my flash drive is:sudo dd bs=4M if=CentOS-7-x86_64-DVD-1511.iso of=/dev/sdb
Depending on how fast the flash drive is it may take several minutes to write the iso image to the flash drive. On my laptop this was the output from dd.
1032+1 records in 1032+1 records out 4329570304 bytes (4.3 GB) copied, 521.836 s, 8.3 MB/s
- Remove and reinsert the flash drive into your computer. Your computer should properly mount this flash drive.
- Viewing the contents of the flash drive should be successful.
- Done with the copy, now move the Centos 7 bootable flash drive to the target computer.
-
RE: Mixed driver environment
@drew_g Ok then lets unpack this one first.
Short of dual booting, two different installs of FOG (one for desktop/one for laptop), would there be a possible way to create a script that would switch back and forth between iPXE unidonly and NBP+SPN?
undionly.kpxe is a bios boot loader. It will only run on a bios machine not uefi. So since you are not using bios only uefi is being considered.
Also since you are using fog as your dhcp server it will automatically shift between bios and uefi if you happen to put a bios based computer on this imaging network. You will need to have a bios based captured image because a uefi based image will not boot on a bios computer.
The lenovos in general are a bit finicky, make sure you have the latest bios (firmware) installed on them because that usually fixes strange behavior with pxe booting.
I have a bit cleaner tutorial here on recompiling the latest version of iPXE here: https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe
You can follow the instructions up to step seven, then you can work out a plan on how to integrate the updated versions into your build. What I would suggest is before you move anything rename the original ipxe.efi and snponly.efi to something else. Then copy over just those files from the build dirctory
/root/fogproject/packages/tftp/
that way if something horrible happens you can manually rename the original files back.The difference between ipxe.efi and snponly.efi is that the ipxe.efi contains a built in network driver for every known common network adapter compiled in. The snponly.efi only has one network driver, the snp driver. That driver uses the built in driver that’s part of the efi network adapter. In the beginning < 2 years ago the snp driver was very immature and kind of sucked in most cases. That is why FOG recommended using the more stable ipxe.efi boot loader. The problem with the ipxe.efi boot loader is that new hardware general doesn’t get support for a year or so. Where the snp driver comes with the new hardware and no days doesn’t suck as much.
-
RE: FOG DHCP problems with possible printer interference?
@afriedman We’ll just taking with Joe through chat. What he’s seeing and what I thought I say was too different things.
It would be helpful if you can capture a pcap of the pxe booting process.
Please do the following (assuming your fog server, dhcp server, and pxe booting clinet are on the same subnet).
- Install tcpdump on your fog server
- Launch the tcpdump program with this command
tcpdump -w output.pcap port 67 or port 68 or port 69 or port 4011
- PXE boot the target computer until you get the error
- Press ctrl-c to exit out of the tcpdump program
- Upload the pcap file here for review.
-
RE: USB Boot UEFI client into FOG menu (easy way)
@ITSolutions I created a new tutorial that requires the reader to create a new ipxe boot kernel to do as you want. It did work in my environment here is a link to the tutorial if you want to give it a try. https://forums.fogproject.org/topic/6400/usb-boot-uefi-client-into-fog-menu-harder-way