@george1421 @Sebastian-Roth Just wanted to give you an update. From what I can tell, the section of dhcpd.conf where you declare options, was missing a } so the file wasn’t reading the options I guess? I compared the file to an old server and that was the only difference I could find. I probably deleted it while editing the file at some point. Works like a charm now.

@fognerval is the BIOS on UEFI or Legacy boot? You might need to change your files on the DHCP server. Also, are both the Device and DHCP servers on the same network? If not, then you might need some IP helper configuration or proxy. More information on setup is needed I think to figure it out.

@nil If you are interested in helping start out by writing a tutorial in the tutorial forum. Then once others have a chance to prove it out it will be converted to a wiki page.

Thank you for helping the FOG Project move forward by adding new options for installing FOG.

@sebastian-roth Thanks for your reply, we will try the alpha version.

My teammate ask me to say a big thank you because since 2008 we use fog and we see you’r answer are very quick and we are very happy to use fog.

did i need to do something to indicate the post as resolved ?

@julio If you need rename and domain join on Linux systems you’ll have to manually add scripts to do that work for you. Rename can be done woth post-deploy scripts I would think but domain join is another story. You might even need to add systemd/initd scripts to do that for you. Currently this is way beyond what FOG or the fog-client can do for you I have to admit.

@george1421 The code works as expected now. I used your shortened fog.updateregbarcode that just echos the variable into the text file on the C; drive.

@matthew11 Totally out of scope question for FOG. FOG hasn’t use syslinux for pxe booting in over 10 years. FOG uses iPXE for a pxe boot loader. There are parallels between the two, but they are not the same.

With that said, if you have the default config file for syslinux it might be possible to translate that into iPXE syntax, but I would have to see the changes needed to that file.

@seppim I have no idea since I did not test loading it with memdisk. I did not look but I suspect the iso image may be larger than 2GB (thinking memdisk is a 32 bit application and not a 64 bit app. But this is only a guess). I know when I was testing the boot.wim file on the iso was 1.3GB in size.
I was able to get it to boot in uefi mode here: https://forums.fogproject.org/post/140212 but in bios mode it complains about needing bootmgr.exe in the iso image.

@Epsilon52 Thanks for the update and good to know. Maybe it just needed a cold boot or something like that.

@seppim While I don’t use hiren’s software, let me download the iso and see what has changed. I know it worked at one time.

@tom-elliott said in droit:

@julio said in droit:

bonjour voici mon fichier /etc/exports. j’ai ajouter ces deux dernière lignes pour un test mais elle ne fonctionne pas toujours.

I’m not quite sure what you’re looking for.

First things first, the fsid elements must be unique.

Meaning these lines are good.:

/images *(ro,sync,no_wdelay,no_subtree_check,insecure_locks,no_root_squash,insecure,fsid=0) /images/dev *(rw,async,no_wdelay,no_subtree_check,no_root_squash,insecure,fsid=1)

But the following 2 items are not good as they are overwriting the configuration for the first 2 items.

/home/fog/images *(ro,sync,no_wdelay,no_subtree_check,insecure_locks,no_root_squash,insecure,fsid=0) /home/fog/images/dev *(rw,async,no_wdelay,no_subtree_check,no_root_squash,insecure,fsid=1)

Should more likely be:
erreur.PNG

c’est ça mon problème. je cherche comment mon mon image dans mon serveur.

@george1421 Worked Great thank you sir. It was the Storage node password was incorrect.

@sebastian-roth Doh! I feel silly. It was absolutely disk size. I built the test machines smaller than the laptops the images were captured from. Thanks for that, now I can go bug the network engineer 🙂

@nerdstburns There is one important thing I have to add. If you select a single partition in the image definition it won’t touch the partition table on deploy/capture at all!! So I would advice you create two image defintions, one full image where the option Partitions is unselected and another one with Partitions set as suggested by George. Now capture the full image an deploy that to all your hosts once. Then when you want to update C:\ you capture that to the other image definition “Partition 1 only” and deploy that to the hosts again.

If you ever try to deploy the “Partition 1 only” to an empty disk (no or not the correct partition layout deployed before) then it will fail!

@kylian Well the simple answer is yes you can. In the host management page of the target computer there is a filed to identify the disk you want to send the image to.

The bit longer answer is the format of the disk is dependent on how the disk is connected to the computer. If its over a sata cable then disk 1 will be /dev/sda, disk 2 will be /dev/sdb and so on. So if you wanted to deploy to the 3rd disk on the computer you would enter /dev/sdc into that field.

@tom-elliott
Originally I wanted to keep the image without installation as I did at the time … I will experiment with domain integrations. And the multicast (At the time it saturated the network … :))

@sebastian-roth I was able to test on both an M83 and a 7010. I’ll be doing more widespread testing once we get back after the holidays, but everything seems to be fine!