@zaqen The way I build the one off kernels are a bit different than the FOG Devs do it but it works. On your linux distro you need to install the buildessentials package. You can probably google building kernel on your linux distro to get all of the required packages.
Copy kernelx64.config from your home directory and save it as .config in the base directory of the kernel you extracted.
Issue the make config or make nconfig command from a linux command prompt to build and load the kernel config editor. Once the editor load look for any warning messages about legacy/old settings or configs. If the menu loads cleanly then save the settings even if you haven’t changed anything and exit the menu config.
The last bit is to just issue the make command to build bzImage. (the kernel).
What I can tell you is that FOG has the ability to run a bash script after the image has been pushed to the target computer and before the computer reboots after completing the deployment. You can use this feature to tweak settings on the target computer before the computer is first booted into the target OS. This is used commonly with the windows environment to place hardware specific drivers onto the target computer that is used during the OOBE/WinSetup phase of windows. In linux we’ve used these scripts to rename linux computer and do some post install activities.
The FOG imaging agent is Linux based so it can’t directly interact with ms windows, but it can leave bread crumbs behind for windows to act upon. For linux target computers it can do more things. I can’t say if it can run grub commands though.
The concept of the fog post install script is that the script will need to mount the target computer media/file system, do whatever is needed then disconnect from the target media.
@sebastian-roth Thank you for the response! I’m assuming I should keep EXT4. I haven’t updated this thing in a while. I was planning to take a snapshot first but wanted to have a little better clarity. I’m running 1.58 so I will also update to 1.5.9 as well.
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?
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!
Hello, I came to this topic because I was having this same issue with some new Dell computers that arrived here where I work, in my case I didn’t needed to repair the grub, but I could solve this by changing some bios configuration where there’s a option to add uefi boot option and there appears the .efi file of the grub and mark it to boot first. Hope it helps!
The problem I have now is that the original machine is 34 GB and the cloned machine is 54 GB and there is unallocated disk space left. How could I extend the encrypted partition to fill the entire disk?
Now that part will definitely take some more work on the inits as we’d need to rework the resize functions and add LVM support. @Wayne-Workman said her might look into this but will take time.
That way we can book to windows using exit to refind, and exit to GRUB UEFI for ubuntu.
You are on the right track on the other thread. The two refind options are what you need. This way you can target where refind looks for the boot files. You can include and exclude file paths to get what you need.
The grub4win implementation inside fog is bios only. BUT that’s not to say you couldn’t use a similar concept to the dual refind hack to leverage grub too. There are a few ways to go about it. I don’t have to deal with dual boot so I’ve never looked into streamlining that flow.
and set the vendor class to PXEClient:Arch:00007
is that the right vendor class for an intel nuc?
I can’t answer that. I can tell you it will either be type 7 or 9 for 64 bit uefi computers.
If you want to find out what type the nucs are setup wireshark on a witness computer (second computer on the same subnet). Run a capture filter of port 67 or port 68 PXE boot the target computer. In the Discover packet sent out by the target computer, in the dhcp option 93 or 94 (sorry can’t remember at the moment) the target computer tells the dhcp server what type it is.
I completed the upgrade without any major problems.
I had to reinstall some php packages that had been removed during the upgrade
(the comparison between the packages installed on the old version and the new one allowed me to reinstall them easily)
Also, unrelated to fog, I had to review the configuration of mariadb and more particularly the authentication mode of the “root@localhost” user.
Indeed the user “root@localhost” was still using authentication with a password, but the new method is to use auth_socket :