SOLVED Chaining FOG from ipxe.efi (x64)

  • Hello fog,

    Currently i’m busy implementing the Fog Project in our enviroment.
    This enviroment is a mixed one (Legacy x86, Legacy x64, UEFI x86 and UEFI x64).

    We use a Debian Wheezy as our fog and DHCP server and use IPXE as our default boot menu.
    I’m booting to fog using the “var/www/fog/service/ipxe/boot.php”

    I’ve noticed that for Legacy x64, I have to rename bzImage and init.xz to their x32 equivalents (bzimage32 and init_32.xz) because the default boot.php always selects the 32 version of the files… (–> way to circumvent this?)

    However, the ipxe64.efi and ipxe86.efi files both end up with a Kernel Panic…
    I can find a lot of Kernel Panics on google, but all topics are 2 to 3 years old…
    What files do I need to boot to support UEFI? booting to legacy is not an option on these devices.

    Thanks in advance,


  • Senior Developer

    @abos_systemax said:

    I believe you, but theory and practice are different beasts 🙂

    Sure they are! That’s why I suggested to give FOG trunk a try! Kernel 3.19.3 might boot some of your UEFI machines but will fail with those having more recent NICs! This is not just a theory. We have seen different people posting about those issues several times a week in the last months!

  • @george1421
    it’s off topic on the initial topic, but it’s very relevant on the later part of this topic. Giving your KB a read and its a very interesting read.

  • Moderator

    (I understand this is a bit off topic) This isn’t meant as a negative statement at all, but I’m old school unix and I don’t like the default layout of putting everything in the root file system. For just the reason Wayne mentioned. If you fill up the root partition you will typically whack your OS so badly the only fix is a complete reinstall. The FOG software doesn’t know how big the client its backing up is, so there is no way to tell if the root filesystem will be consumed on the next upload.

    With that in mind we never put transient data on the root file system (or the 😄 drive in the windows genre) for that reason. I did create a right up on how to relocate all of the transient data onto its own disk (vmdk). That way if the images fill up the images disk the OS will still continue to run and give you the ability to fix the issue instead of just crashing horribly.

    Here is the kb I wrote on this.

    Also by placing the images on there own disk (vmdk) you can grow the disk as required without worrying about stepping on an adjacent partition (same with windows).

  • @Wayne-Workman
    eventually we will store our images on a SAN, so the partitions should not be that much of an issue. However, if it somehow makes a difference then we will definitely have to consider all options. Since we will have multiple customers and lots of images in the future, speed and efficiency are the two major things to take into account.

    I’ll check out the guides on CentOS and Fedora as you mentioned. Thanks for the heads up.

  • @abos_systemax said:

    @Tom-Elliott We are one of them people…(we setup the LVM with everything on one partition) Mostly because I do not know any best practices in terms of this setup.
    Does FOG has a ‘best practice’ in terms of disk layout and setup? As said, we are still busy with the initial implementation and everything tackled in this phase is a job done.

    the CentOS 7, Fedora 21, and Fedora 23 tutorials in the Wiki outline a partitioning scheme.

    Putting everything on one partition will only cause disaster in the future if the drive fills up, and it will suck severely.

  • @abos_systemax The fog server is the server that things will be on, so the “defaults” of installation are usually fine. It’s the systems you need to image that need more care taken for what you want/need.

  • @Tom-Elliott We are one of them people…(we setup the LVM with everything on one partition) Mostly because I do not know any best practices in terms of this setup.
    Does FOG has a ‘best practice’ in terms of disk layout and setup? As said, we are still busy with the initial implementation and everything tackled in this phase is a job done.

  • @abos_systemax When you install any Linux OS you have the option to setup your partitioning scheme and types as you see fit. The problem is that most just go with the defaults.

  • @Tom-Elliott

    Since we are still busy with our test environment, and nothing is set in stone: are newer versions of Debian a better solution; or do we have to look to different Linux OS’ses to support Fog 1.3.0 (and multicast traffic(!)) without having to resort to RAW image data?

  • @Sebastian-Roth

    Thank you, i’ve updated the kernel to 3.19.3 (was 3.15).
    Will check Monday if it’s bootable in UEFI. (I believe you, but theory and practice are different beasts 🙂 )

  • @abos_systemax I can tell you, with relative certainty, that it will work with debian wheezy. LVM Setups may have a bit of a harder time as it will upload in raw format, but if your filesystem is setup with ext (2,3,4) and/or ntfs you will be fine.

  • @Tom-Elliott
    I’ve found the file that is responsible for the ${arch} variable; the reason it wasn’t working with my setup was because the arch it was expecting is x86_64; and the arch i’m passing is x64… so the x32 was always the file getting served.

    Thank you for the push in the right direction; I was staring myself blind at the problem.

    I’ll definitely check out 1.3.0 and see if it works on Debian Wheezy

  • Senior Developer

    @abos_systemax The kernel panic you are seeing is due to the FOG 1.2.0 default kernel (can’t remember the version right now but you can check with command file /var/www/fog/service/ipxe/bzImage* on your FOG server) does not have the so called EFI_STUB yet! Please update the kernel (web gui -> FOG configuration -> Kernel update) and you should be able to boot UEFI devices!

    That said I totally agree with what Wayne told you already. FOG 1.2.0 is not very good at handling newer devices and I am sure you will run into trouble soon. I’d suggest try FOG trunk and maybe spend a few hours with one of the latest introduced bugs but save yourself days (if not weeks) of work trying to make 1.2.0 work for all your devices (compiling your own iPXE binaries is just the tip of the iceberg really!!).

  • @Tom-Elliott

    AH! that’s it… I need to pass the ${arch}…

    stupid little me 😉 thnx!

  • How about I chime in here.

    FOG, since at least 1.0 (if I recall), did recognize architechure of the devices connecting.

    It will ONLY hand out init_32.xz and bzImage32 if the arch is NOT 64. If it’s 64 the files it hands out will be named init.xz and bzImage. If you replaced these files with 32 bit variants, there’s not a thing I can do for it.

    If you modified your own ipxe setup script, it’s likely missing the passing of the arch to the boot.php.

  • @Wayne-Workman

    My ‘problem’ here is that I already supply the right ipxe based on the architecture via DHCP; however, the boot.php file does not recognise this apparently, because it always distributes the x32 versions of bzimage and init.xz; so somehow I think fog changed the original ipxe files to include some other script to help in the boot process?

    I will certainly have a look at 1.3 (trunk), mostly because we are still in our own beta setup here and having the latest when going live is in everyone’s interest.

  • @ch3i

    That is because I created my own from the IPXE project

  • This post is deleted!

  • The current development branch automatically uses the right kernel as far as x86/x64 goes. Since your new to fog and are setting it up for the first time, I’d really urge you to go with Trunk. 1.2.0 is very dated and doesn’t support a lot of things that you will find you need. And FOG Trunk, I feel, is very close to release-ready. That said, there will be minor bugs here and there, just report them, the fog team fixes them pretty fast (we are well known for our quickness and take pride in it). Here’s how to upgrade to trunk: There are some installation tutorials that use FOG Trunk in our wiki, including Fedora 21, 23, and CentOS 7. If you wanna stick with Debian, that’s great! Write us an article!

    And for the boot files, what you need is to setup your DHCP server to identify the vendor class ID (option 60) that the clients report, and give the boot file out according to that. There is an entire Wiki article just for this, right here:

    I’d be happy to help you out further if you have any questions.