@george1421 That worked! I added the two additional tables to the export command and the “test” host was imported.

@brakcounty said in Newly captured images are being owned by "root" instead of "fogproject":

Well all of my other images in /images are owned by fogproject:root. If this isn’t a problem then I’ll leave it alone.

That’s done when you re-run the FOG installer. Just don’t worry about it. They’ll work either way.

@pamadmax Its great that you have it solved. Intermittent communications would also cause this pattern.

Just to clarify the point a bit about dual dhcp servers. If your fog server is on the same imaging network and its “the dhcp server” for your imaging network, then you don’t need a dhcp-relay service listening on this subnet. Actually you should clearly not have it listening on this subnet. You can have the dhcp-relay service on your router, that’s fine, but not listening on the imaging network’s vlan.

The issue is this, if the dhcp-relay service IS listening on the imaging subnet, the relay service will relay the dhcp request to your main server. With the FOG dhcp server also listening there is a chance that your pxe booting computer will get two OFFERS. One from your FOG server and one from the dhcp-relay service as a proxy for your primary dhcp server, hence the comment about 2 dhcp servers.

You have it worked out, so that is all that really matter here. Good going on finding the problem. I’m sure that misconfiguration on the LAG trunk was causing other strange issues on your network too.

@Pilar Please post pictures of the configuration in the web UI.

@Pilar There is no place to check. Re-running the installer script should correct all the permissions for you. Though you seem to have modified your storage setup a lot now and I am not sure the installer script will take care of this.

Of which directories do you want to know the permissions?

Same here, please give this topic a proper headline!

@Pilar You probably want to add this to the other topic: https://forums.fogproject.org/topic/15911/without-master-node

Why several postings with seemingly the same question? As well you might change the heading of this topic to match it’s contents!

@sigit FOG is a one to many bare metal imaging solution. I don’t think that fits your requirements about updates and patches. PDQ Deploy and Inventory might be a good fit for that bit. FOG does have a snap in function (application deployment) that can be connected to image deployment, but its not really a stand alone solution.

With inventory it can scan for installed software and then you can create policies and have pdq deploy enforce those policies.

Also you could look into chocolatey https://chocolatey.org/ for patch/ application deployment if you wanted to stay in the FOSS user space.

In any case for a non-domain environment you will need to have a consistent admin user account across all non-domain computers for the above solutions.

@mikael1909 While I haven’t tried these specific boot disks. I don’t read russian at all, but it looks like these boot images are windows pe based. You should be able to get them to boot.

What have you tried so far?

What errors do you see? If you post a picture of the error it might help debug the problem.

@george1421 thanks for the quick answer.

I’m aware that the power of FOG is in the multicast deploy. But I have to say that I tested it with 25-30 capture tasks in parallel, and if you have the hardware+infrastucture, it works like a charm 🙂
I already have the registrations, image definitions, groups etc., but I won’t do it on scheduled basis, only on manual basis.
My only problem is the lot of clicks which I have to do, if I want to do it manually:) That’s why I asked this question here.

I will have a look at the Powershell API, it will probably/hopefully solve my problem 🙂

Thanks!

Yepp, I have the same problem, I see the status only after a few minutes, when the text gets “streched”. If there is a solution, it would be nice to know:)

We have an “easy” solution for this. We are using a NAS (a Syno in our case) to store the images, and we enabled the recycle bin. When the image is overwritten by FOG, the old one goes in to the recycle bin of the Syno (#recycle). Depending on the filestore size(we have around 32TB), number of hosts, size of the images and the size of the recycle bin, you can have the “history” for a few days.
The images are renamed in the #recycle of the Syno(e.g. d1p4_1.img or d1p4_5.img) and if you need an older image, you just copy it back, and rename it.(e.g. d1p4.img )
We can go back in this way, for 5-6 copies, in your case it would be 5-6 days.
I hope it helps.

@brakcounty Well done!!

Where I also see value in this is if someone wanted to hard drive boot into iPXE then from iPXE into the hard drive or FOG without using PXE booting. Instead of a usb drive, everything could happen off the efi partition on the local hard drive. It would not solve the secure boot part of it, but its an option.

Also lets say someone wanted to setup a preboot menu (such as for dual booting) using refind. Your idea could be tweaked slightly to boot into refind menu manager and then pick to boot windows, linux or something else from the refind menu. There are a number of options this method opens up. Again, well done!

Hi,

i have FOG 1.5.0 running on an ESX Host and a Storage Node on a bare metal machine.
Works like a charm since years.

Best Regards X23

@danboid said in Restore BIOS W10 image onto UEFI machine:

First, why is there so little content on the FOG wiki FAQ page?

Would you be keen to help work on the documentation?

@george1421 I just tested it out on a PC outside of our IT vlan with success. I hard coded it already, but I have a habit of not disclosing our IP addresses even if they’re private. I get the Press ESC to show the menu option for one second, then it boots to the hard drive. Now I took the modified bootx64.efi from my usb drive and copied it to the Windows EFI partition, replacing the existing one (renamed the old to bootx64.efi.bak), made sure that the UEFI is pointing to the file, and now the PC boots the fog process without USB.

@george1421 well, I am excited to say that it is working. I literally just readded what was already added, and re-tested. Could have been gremlins or lack of sleep, whatever the case, I am about to capture my image, and do a test deploy. I will ping you back shortly and you can close this as solved I do believe.

Thank you so much for the assistance. Ping me anytime you need a tester.

@danboid said in Linux mdraid RAID-10 with FOG?:

software RAID built into the Linux kernel

These are the words I was looking for to give a direction. mdraid can be used for more than just the intel fake raid as you referenced previously.

Yes FOS linux (the engine that interacts with the target computer to capture and deploy images) can interact with a software raid.

the same rules for FOG imaging as with clonezilla. If the software raid doesn’t exist you must create it before you can image it. You could test to see if it exists in a FOG post init script, If your deployment mode is download then you could create a bash script to create the array. Post init scripts are executed just after the FOS OS inits and before any imaging begins. The tutorial you referenced before lays out all of the bits you need, just in this case you are not setting up the intel fake raid configuration.

@sebastian-roth it’s working thank you !!

@pep Any news on this?

@sebastian-roth 1.5.9. What is also strange about how FOG behaves across subnets is the USB boot method. I’ve explained in another post about how booting from USB on the same subnet and/or same switch stack on my floor will not prompt me to enter the tftp server but booting from a completely different vlan or subnet physically outside of our own network will prompt for it. See this line in the ipxescript:

:setserv echo -n Please enter tftp server: && read next-server && goto netboot || goto setserv

I tried changing it to and this time it configures net0 then does nothing and the PC returned to it’s own (Dell) boot menu:

:setserv set next-server 10.x.x.x && goto netboot || goto serserv

I know this is off OP but it seems related to different subnet behavior in FOG.