@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!

@sebastian-roth said in Permission Denied Capture:

ls -al /images/INFRA-NEW

Ah I ran that and it wasnt listed, so I checked under Images, and all my other images were there- So I just decided to remove that old image from Webui and remake it.

@blema2213 It looks like I need to create an updated post. The intent was for you to follow this process https://forums.fogproject.org/post/103323 until you get to step 18 then jump to the first link I posted to you.

The idea/problem is just as I mentioned, Win10 expects to see local or network based media not in RAM media. Also the issue with the above link is that you can not use the memdisk program with uefi. So what I’m recommending is that you copy the win10 media to a windows server and share it out as read only. Then build a WinPE image that will mount the network share you created and run the winsetup program. Windows will allow you to install over a CIFS share.

So the steps are to

Copy the windows media to a windows based server (or SAMBA) share. Create a WinPE boot media Launch that WinPE image from the fog server over pxe Install Windows from the share created in step 1

@george1421 Thanks so much for your quick reply! I do have 3 DHCP servers that sync with each other but all the settings seem to be correct. I will start a new topic.

This is fixed in the latest dev-branch code. Looking at it again I found this to be a simple typo (ref).

@george1421 You were right! It worked. I didn’t know that I should run it again to complete the installation, my distraction, I lost about 40 hours to solve something that wasn’t even installed! Thank you very much @george1421. You saved my job.