@Wayne-Workman Interesting, I found our problem was the initial setup of the Ubuntu server that hosts FOG was set to allow auto-updates. This will come in handy for future installs, thanks!

@anhphuong all assigned to that host. i agree that being able to select what snapins you want at the time of deploy would be nice, but the logic is tricky and there hasn’t been a lot of demand for it.

@meobeou Hi, i am using it and it‘s easy to use, google for create pushbullet api key, create it in your pb account and paste it into the fogs pb config. After that it should work.

Bild Text

Bild Text

Easy 🙂

Regards X23

@sampsont I guess you could come up with a solution where you add our FOS linux system to your clients and boot from it. I don’t know anyone who’s done this but I reckon it’ can be done. Surely Ubuntu 12.04 had grub installed. So you’d copy bzImage and init.xz to the clients and modify grub.conf to boot exactly that as first boot option. The problem I see is that you only have one go (old Ubuntu and FOS being wiped from disk as soon as imaging starts) and if things do wrong…?!

And you’d need to prepare all the clients so why not just using clusterssh and do a normal dist-upgrade 12.04 - 14.04 - 16.04 - 18.04? Probably not trouble free either but not much involved to try it out with the first batch.

What kind of hardware do you have? As George said, some manufacturers like Dell and HP might provide command line tools that let you change boot options.

Would be real interesting to see if FOG would image properly while wiping itself from the disk. Should work as it is loaded to RAM but I never tried that before.

@Wayne-Workman Thanks for the response. I ended up renumbering the image name to include 01. through 14 and that did sort them. I appreciate the quick thinking and that fixes my issue!

@vishalthejigsaw What’s the end-goal here? Snapins? And you should think about SnapinPacks. Put all your stuff into one SnapinPack and then run that on a schedule. Documentation here: https://wiki.fogproject.org/wiki/index.php?title=SnapinPacks

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