• Recent
    • Unsolved
    • Tags
    • Popular
    • Users
    • Groups
    • Search
    • Register
    • Login
    1. Home
    2. Zer0Cool
    Z
    • Profile
    • Following 0
    • Followers 0
    • Topics 21
    • Posts 148
    • Best 10
    • Controversial 0
    • Groups 0

    Zer0Cool

    @Zer0Cool

    11
    Reputation
    555
    Profile views
    148
    Posts
    0
    Followers
    0
    Following
    Joined Last Online

    Zer0Cool Unfollow Follow

    Best posts made by Zer0Cool

    • Single iPXE Menu Entry for Both BIOS/UEFI

      FOG version: 1.5.2

      As I have been learning and using FOG I realized some options can only be used when the host has been booted BIOS or UEFI. For example, the included Memtest86+ can only run when the host was BIOS booted. Trying the menu option when UEFI booted results in errors. Alternatively, as per this post here, ESXi would only be supported out of the box when UEFI booted. I am sure there are many other examples of this.

      It may also be that the parameters under BIOS and UEFI are just different. In other words the OS/Installer can run under either, but requires different parameters.

      What I have found is its possible to use a single iPXE menu entry to cover using different parameters depending on how the host was booted. This is all done via the web GUI under Settings | iPXE Menu Item Settings (or for new entries ‘iPXE New Menu Entry’.

      I altered the default fog.memtest entry, parameters field for example to the following:

      iseq ${platform} pcbios && goto mem_bios || goto no_mem
      :mem_bios
      kernel memdisk initrd=memtest.bin iso raw
      initrd memtest.bin
      boot || goto MENU
      :no_mem
      prompt --timeout 30000 Host must be BIOS (not UEFI) booted for this option. Press any key to return to the menu... && goto MENU || goto MENU
      

      The first line tests if the host was BIOS booted, if so it jumps to the ‘mem_bios’ label and executes the commands under that label, otherwise it goes to the ‘no_mem’ label and instead displays a prompt explaining why its not an option and then returning to the menu thus avoiding the error.

      This results in 1 menu entry that changes behavior based on how the host was booted. I might even go as far as including in my entry descriptions some syntax/indicator of its compatibility, IE: “Memtest86+ (BIOS only)” so that its obvious to users without selecting it that it can only be used when BIOS booted.

      Another example is my ESXi entry:

      iseq ${platform} efi && goto esxi_efi || goto esxi_bios
      :esxi_efi
      kernel http://${fog-ip}/fog/os/esxi65/efi/boot/bootx64.efi -c http://${fog-ip}/fog/os/esxi65/efi/boot/boot.cfg
      boot || goto MENU
      :esxi_bios
      prompt --timeout 30000 Host must be UEFI booted for this option. Press any key to return to the menu... && goto MENU || goto MENU
      

      Similar to the above but the 1st line does the reverse test, is the host UEFI booted. The ‘:esxi_bios’ label and its commands could be altered as seen below if, for example, you compiled the ipxe kernel to include IMG_COMBOOT to support BIOS booting ESXi:

      iseq ${platform} efi && goto esxi_efi || goto esxi_bios
      :esxi_efi
      kernel http://${fog-ip}/fog/os/esxi65/efi/boot/bootx64.efi -c http://${fog-ip}/fog/os/esxi65/efi/boot/boot.cfg
      boot || goto MENU
      :esxi_bios
      kernel http://${fog-ip}/fog/os/esxi65/mboot.c32 -c http://${fog-ip}/fog/os/esxi65/boot.cfg
      boot || goto MENU
      

      In the above, we load ESXi one way if the host is UEFI booted and another if it was BIOS booted.
      [Moderators Note]: I want to restate again that the mboot.c32 syslinux script will not boot using FOG Project supplied iPXE boot loaders (i.e. undionly.kpxe) since they are not complied by default with COM_BOOT enabled. YOU must compile the iPXE boot loader if you want syslinux support -Geo


      I have so far only tried this with memtest and ESXi.

      I also would love to see an option for a menu to be displayed or not based on this variable, IE: show the memtest86+ entry only when BIOS booted but not when UEFI booted, but have not found a way this is possible yet. Maybe the devs have some ideas as to if this is feasible?

      I think that could really help make the menus a bit more flexible/dynamic. It could potentially be a set of check-boxes in the GUI for the menu entry: “BIOS”, “UEFI” or “Both” which would dictate if the menu entry is included for a host given how it was booted. Alternatively, maybe somehow tied into the ‘Menu Show With’ option.

      In any case hopefully others find this useful.

      posted in Tutorials
      Z
      Zer0Cool
    • RE: Permissions on /images NFS share

      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.

      posted in General
      Z
      Zer0Cool
    • RE: iPXE Fedora 28 Workstation Boots Live, Not Installer

      @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.

      posted in Linux Problems
      Z
      Zer0Cool
    • RE: ESXi PXE Boot PSOD/Crash

      @george1421 I can confirm ESXi 6.7 installs and boots without an issue.

      I am going to proceed with mounting the ISO on the server for 6.5, copy its contents over into the proper place again, and see if it resolves anything.

      If not, I am going to chalk it up to a compatibility issue between the R620, iPXE and ESXi 6.5 U1.

      posted in FOG Problems
      Z
      Zer0Cool
    • RE: Integrating clonezilla into fog

      Here is my entry, this just boots up as if you put the disc in the host, should work UEFI or BIOS. I just did a new iPXE entry from the web GUI and placed this in the parameters.

      kernel http://${fog-ip}/os/cz/live/vmlinuz
      initrd http://${fog-ip}/os/cz/live/initrd.img
      imgargs vmlinuz initrd=initrd.img vga=791 boot=live union=overlay components noprompt edd=on nomodeset nosplash config locales=en_US.UTF-8 keyboard-layouts=NONE fetch=http://${fog-ip}/os/cz/live/filesystem.squashfs ocs_prerun="" ocs_live_run="" ocs_live_batch="no"
      boot || goto MENU
      

      I have the Clonezilla CD contents at ${fog-ip}/os/cz/live which I have pointed httpd/apache to. You can replace http with tftp or whatever protocol you use for PXE booting.

      Clonezilla has a list of parameters someplace that I used to help me work out the menu.

      I am sure you have a good reason for using Clonezilla or wanting it, would you mind if I asked why?

      I have it for old images captured using Clonezilla while I transitioned to FOG, but honestly dont need/use it anymore.

      posted in General Problems
      Z
      Zer0Cool
    • RE: Proper Way to Upgrade FOG?

      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.

      posted in General
      Z
      Zer0Cool
    • RE: HTTP Redirects After Upgrade 1.5.2 to 1.5.3

      @quazz Alright that appears to work. symlinks in /var/www/html are working. Thank you!

      @quazz said in HTTP Redirects After Upgrade 1.5.2 to 1.5.3:

      @zer0cool I think it will redirect anything with url/fog so try going one directory higher.

      Since I appear to be unable to mark moderators responses as the solution I have quoted your solution and will mark this solved. Thanks!

      posted in FOG Problems
      Z
      Zer0Cool
    • RE: Proper Way to Upgrade FOG?

      @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

      posted in General
      Z
      Zer0Cool
    • RE: New Fog Install, No Fog on Boot

      @scojo said in New Fog Install, No Fog on Boot:

      I am unable to get the FOG menu to show up.

      Can you clarify this in specific terms, what does happen is more helpful than what doesnt happen.

      • Does DHCP assign an IP?
      • Does iPXE pull down the NBP file?
      • Do you get an error?
      • Does the computer do something after not presenting the menu? (beep, reboot, show something else, power off, etc)
      • Do you have SELinux set to permissive mode?

      What machines are you trying (make/model), what GPU are they using, how is the monitor connected (HDMI, DP, DVI, etc)?

      @george1421 said in New Fog Install, No Fog on Boot:

      Remember the prerequsites are to disable the OS’ firewall

      I dont know about for other OS’s, but not CentOS 7. The instructions provide directions for opening the proper ports/services.

      posted in FOG Problems
      Z
      Zer0Cool
    • RE: FOG Client Unable to Decrypt AES Error

      I re-deployed my image to the host so that I could see the log from deployment to when it stops working.

      It appears as if the FOG client works just fine during hostname change, Windows activation, joins the domain/reboots and even runs my snapin assigned to the host which deletes the local user, does a gpupdate /force and reboots again. After that point I get the log posted above and it seems the FOG client cannot properly authenticate.

      It appears as if it is able to reach the server as it gets the CA cert, but on the line Middleware::Communication POST URL: http://10.0.0.2/fog/management/index.php?sub=requestClientInfo&authorize&newService It then seems to fail with a message regarding being unable to decrypt AES.

      I have tried multiple times doing the encryption reset option in the web gui for the host to no avail.

      Not sure what I am missing here, any help would be great. Thanks

      posted in FOG Problems
      Z
      Zer0Cool

    Latest posts made by Zer0Cool

    • RE: Script/Program to Batch Copy ISO Contents for PXE Boot?

      I actually made some progress on this front. It became a bit more clear when I thought it over and made some considerations.

      My setup is such that I have mirrored (via rsync) local repos of CentOS and Fedora. I then symlink the ISO’s within those repos to another place to make them easy for people to download the ISO. In this scenario I don’t have to do anything with the ISO to get the installation files need by PXE as they are available in the repo as I have syncd them.

      With the above in mind, I should be able to accomplish the same for any Linux distro that I can mirror/rsync locally which nullifies the needs/goals of my OP.

      I then thought about what OS’s this need actually applied to, and in my case it came down to Windows 10 and ESXi (various versions). I don’t mind downloading the ISO manually. What I was looking to accomplish was being able to take an iso or a batch of them in a dir and identify their; OS, version, build, revision and be able to use that to create a unique directory structure for said iso and then dumb the iso contents into the created dir structure for it.

      The part I was hung up on was how to get the information I needed for this and that part, at least for Windows 10 (really any Windows ISO) and ESXi I have figured out at least as a proof of concept. I realized that the iso file name would not be the most reliable method of doing so and found ways unique to each OS family to identify the metadata I needed.

      ESXi (having checked multiple Dell isos from 6.5-6.7):

      I found that they had a /upgrade folder with 2 note worthy files in them. metadata.xml contains the version number and build number. profile.xml has the full name (so even if the file name of the iso is changed this should stay the same) from which I could extract things like the Dell revision and U1/U2 monikers used for Update 1 and Update 2, etc. It also has a tag for “creator” so I should be able to differentiate between Dell isos and non-dell isos.

      To parse out the xml I found that xmllint provided by libxml2 would allow me to reliably pull this info from the xml files. Coincidentally, libxml2 was needed by wimlib anyhow (mentioned below for Windows).

      Windows 10:

      I installed wimlib and using the wiminfo command on the install.wim (combined with grep) I am able to pull information about the ISO as well as deduce if the ISO is a Windows ISO. I can get name, version, build number in this fashion.

      I may expand this to Server 2016/2019 if they start releasing new iso builds “frequently” like they do with Windows 10, but older versions the iso hasnt changed for a long time and I have these setup already.

      So basically it comes down to checking the ISO’s for the structure/files that match the OS family. In this case /upgrade/metadata.xml being ESXi and /sources/install.wim being Windows. Then I either parse out the XML for ESXi or using wiminfo pull the info from the wim file for Windows.

      After that should be “easy”. Create a path using that info, check if it already exists, dump the iso contents, unmount, etc. I am also considering putting a fail safe kind of option in so that if the ISO doesnt match any conditions I am checking to “classify” it, I can prompt the user for manual input if they want to process the ISO allowing them to determine the path to dump it into.

      Follow Up Question:

      I hadnt considered it before, but generally speaking I assume it would be possible via the bash script to also update or add to the FOG’s iPXE menu by manipulating the “config” file that stores the menu? Or is there a database in between that would make that problematic?

      I am not stuck on automating the menu creation but if its a relatively simple addition might as well add it.

      Conclusion:

      Once I get this written up into a moderately working fashion I intend to post it on my Github and would be happy to share the link back here.

      Thanks

      posted in General
      Z
      Zer0Cool
    • Script/Program to Batch Copy ISO Contents for PXE Boot?

      This isn’t really FOG specific, though it will help me in my use of FOG (and maybe others). If it isn’t appropriate to ask here please feel free to close the thread, my apologies.

      I was wondering if anyone knows of a script or tool for automating the process of preparing the OS dirs/content needed to PXE install and OS.

      What I mean is, before ever getting to creating the iPXE menu entry, one would typically mount an OS iso and copy its contents to a directory on FOG.

      What I am finding is that I often need to repeat this process as new versions of OS’s come out and generally check every couple of weeks/months so I end up finding multiple OS’s with new versions. Its then a laborious process to manually create each destination dir/subdirs, mount the iso, copy the contents, unmount the iso and repeat.

      I am considering trying to write a bash script to help automate this but figured I would ask before diving in in case someone else has already addressed this.

      So, essentially what I would like to accomplish is to point something to a dir and have it process all the iso’s in the dir such that:

      • Each iso has a folder created for it according to its OS/ver. IE: win/7 or esxi/6.5 A01
      • Each iso is mounted and its contents copied to the right directory for it then unmounted.

      From my perspective, the tricky part in a bash script would be how to identify each iso and properly “categorize” it to create the desired dir/subdirs.

      I have searched online to see if a tool for this exists but couldnt find one, maybe its just not feasible?

      I dont mind updating the iPXE menu entries (or creating new ones) manually in FOG, but processing the isos is starting to be a chore I feel automation could address.

      Thanks

      posted in General
      Z
      Zer0Cool
    • RE: FOG DHCP Server on Multiple VLAN Network

      @george1421 Hey Thanks for the reply. To answer your question, we do not use any other DHCP server currently. All IP’s on other VLANs are set statically. The only DHCP server is the FOG server.

      I know it sounds dumb, but in my environment, it makes sense for many reasons.

      As you have explained it, am I to understand that I need another DHCP server aside from the FOG server to make this work? If not, does it make it any easier?

      I am open to any suggestions that would make it possible (preferably easy) to have FOG (or a “helper” DHCP server) be able to work across VLANs.

      Thanks

      posted in General Problems
      Z
      Zer0Cool
    • FOG DHCP Server on Multiple VLAN Network

      FOG 1.5.3
      CentOS 7.5
      Run as a VM in ESXi 6.7 free
      FOG uses a single virtual NIC (typically)

      FOG is the only DHCP server on any of the desired VLANs I know of. I do use 2 other servers for DNS. Otherwise the FOG server is self sufficient. Everything works as expected for hosts on the same VLAN/subnet as the FOG server.

      Goal
      I need to get FOG to PXE boot and be able to image/capture from hosts on multiple VLANs/subnets. Its not an option for me to put everything on the same VLAN.

      Setup
      I have a physical network that’s structured as follows:

      1. Palo Alto Firewall
      2. Juniper Switch
      3. Arista Switches
      4. Hosts

      I have the following VLANs/subnets:

      • 100/10.0.0.x - FOG is 10.0.0.2 on this vlan and works when physical and virtual hosts are on the same vlan
      • 1600/172.16.0.x - Many hosts on this vlan.
      • 1605/172.16.5.x - Many virtual hosts (VM’s) on this vlan.

      The 100 VLAN can cross communicate with all other VLANs, setup under the settings in the Palo Alto (rules, zones, etc). IE: its possible to ping across VLANs, SMB, etc.

      I am currently not concerned with making any other VLANs work with FOG but it would be nice to be able to expand to include others in the future.

      Things I Tried
      I started by creating a DCHP Relay agent on the Palo Alto and editing the dhcpd.conf file to include another subnet section. This alone ended up with the closest to working I got. Hosts on 1600 for example would PXE boot, get the proper IP address from the proper subnet but would then give a PXE error, I think #11 regarding ARP (PXE-E11: ARP Timeout). At this stage they would just give the option to press a key to reboot.

      I then took steps to try and configure Juniper/Arista switches to also handle DHCP relay with no luck, 0 change in the outcome.

      I also tried adding another virtual NIC to FOG, placing it on another VLAN/subnet and ran into odd issues, eventually I think coming down to TFTP being assigned a static/single IP address in the FOG gui/settings. The first problem with this was that the original NIC on 10.0.0.x seemingly stopped working for everything expect PXE booting (ping, network, internet all stopped working) while the new NIC on 172.16.0.x worked as expected. Disabling the new NIC (in CentOS) would make the 1st NIC instantly start working completely. Machines PXE booted on the second new VLAN would get a little further than before but are unable to load the boot files as TFTP still appears to try loading them from the original IP/vlan address on 10.0.0.x and fails.

      So I am not sure whats easier to correct, the ARP timeout when using DHCP Relays or the issue of TFTP not using the IP/vlan of the NIC on FOG matching the hosts VLAN/subnet.

      Final Thoughts
      I am open to any solution that can get this working or at least an explanation of the limitations of FOG in a setup like this, as I imagine its possible I am just trying to do something that shouldnt be done. For what its worth I have been through our wiki, many hours of research on Google and trying to iron this out with the help of multiple co-workers and we are stumped.

      I have tried to provide as much relevant details as I can and will be happy to provide more to the extent that I am allowed.

      Thank you for any help or guidance you may be able to provide.

      posted in General Problems
      Z
      Zer0Cool
    • RE: Integrating clonezilla into fog

      Here is my entry, this just boots up as if you put the disc in the host, should work UEFI or BIOS. I just did a new iPXE entry from the web GUI and placed this in the parameters.

      kernel http://${fog-ip}/os/cz/live/vmlinuz
      initrd http://${fog-ip}/os/cz/live/initrd.img
      imgargs vmlinuz initrd=initrd.img vga=791 boot=live union=overlay components noprompt edd=on nomodeset nosplash config locales=en_US.UTF-8 keyboard-layouts=NONE fetch=http://${fog-ip}/os/cz/live/filesystem.squashfs ocs_prerun="" ocs_live_run="" ocs_live_batch="no"
      boot || goto MENU
      

      I have the Clonezilla CD contents at ${fog-ip}/os/cz/live which I have pointed httpd/apache to. You can replace http with tftp or whatever protocol you use for PXE booting.

      Clonezilla has a list of parameters someplace that I used to help me work out the menu.

      I am sure you have a good reason for using Clonezilla or wanting it, would you mind if I asked why?

      I have it for old images captured using Clonezilla while I transitioned to FOG, but honestly dont need/use it anymore.

      posted in General Problems
      Z
      Zer0Cool
    • RE: FOG 1.6 Testing Needed - Help would be greatly appreciated as needed

      @tom-elliott said in FOG 1.6 Testing Needed - Help would be greatly appreciated as needed:

      I know you all have been hearing about our work on 1.6 and maybe even our “kind of” roadmap with 1.7, 1.8, 1.9, and 2.0.

      Is there any specific place we can check this info out? I would be interested to read about future plans. Thanks

      posted in Announcements
      Z
      Zer0Cool
    • RE: Keys Disappear on Multi-cast?

      Forget it, sorry to waste anyone’s time. Redoing it has worked on all machines. I am guessing applying just the snapin via group wiped the key fields for each host.

      posted in FOG Problems
      Z
      Zer0Cool
    • Keys Disappear on Multi-cast?

      FOG 1.5.3
      CentOS 7.5

      I am not sure if this is a known issue, an unknown issue or simply my own fault.

      I have 7 hosts registered. For each one set the key, clicked update, then went back to the hosts list, back to the updated host and verified the key was in the field. I then followed the same process for enabling a snappin on each and setting domain join on each.

      After having done that for all 7, I added all 7 to the same brand new group. From the group I applied the same snappin previously applied to each via the group and made no other changes/updates independent or via the group.

      I then did a multicast via the group and sent the same Windows 7 image to all the machines. I used an 8th machine already imaged from this image (literally solo deployed the image to it prior) to run the task via the web GUI. Its worth mention that the 8th machine was imaged and worked just fine.

      The 7 host machines went through the entire imaging process including joining the domain and running my snapin but did not activate Windows with the keys I had previously provided. Going back to check each host in the web GUI and none of the 7 have a key in the field now.

      I am hoping I just made a dumb mistake in how I executed my process (likely something to do with doing the keys before using the group to update something else), but its possible this is similar to the bug I found/helped find with the iPXE descriptions not being saved on creation (updates stuck, but initial creation would not save this field) in a prior version of FOG.

      I have assigned the keys 1 by 1 to all 7 hosts again, verified that they are in the field and also exported the key list from reports. This all checks out. I am going to re-image the same 7 machines using multi-cast again and see if the result changes or if it happens again. I will report back my findings in case this is a bug.

      Any input is welcome, as I am working on 0 sleep now its possible I will make more mistakes 😕

      posted in FOG Problems
      Z
      Zer0Cool
    • RE: FOG 1.5.4 Windows 7 UEFI Image Capture

      @ty900000 Was a permissions issue for me, had nothing to do with TZ

      https://forums.fogproject.org/topic/12048/unable-to-install-kernel-4-17-0/22

      posted in FOG Problems
      Z
      Zer0Cool
    • RE: iPXE Setup For Many OS's Under BIOS and UEFI

      CentOS 7.4 and 7.5

      Works with: UEFI or BIOS

      To start we need the installation files in our /tftpboot/os/centos directory. This can be done by manually copying the required content from a CentOS iso or by using rsync to sync from an online mirror. A list of official mirrors with rsync links can be found here. The following will presume the latest version of CentOS (at this time 7.5.1804) but altering the version to your desired version in the steps should work.

      You do not have to do the steps in BOTH “Using Files from ISO” and “From rsync”, its one or the other.

      Using Files from ISO:

      1. Create the directory for CentOS/version if it doesnt already exist:
      mkdir -p /tftpboot/os/centos/7.5.1804
      
      1. Mount the ISO and copy the required files to the above directory:
      mount /{path to the iso}/filename.iso /mnt/iso/
      cp -R /mnt/iso/* /tftpboot/os/centos/7.5.1804
      umount /mnt/iso
      

      Using rsync:

      1. Do not create the subdirectory for the CentOS version, just have /tftpboot/os/centos ready, rsync will create the subdirectory.

      2. run the rsync command using a rsync url from the list of mirrors you want to use. This can take hours to run:

      rsync -avzP --log-file=/var/log/rsync_cron/rsync_yum_mirror.log --delete --include="/7.5.1804" --include="/7.5.1804/**" --exclude="*" rsync://mirrorurl/centos/7.5.1804/os/x86_64/ /tftpboot/os/centos
      

      feel free to change the path/name of the log file. I use this rsync to also pull updates allowing me to use my FOG server as a local YUM repo as well. If interested in doing so change the rsync path to be rsync://mirrorurl/centos/ instead. This will make the amount of data downloaded much greater, but will later let you use the FOG server as a YUM repo. I placed the rsync command above in my crontab -e without the -P switch for rsync and have it sync once a day. Doing so is a bit beyond the context of this guide though.

      Also note that if the mirror is down the command can fail, you may need to switch to another mirror or if setting up cron having it sync multiple mirrors just in case.

      Adding iPXE entry:

      From the FOG web GUI, create a new iPXE entry (or edit an existing one) as follows:

      1. Menu Item: name as desired (ex: os.centoslatest)
      2. Description: as desired (ex: CentOS 7.5.1804 - Install). Note: This is what is seen in the iPXE menu on the host machine!
      3. Parameters:

      Manual or rsync without wanting YUM server too:

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

      With rsync pulling all data for YUM:

      kernel http://${fog-ip}/os/centos/7.5.1804/os/x86_64/images/pxeboot/vmlinuz
      initrd http://${fog-ip}/os/centos/7.5.1804/os/x86_64/images/pxeboot/initrd.img
      imgargs vmlinuz initrd=initrd.img root=live:http://${fog-ip}/os/centos/7.5.1804/os/x86_64/LiveOS/squashfs.img repo=http://${fog-ip}/os/centos/7.5.1804/os/x86_64
      boot || goto MENU
      
      1. Menu Show With: as desired.
      2. Save changes

      Alternate directions here.

      posted in Tutorials
      Z
      Zer0Cool