Chaining FOG from ipxe.efi (x64)
-
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. -
@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!
thnx!
