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,
Alex
-
@abos_systemax Hi, I don’t see ipxe64/86.efi files in /tftpboot :
ls -l /tftpboot/*.efi -rw-r--r-- 1 fog root 196960 mars 1 17:13 /tftpboot/intel.efi -rw-r--r-- 1 fog root 914112 mars 1 17:13 /tftpboot/ipxe.efi -rw-r--r-- 1 fog root 196480 mars 1 17:13 /tftpboot/realtek.efi -rw-r--r-- 1 fog root 195744 mars 1 17:13 /tftpboot/snp.efi -rw-r--r-- 1 fog root 195936 mars 1 17:13 /tftpboot/snponly.efi -
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: https://wiki.fogproject.org/wiki/index.php?title=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: https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence
I’d be happy to help you out further if you have any questions.
-
This post is deleted! -
That is because I created my own from the IPXE project
-
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.
-
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.
-
-
@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
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
-
@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.
-
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
) -
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?
-
@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 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 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.
-
@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.
-
@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.
-
(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. https://forums.fogproject.org/topic/6642/moving-fog-s-images-files-off-the-root-partition
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).
-
@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.
thnx!