@ckasdf Sorry for not having engaged in this discussion yet but unfortunately I am way more a wiz when it comes to Linux. I have not toyed with setupcomplete.cmd yet at all. Possibly @george1421 has an idea on why this is making problems?

@fry_p What OS version do you use? Just wondering if this is something that broke with 1809 or 1903 or what?!? @ckasdf Which version do you have?

It’s very interesting it happened to work for one out of three machines!! To me this sounds like it’s very likely to be a timing issue. But on the other hand “Access denied” is a pretty clear statement as well. Possibly the system account is not ready yet or the windows services framework?!?

Forgot to post the link… https://news.fogproject.org/fog-1-5-5-officially-released/

@UWPVIOLATOR I would recommend you wait a couple of days as we prepare för 1.5.7 release with important fixes.

Please read the update notes for 1.5.5 before you go ahead!!!

@MFuchs135 Please try running this command to see if it properly returns on success: sha256sum --check binaries1.5.6.zip.sha256 ; echo $?

Take a picture of the output and post here.

@MFuchs135 said in Failed to download kernel, init and fog-client binaries...:

could not download binaries1.5.6.zip properly

This message means that the installer was not able to verify the checksum. Plesae run the following and post output here:

cd fogproject/tmp
sha256sum --check binaries1.5.6.zip.sha256

PS: Sorry for the misspelled curl commands. I just fixed that so other people won’t run into it as well.

@svandam Which version of FOG are you running? If you are on 1.5.6 already you should be able to switch to SSL by simply changing the variable httpproto in /opt/fog/.fogproject from “http” to “https” and re-run the installer. It will do the needed changes for you and compile the iPXE binaries.

@theland10 Ok, so I guess you downloaded “EFI PXE bootstrap 64-bit (.efi)” from https://rom-o-matic.eu/, right? Have you tried “EFI x86_64 snponly (.efi)” yet?

Are you absolutely sure this issue is specific to the NUC model? I am just trying to prevent us from running down the wrong lane right from the start. Can you please try one of your other models (known working) right at the same spot where this NUC fails (exact same network cable/port/switch)?

@tehresman Please schedule a debug capture task and when you get to the shell run lspci -nn and take a picture. Hope we get some valuable information on that RAID controller.

@theland10 Is it booting in UEFI or legacy BIOS mode? If you are not sure take a picture of the PXE boot screen and we’ll be able to tell you.

@ckasdf Ohhh no, I had lost track of this topic again. Sorry for the late reply!

Now that you posted the iPXE boot menu output I kind of understand what’s going on here. The boot exit type is set to “sanboot” and for some reason it seems like this machine you are trying this on is not able to use that exit type. You can change this setting either “per host” (host settings -> Host Bios Exit Type and Host EFI Exit Type) or globally (FOG Configuration -> FOG Settings -> FOG Boot Settings -> BOOT EXIT TYPE (for legacy BIOS machines) and EFI BOOT EXIT TYPE (for UEFI machines).

Probably start by changing this in the host settings to see what works for this kind of machine.

An issue was found in 1.5.6 that calls for an early next release to fix that. Find the details here if you run into problems with FTP connections on kernel updates or storage nodes in 1.5.6: https://github.com/FOGProject/fogproject/issues/311

@Wayne-Workman Sure, good point!

@MFuchs135 This is what the installer does at this point (I guess you are using the latest release version 15…6 with git and not the development branch dev-branch

cd fogproject/tmp
curl -kOL https://fogproject.org/binaries1.5.6.zip
curl -kOL https://fogproject.org/binaries1.5.6.zip.sha256
sha256sum --check binaries1.5.6.zip.sha256

@njohnson Yes, setting DHCP options 66 and 67 will only affect PXE booting devices. Please use a search engine to find out more about PXE booting and how this works. The information is available on the web.

PS: I moved this topic as this has nothing to do with Windows as far as I see it.

@MFuchs135 said in Failed to download kernel, init and fog-client binaries...:

We have a proxy server btw. and i already tried all the solutions posted on here

What do you mean by “tried all the solutions posted here”?? Please be more specific. Post the exact URLs of forum posts you read and tried things from. If we don’t know what exactly you tried we can’t help you.

@Matthieu-Jacquart I am not sure we’ll get to anything here. There are too many strains of topics combined in one forum thread. This makes it very hard to follow and quite often we seem to mix up things here.

For the parted -l /dev/sda output it would have been interesting to see the one with the four partitions.

@jemerson93 said in Small local disk and the rest unallocated:

windows could not finish configuring the system. to attempt to resume configuration, restart the computer

Are you sure this image deployed without an issue before? I am not exactly sure but this sounds like some kind of sysprep issue to me.

@marcolefo May I ask you to open a new topic because I am fairly sure you have a special partition layout if the new inits don’t work for you. We need to analyze that in detail. Please post the contents of d1.partitions, d1.minimum.partitions and d1.fixed_size_partitions in the new topic.

@mechalas I am absolutely with you here that simply overwriting the file can cause trouble if people rely on the FOG server as general NFS storage (not recommended by the way!) and therefore customize /etc/exports.

We have a similar situation for different configuration files as well (DHCPd, VSFTPd). For those we do a single shot backups (copy before overwrite). So running the installer a second time (for whatever reason) will erase your initial config as well. Not as bad as we have it for NFS but still. I remember that I had thought about how to properly solve this a couple of times in the last years but never got to a proper solution. Too bad we never did.

Thanks for your suggestion but as you already mentioned this will ruin configs that were modified by people manually. Let’s take the time and try to come up with a proper solution for all situations now that you brought up this again!

Checksums would work for /etc/exports but not for dhcpd.conf as that has variable information like IP addresses. Another option would be to use “block comments” like:

### FOG config start - don't touch ###
...
### FOG config end - don't touch ###

But I have seen many situations where this fails terribly and I don’t thing we can make this absolutely fail save.

Hmmm, any other suggestions?

@processor Should take about 10 minutes for your 300 hosts to ping. I can imagine that a firewall is blocking the ping (not ICMP but TCP port 445!). See some more information on this here: https://forums.fogproject.org/topic/12669/fog-doesn-t-detect-the-status-of-the-clients

@Scott-B Pleas run find /var -type f -name "*fpm*log*" and post results here.

Ahhh, forget about that. Ubuntu has the errors in apache error log as far as I remember. Please take a look at /var/log/apache2/error.log and maybe paste the whole log messages from yesterday and today here.