@sebastian-roth as you suspected, this ISO image did boot both legacy and EFI. Which has been a boon.

I have used this ISO four times this week, and it has been a huge time-saver.

@wasps-d You can automate the domain join with FOG by using the so called fog-client software. Installed in the master host before you capture the image. After the image is deployed to one or several other machines it boots into Windows, fog-client service is started, host rename, reboot and domain join happen automatically (if everthing is setup correctly). To be clear, whatever method of booting you use (PXE or USB), the domain join/rename will still work.

That said I would still advise you to talk to your admin as many PXE systems can chainload from one to the other. I am not sure about PVS but it’s worth to take a look because it would make deployment of 500 PCs so much more convenient.

@londonfog You’ve probably seen my post in your other topic: https://forums.fogproject.org/post/143080

I managed to PXE boot it using NFS instead of the url=...iso option. So I have not played with the ISO option. See my post and give it a try using the NFS method.

Now bacl to the point of you saying that it does work with other machines but not with Dell Precision 5750 in UEFI mode. Do you have other machines that PXE boot in UEFI mode and loading this fine? I mean, is it just that Dell Precision 5750 causing the problem or potentially any UEFI mode machine?

@Jacques-Olivier What is TZ INFO (FOG Configuration -> FOG Settings -> General Settings) set to?

As well you might need to look into PHP-FPM timezone information. As we don’t know much about your setup yet (Linux OS and version) it’s hard to give further instructions. This command should help you find if there is a timezone set in PHP on your system or not:

find /etc/ -type f -exec grep "date.timezone" {} /dev/null \;

Make sure you adjust the value for and restart PHP-FPM service (not PHP cli or PHP apache module).

@sebastian-roth Because we are using VMs that are thin provisioned, Windows only optimizes, which we tried and the same result and behavior happened. Increasing the value of how much space to use https://forums.fogproject.org/topic/15416/out-of-disk-space-fog-capture-error/7#, did fix our issue and we only had to increase the value from 5 to 8 for a successful capture.

Thank you for your help!

@radjunior Can’t believe that switching to Windows DHCP server would solve a kernel download issue. But hey, what do I know. Great you got this solved!

@xburnerx00 It is possible with most DHCP servers. You wanna read through this: https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence

@sebastian-roth We should have renamed that user donotusethisuserever

@wayne-workman Yes thank you, video answer alot.

@faboulous said in 20.04 autoinstall:

If someone manage to do so, it would be interesting to check what is_casper_path and matches_uuid does and return.

I don’t have a setup to dive in this right now and so I just started looking at the code. But maybe that’s of any help to you too.

Looking at the definition of is_caspar_path I get the impression that there is no possible way for this to return 0 (true in bash logic) to actually proceed to the next check.

Edit: Ok, forget what I said here. This is using bash globbing to expand filenames when a file exists matching the glob used.

Anyhow, I figured out why it would not return successful from the do_nfsmount() call. It checks UUIDs that are stored within the ISO in path .../.disk/casper-uuid*. Now when we prepare things and copy contents from the ISO we are missing that hidden folder (starting with a dot)! To fix that run the following command on your FOG server with the ISO mounted in /mnt/loop:

cp -R /mnt/loop/.disk /images/os/mint/20

I’m able to PXE boot into the Mint20 XFCE Live system with that fix on a VirtualBox VM (hosted on Debian 10) with only 768 MB of RAM set for the VM.

@george1421 We might think about switching to rsync -a /mnt/loop/ /images/os/... in your great tutorials on PXE booting installers to prevent that from happening. What do you think?

@londonfog I just tried Ubuntu Server 20.04 as well and it is working fine too - even using kernel and initrd from the ISO and not download the netboot ones! The important part is that you need to copy the .disk folder over as mentioned above.

@sebastian-roth yes, right… and just FYI, I got it working once I followed the instructions on the link you’ve sent me, thanks man!

@ngriffith29 With FOG you usually register hosts (at least you need to if you want FOG to rename them) and there you define the hostname it will use after deployment. So it’s just up to you to name the hosts accordingly.

@londonfog said in Use http instead of tftp for fetching kernel and initrd:

and as long as directory above is in /var/www (ubuntu server here) it will work?

Yes. Your actual files will need to be in /var/www/os/ubuntu/20.04/casper/ If all you are doing is changing the protocol.

I agree that tftp over to a remote site will be painfully slow.

If your remote site has a web server available, it may be faster to host this iso locally at the remote site:
url=http://{fog-ip}/os/20.04/ubuntu-20.04.1-live-server-amd64.iso so you don’t have to copy that iso across your WAN link.

@sebastian-roth
Wow, so is my only known option for external storage making the NAS behave as a storage node? It has a flaky proprietary OS/GUI that has warning everywhere. “You will brick me if…”

@george1421 I think that may work, it might be just as easy to implement a feature as well for the web interface, just brainstorming here. But my assumption was that after registering a host, I would be able to log into the fog web interface and assign which menu entry would be default for a host.

I will experiment with both the method you describe, and perhaps a feature as described above in the web interface and see if I can’t get it to work.

Oddly enough I found the solution soon after my last post.I was looking at the wrong file all along.
I completely forgot that I un-commented the line 4 of my dnsmasq.conf file while running some tests last week . I just had to re-comment that line and voila it’s finally working.

@NubCake69 Are all the rooms on the same subnet? On the same VLAN?

From what we know so far I would think you are right, the switches need to relay the DHCP packets. No way to solve this unless you have access to the switch settings.

Update:
Finally had some time to sit and putz with it. Seems it was a carry over issue between what the password was in /opt/fog/.fogsettings for "fogproject’ versus what the UI had for the TFTP settings for the ftp user account, and for the storage node. Interesting that it was able to Image, and pull images though.

For those that may be interested, or have the same issue:
FTP to the FOG server from another box, and test FTP user and password that is shown in the storage management UI. This password should ALSO match what is in the FOG Settings in the UI for TFTP server. In my case… the password in the GUI would not allow me to connect to the FTP. Started searching for the proper way to change the FTP password for FOG… but ended up finding that the password was different in the .fogsettings file. I tried the password in the settings file and it worked to connect to the ftp.

At this point, I took the password shown for fogproject in /opt/fog/.fogsettings and placed it in the UI for the Storage, and TFTP server settings. Attempted to delete from the UI… and bingo, all good.

A good ref that helped to figure this out:
Troubleshoot_FTP