@plegrand Testing internet connection is now done mainly with curl.

Hi,

i am not sure if it can simply deleted, It’s used in recovery cases and there are 12,5MB of data in it. I need to find out if Windows 10 is using it for what ever case.

Best Regards X23

@Sebastian-Roth Thank you, I did forget about using Multicast. I’m running a job now using it and it’s immensely improved bandwidth utilisation!

@Kamiii said in Fog Update 1.4.4:

As for the images, how do I copy them over to a new fog node?

When you setup a new FOG server make sure you place the /images on its own partition. If you use Centos to install the default will be to place the root partition on 50GB and then give /home the remainder of the disk. For FOG I would select custom configuration and then select auto create partitions. Then rename /home to /images sections and then set that configuration. This will keep you from accidentally filling up the partition with imaging and killing your OS and database. The other option if creating in a VM pick the minimum size of disk required by your OS and then install the OS. Once the OS is installed create a second disk for your images and then mount that new disk over the /images mount point, THEN install FOG. This will then keep your disk images on a different disk and away from your OS disk.

thanks guys 🙂 that fixed my problem

and i have mounted a share from my host to the vm … and that was working fine until i rebooted as i know now 😄

i forget to automount this share on startup and than fogserver wasn´t writing to the share 🐶

@zzeuss1969 Thanks for the update. It’s interesting you get this error message when capturing in legacy BIOS mode and deploying to UEFI. While I know that you cannot boot a machine in UEFI mode that has a legacy BIOS image deployed to it I don’t think that you’d get this error when capturing/deploying. We do actually have users who capture UEFI installations in legacy BIOS mode because they do their master image in a VirtualBox environment which you still cannot PXE boot in UEFI mode and it works all fine deploying this image to an UEFI machine.

Anyhow, good you got it solved!

@Sebastian-Roth Thanks for the TIP. I did make the change on the storage nodes as well. The time on the reports is now correct.

Thanks for the reply.

@Bastian Looking into this, I can’t believe its still an issue after all of these years (> 5). The only solution I can find is to switch the disk controller to ahci mode from RST. If you have a live system that was installed with RST on windows will hate you. I’ve found instructions on how to fix windows.

The ideal solution would be for you to recreate you golden image and sysprep it on a system with the disk in ahci mode enabled. That way everything will work moving forward.

@Sebastian-Roth So it turns out most of my problems were in fact caused simply by old software. I installed Ubuntu 20.04 and FOG 1.5.9 and it solved all the database updating issues.

Now I just have to solve some DNS problems that I’m pretty sure are not FOG related.

Thanks mate.

@Sebastian-Roth I understand than I was racing my brain on this lol

Turns out the DNS server was not ser correctly and the server got it’s IP via DHCP. We got that fixed.

@jmvela2x Sorry, lost track of this.

Here you have a template for an advanced menu:

#!ipxe :ADVMENU menu colour --rgb 0x00567a 0 || cpair --foreground 1 1 || cpair --foreground 0 3 || cpair --foreground 4 4 || item item1 Do this item item2 Do that item item3 Go back to main menu choose --default item1 --timeout 6000 target && goto ${target} :item1 echo "Do this" || goto ADVMENU :item2 echo "Do that" || goto ADVMENU :item3 chain -ar http://${fog-ip}/fog/service/ipxe/boot.php || goto ADVMENU

@george1421 thank you for all the help yet again 🙂

seems to be all working as my router for the dhcp server and the fog server as the pxe server.

PS. i have to say it is a really nice project/community to flow in like this with people willing to help thnx appreciated.

ok thank i actually install newer version of ubuntu not 20.04 but 19.10 cause i already have this iso,

i install again and i change the dhcp conf with filename “ipxe.efi” and i give you new later.

did as you instructed and seems to be working now thanks 🙂

@Jim-Holcomb I still don’t fully understand. The database is just a point to store and pull the data from. Nothing more.

If you manually rename the folder in Linux, would you expect the database to automatically update when now it has no reference point? It’s the same reason in reverse. Why allow the folder to be renamed in the terminal if it won’t update the database that may be referencing it?

The folder doesn’t get automatically created when you define a new image. This only happens after the image is defined and captured. The pieces handling it are all after the database information is pulled. The GUI is not creating the folder. FTP is.

If you manually change the folder name in the terminal, you will still need to change the folder in the GUI. It’s the same for updating the path in the GUI. While you could temporarily store the change, but what about you are changing the path when the image hasn’t been captured yet?

Disregard - some how the SSH service was offline.

@JDnoble18 download it to the fog server. Run it. That’s it.

How you run is up to you. But I’d say do sh ./renumberImageIDs.sh once it’s on the fog server.

@Pyrol said in PXE-E18: Server response timeout:

I reinstalled FOG and PFSense and it’s still the same.

You are using pfSense as DHCP server. Please share the settings you have in there (picture) as well as the information requested by George.

@Sebastian-Roth Just replaced a mobo on a failed 3500, and it came with latest bios, which now acts the same as the 3510 😞

So it seems my work flow with imaging 3500 only worked due a bug in the firmware on the 3500s.

Going to either set the bios to pass-through disabled on unboxing or put together a new imaging work flow.