• Recent
    • Unsolved
    • Tags
    • Popular
    • Users
    • Groups
    • Search
    • Register
    • Login
    1. Home
    2. jms
    J
    • Profile
    • Following 0
    • Followers 0
    • Topics 4
    • Posts 14
    • Best 4
    • Controversial 0
    • Groups 0

    jms

    @jms

    4
    Reputation
    121
    Profile views
    14
    Posts
    0
    Followers
    0
    Following
    Joined Last Online

    jms Unfollow Follow

    Best posts made by jms

    • RE: Detect if PXE client is already iPXE

      @Sebastian-Roth Thanks that all makes sense.

      Thanks Sebastian — from my point of view I could still get rid of TFTP by recognizing either UEFI HTTP Boot (physical hardware) or existing iPXE ROM (in my Nutanix VM) vi DHCP headers (vendor class / user class) and in either case chainload the FOG iPXE binary (with “params” enabled) via HTTP and eventually perhaps HTTPS.

      This should be pretty straightforward, I’ll see if I can work it out and I’ll post back - may be worth a wiki article.

      Now … the next item to tackle would be replacing FTP (vsftpd) with SFTP 🙂

      Feel free to close this thread if it’s no longer appropriate as a “feature request”.

      posted in Feature Request
      J
      jms
    • RE: working-1.6 "Deploy Image" from iPXE menu fails with HTTP Error 5xx

      @Sebastian-Roth Yes it is working now - thank you !!

      posted in Bug Reports
      J
      jms
    • RE: working-1.6 ... During image creation: Updating Database ..... Failed

      Update. I created 2 identical CentOS 7.5 vm’s, configured them 100% identical.

      On on I installed fog from the git clone and on the other I used git to checkout working-1.6 and install. All fog installation parameters were exactly the same for both servers.

      On the regular git cloned fog installation, everything works as expected.

      On the working-1.6, I get the same error as before, after image captured, updating database … failed.

      So I agree, something with 1.6

      I’m happy to help troubleshoot further. I’ll poke around on my own but if there are some things you would like for me to try I’d be happy to participate.

      Thanks !!

      posted in FOG Problems
      J
      jms
    • RE: working-1.6 ... During image creation: Updating Database ..... Failed

      @Sebastian-Roth Yes your fix does indeed resolve the issue for me – thank you sir !!!

      posted in FOG Problems
      J
      jms

    Latest posts made by jms

    • RE: Install to / boot from SAN support (FC, not FCoE)

      Thanks – I will add the Emulex drivers and rebuild the kernel for FOS - I believe that will get me 90% of the way there and I will at least be able to capture/deploy images etc., although I may need to add some user space tools as well (for multipath etc). Can you tell me which Linux distro FOS is based upon - or if it is a completely custom Linux OS in case I need additional user space packages to install or compile?

      I will also post to the iPXE message boards about native FC HBA support or also utilizing the EFI FC HBA driver (already loaded during POST) when wanting to boot directly to the FC LUN from iPXE menu.

      posted in Hardware Compatibility
      J
      jms
    • Install to / boot from SAN support (FC, not FCoE)

      It appears that while iPXE supports FCoE via sanboot, there is no support for traditional FC HBA booting. In my physical server environment, all systems are boot-from-FC-SAN and have no local drives whatsoever.

      Without FC HBA support (Emulex in my case), I don’t believe there is a way for iPXE to boot from the local hard drive from the menu system, as FC HBA drivers simply are not present. FCoE works because it’s over the ethernet adapters which are supported and do have drivers in iPXE.

      rEFInd should be able to go back to UEFI and from there boot from the FC LUN that was attached during EFI POST when the Emulex EFI ROM was loaded – however this is also not working for me. I have not performed any significant troubleshooting steps on this, so it may be possible.

      I am loading iPXE via the server BMC via iPXE ISO, so my workaround there is to simply reboot to the FC LUN after imaging is finished - and this is satisfactory.

      However, my biggest issue is that I cannot create/deploy images using FOG against my FC LUNs, I assume because the FOG OS does not contain Emulex FC drivers and hence the same issue occurs. I’m wondering if anyone here has successfully solved this problem, or if you could point me to the right resource on compiling drivers and creating new kernel/ramdisk for FOG OS that would include the Emulex drivers so that I can at least create/deploy images using FOG? As mentioned, I’m less worried about booting from the FC LUN from the iPXE menu as I am about having an imaging solution in general.

      Thanks !!

      posted in Hardware Compatibility
      J
      jms
    • RE: working-1.6 "Deploy Image" from iPXE menu fails with HTTP Error 5xx

      @Sebastian-Roth Yes it is working now - thank you !!

      posted in Bug Reports
      J
      jms
    • working-1.6 "Deploy Image" from iPXE menu fails with HTTP Error 5xx

      In working-1.6 when I choose “Deploy Image” from the iPXE menu, on a host that is registered, and choose to deploy any image the operation fails immediately with the following:

      http://192.168.X.X/fog/service/ipxe/boot.php... HTTP 5xx Server Error (http://ipxe.org/1d0c6639)
      Cloud not boot: HTTP 5xx Server Error (http://ipxe.org/1d0c6639)
      Could not boot image: HTTP 5xx Server Error (http://ipxe.org/1d0c6639)
      

      The iPXE error URL redirects to a more generic error (1d0c66) that is deprecated and no longer used.

      I did find the following in www-error.log:

      12-Nov-2018 15:02:29 UTC] PHP Fatal error: Undefined class constant 'DEPLOY' in /var/www/html/fog/lib/fog/bootmenu.class.php on line 1271
      

      In an identically configured “working” branch (working-1.5) system, this issue is not present. Additionally in the working-1.6 system, I can successfully schedule a test for an image to be deployed to said host and that tasks executes and completes successfully.

      (By the way - please let me know if there is a better way to submit bugs or if the forum is the right place!!)

      posted in Bug Reports
      J
      jms
    • RE: Detect if PXE client is already iPXE

      @Sebastian-Roth Thanks that all makes sense.

      Thanks Sebastian — from my point of view I could still get rid of TFTP by recognizing either UEFI HTTP Boot (physical hardware) or existing iPXE ROM (in my Nutanix VM) vi DHCP headers (vendor class / user class) and in either case chainload the FOG iPXE binary (with “params” enabled) via HTTP and eventually perhaps HTTPS.

      This should be pretty straightforward, I’ll see if I can work it out and I’ll post back - may be worth a wiki article.

      Now … the next item to tackle would be replacing FTP (vsftpd) with SFTP 🙂

      Feel free to close this thread if it’s no longer appropriate as a “feature request”.

      posted in Feature Request
      J
      jms
    • Detect if PXE client is already iPXE

      This would have the impact of potentially removing the need for TFTP for those PXE clients and using only HTTP or perhaps even HTTPS at some point.

      For example, lets say I have a VM running on Nutanix, which by default uses SeaBIOS and iPXE as the boot ROM. It’s a bit redundant to load undionly.0 and then ipxe.0 and then proceed down the path of booting into the FOG menus.

      It’s fairly straightforward to get an existing iPXE ROM to load a script or menu via HTTP using DHCP …

      ISC DHCP

      if exists user-class and option user-class = "iPXE" {
          filename "http://${next-server}/fog/service/ipxe/boot.ipxe";
      } else {
          filename "undionly.kpxe";
      }
      

      DNSMASQ

      # The dhcp-match sets the ipxe tag for requests from iPXE.
      # iPXE sends a 175 option
      dhcp-match=set:ipxe,175
      
      # The boot filename, Server name, Server Ip Address
      dhcp-boot=tag:!ipxe,undionly.kpxe,,192.168.X.X
      dhcp-boot=http://${next-server}/fog/service/ipxe/boot.ipxe,,192.168.X.X
      

      May also be able to use the DHCP option “user class” in dnsmasq.conf, but the above works just fine. I have only tested in proxy mode but it does work just fine … my DHCP server will be off-limits in production.

      So, trying this I copied over /tftpboot/default.ipxe into /var/www/fog/services/ipxe/boot.ipxe.

      The first thing that happened when dnsmasq sent over boot.ipxe as the file to load, exception thrown because all of the “params” and “param” statements in that file were of course not recognized by my iPXE boot ROM causing an exception and halting any progress. Based on a quick look through boot.php in the ipxe directory and then other php code further up the chain (bootmenu.class.php etc), I assume these are PHP arrays and variables. Of course, the FOG-provided chain loaded iPXE ROM seems to load just fine - so perhaps “default.ipxe” is the wrong place for me to start … I’m still digging around 🙂

      Now, if I trim back boot.ipxe (default.ipxe) to instead contain only the following, I successfully boot to the FOG menu … however it has no styling or background PNG, only plain ncurses type PXE menu but all of the standard FOG options are there.

      #!ipxe
      cpuid --ext 29 && set arch x86_64 || set arch ${buildarch}
      chain http://${next-server}/fog/service/ipxe/boot.php?mac=${net0/mac}
      

      Now from here all I tried to do was click on the deploy image option and again I was given an exception stating that “params” was an unknown.

      I’m going to continue to poke around, because obviously FOG is already working properly via iPXE once it’s chain loaded from undionly. So, I believe this may not require much in the way of codebase change, but perhaps configuration change.

      As a side note, for physical hosts my plan would be to utilize UEFI HTTP Boot to load the iPXE ROM (vs using the Intel hardware PXE ROM) and then loading up the same boot.ipxe script via HTTP as shown above. Goal would be to eventually move all of this to HTTPS, but … baby steps!!

      If you have any quick tips about where to look next that would be appreciated. I think as you look to the future and using UEFI HTTP(S) Boot and removing the hard requirement for TFTP for that initial undionly.0 for folks that may not want TFTP installed, this could be a good feature request.

      posted in Feature Request
      J
      jms
    • RE: working-1.6 ... During image creation: Updating Database ..... Failed

      @Sebastian-Roth Yes your fix does indeed resolve the issue for me – thank you sir !!!

      posted in FOG Problems
      J
      jms
    • RE: working-1.6 ... During image creation: Updating Database ..... Failed

      @Sebastian-Roth I tried against “working” branch (1.5.x working), setup identically to the other 2 VMs and fog installations, and it works flawlessly, same as stable (head? – sorry I’m not that up to speed on git terminology!) … so, seems the issue lies squarely in working-1.6

      Happy to continue to test and debug - just let me know how I can help.

      posted in FOG Problems
      J
      jms
    • RE: working-1.6 ... During image creation: Updating Database ..... Failed

      Update. I created 2 identical CentOS 7.5 vm’s, configured them 100% identical.

      On on I installed fog from the git clone and on the other I used git to checkout working-1.6 and install. All fog installation parameters were exactly the same for both servers.

      On the regular git cloned fog installation, everything works as expected.

      On the working-1.6, I get the same error as before, after image captured, updating database … failed.

      So I agree, something with 1.6

      I’m happy to help troubleshoot further. I’ll poke around on my own but if there are some things you would like for me to try I’d be happy to participate.

      Thanks !!

      posted in FOG Problems
      J
      jms
    • RE: working-1.6 ... During image creation: Updating Database ..... Failed

      Ok, that page has some useful tips, although the mysql portion(s) are a bit circular regarding the number of different mysql users required. Is there a single mysql user/pass for everything in fog, or is the storage node mysql credentials different?

      I did not set a password for mysql during installation.

      .fogsettings shows no user/password/host for snmysql*

      Web UI shows a user of “fogstorage” along with a password for FOG_STORAGENODE_MYSQLUSER/MYSQLPASS

      config.class.php shows a user of “root” and no password under function _dbSettings, and shows user “fog” with the correctly set password for STORAGE_FTP_USERNAME/PASSWORD, as set by passwd for the Linux system user “fog”

      When I run the mysql credentials test with no user/pass against the fog db it works fine, but when I try against the storage user listed in the Web UI I get the following …

      [root@fogsrv ~]# mysql -U fogstorage -pPASSWORDHERE -D fog
      ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES)
      
      posted in FOG Problems
      J
      jms