With fog you would set the image type to “multiple disk resizeable” and pick “all partitions”.

Thanks kafluke! This was just what I was looking for!

For anyone else looking:
To change selinux to premissive permanently in CentOS 7 edit /etc/selinux/config. Change “SELINUX=permissive” the write out.

@ConJon said in Boot to Image:

We only image one kind of machine. I am wondering if it’s possible to skip everything on the host side and when we boot to the NIC, it skips every menu and starts the only image we use. Anyone know of any way to do that.

Hi, what you want sounds dangerous, what if a client boots via network by accident? You will wipe the hdd/ssd and deploy a new image.

A good idea would be something like waiting for admin to approve. Like IBM Tovoli does.

Regards X23

Thanks for the info. I’ve been leaning towards Cent so I’ll start there with a test migration.

I’m not understanding your question. Or at least not understanding what you mean or are intended to obtain.

FOG, itself, knows nothing about your Drives used/free space. We use a block based imaging tool called partclone. Partclone can detect the used vs. free/empty space.

All Fog does is use utilities that are readily available to do all the work. FOG just automates the usage and mathematics of these things to help with resizing and expanding.

I’m sure this isn’t the answer your looking for, but to understand what I mean you’d have to look at the source code. https://github.com/fogproject/fos

Specifically the bin and usr/share/fog locations.
https://github.com/FOGProject/fos/tree/master/Buildroot/board/FOG/FOS/rootfs_overlay

@china-boy said in Fogproject can only clone C disk:

Sorry, what I want to say is that the captured image should be installed on other user machines in bulk, but other disk characters other than C disk cannot be erased.

Hope you are still around. We’ve kind of lost track of this as you haven’t posted the picture of disk management of the target PC before deploy.

Without knowing the details I guess that you are trying to simply update 😄 after you have initially cloned the PC’s full disk. So steps I would recommend: In your FOG image definition set Partition to “Partition 2 only - (4)” and deploy the image to the target machine. This way only partition 2 (hope this is 😄 in your case) will be deployed and the other partitions won’t be touched.

@Wayne-Workman Amazing !! thanks a lot

@Wayne-Workman Okay i’ll give that shot on monday

@pberberian @Sbergeron I am sorry to bring up this kind of oldish topic again. Lately I have been working on a couple of things and stumbled upon something that makes me think that ARM support never made it into FOG completely (exit type calling ARM binaries that don’t exist in FOG). So I am wondering if you are still interested or maybe got it worked out yourself? I am more than happy to add what is needed to fully support ARM clients but on the other hand I don’t fancy maintaining the ARM support if it’s not used at all.

@The-Dealman As George said, take a look at the logs to see the current status of replication going. It replicates image by image but kind of parallel to all storage nodes.The actual replication of one image to one storage node is started as a background job and so it is mostly going all in parallel.

You need to recapture. Preferably to a new image so that if something goes wrong, you still have the old one.

There is no Software inventory.

Hardware inventory is performed either through the deployment/capture process of a registered machine, or via a dedicated Inventory from the FOG GUI. @george1421 the FOG Client does not perform “hardware inventory” in the level of telling a user what information the machine has. It simply registers an unregistered machine and allows the admins to approve/disapprove machines in a semi-autonomous methodology. (Not that I think you were saying otherwise, just wanted to make sure the information was more clear.)

Software deployment is not the “strong” element of what FOG does. We do have snapins which could potentially be used to install software, but snapins, in and of themselves, are not really a “software deployment utility”. This would be better suited for some other programs out there. Neither is it a patch management system. Again, you could use snapins to do these things, but this was not what snapins were designed for.

Unattended installation is managed particularly by how you want to manage the installation process. FOG, as @george1421 stated, doesn’t care what “state” your reference machine is in. It only captures the current state of the hard drive in a block level format. I would, personally, recommend using Sysprep (in the case of Windows) to generalize the machine before capture. This will allow you the ability to create what we call a “hardware independent” image. This, however, is not a requirement and FOG will happily capture your disk in any state you feel is sufficient for your needs.

Hardware inventory works just like an imaging task in fog works. (At least if you’re meaning what I think you’re meaning.) You create a task (deploy, capture, or inventory). FOG Uses PXE to load the machine from the network. This passes to a bootfile called iPXE. IPXE then handles checking for the task, and if there is one found booting the machine into the FOS (FOG Operation System) to perform the task. This data is stored in the FOG MySQL database linked to the registered host’s identifier.

Hopefully this helps. @george1421 already stated most of this, but I figured I could potentially help a little too!

@agray

static ip address management post install. Not a problem. DHCP is only required if you need to PXE boot into the FOG iPXE menu or for capture/deploy activity. After image deployment the target computer checks-in to the FOG server using the FOG Client service so that is how the FOG server knows about the target computer.

Driver install for single golden image. Its not easy, but not hard either. If you use Dell computers then Dell provides the driver cab files as you need them. You can look over these tutorials: https://forums.fogproject.org/topic/11126/using-fog-postinstall-scripts-for-windows-driver-injection-2017-ed and https://forums.fogproject.org/topic/8889/fog-post-install-script-for-win-driver-injection for guidance. You will need a little linux experience to setup, but its not too hard.

MDT driver less: Yes you can. We will build our golden image using a virtual machine. We use ESXi virtualization, but you could use Hyper-V or VirtualBox to build your golden image. Then capture from that visualized machine. But I do recommend that you install the Dell Win10PE drivers in the Out of box drivers section to make your deployment life a bit easier. These are generic drivers that will allow your target computer to initially get connected to the network and talk to the storage device. There are plenty of how tos out there on how to setup and MDT environment. The deployment research web site is pretty handy too with info.

@Sebastian-Roth Many thanks for this. I should be able to request that the labs can sit common VLANS with no port restrictions between them. I guess this might cause problems with multi-casting but worst case I can have a FOG server on each subnet. I’m going to start testing! thanks

@Tom-Elliott I see, the storage nodes themselves are not meant for capacity but redundancy and throughput? Is mounting a network storage location viable to expand my capacity?

@Wayne-Workman Probably one of the configs were changed and the updater is asking what to do. The best I could find quickly is: https://serverfault.com/questions/259226/automatically-keep-current-version-of-config-files-when-apt-get-install/593640

Try: apt-get update;DEBIAN_FRONTEND=noninteractive apt-get dist-upgrade -y -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" --force-yes

What a monster of a command…

@Sebastian-Roth
1.
This is a very new idea. Did not have chance to test wimlib yet. Next week will do so for sure.
I have Samba NAS , will try with centos.
2.
Another interesting wim usage scenario:
WIM keeps in the A-image base Windows + B-snaphot with drivers + C-snaphot with sql server.
And you decide what you want to restore after the Base. So for a host1 u have A+B. For host2 A+B+C.
Instead of 3 images you must keep only one image +2 deltas.

Thank you for clarifying this. I strictly use fog for imaging and joining multiple lab computers to the domain. Kudos to all that make this possible.

Thanks James…

@Tom-Elliott Hi Tom the FOGUpdater script fails on the mirrorlist trying to download. Is it possible for me to download the latest version manually and then pass it to the fogupdater.sh

@LycaKnight You are missing the parameter initrd=init.xz (kernel bzImage initrd=init_32.xz ...). I am fairly sure this is causing the kernel panic.