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