@Zark110 Just as a quick test an you connect a dumb unmanaged switch between the client and your main switch? Then try again.

@mstallter Did you export/import the whole database?

@Tom-Elliott Do you have an idea?

@theland10 Does this NUC have a rotten CPU? Celeron or what?

@UWPVIOLATOR said in Steps/Requirements to Update FOG 1.5.4 to 1.5.6:

072Cache was updated to 1.5.6 and we updated the username in GUI to fogproject and verified the password. Is this normal until we update the master node to 1.5.6?

No, unfortunately this is a bug in 1.5.6 and we are working on releasing 1.5.7 soon to fix that. Manually adjusting the username works för you just aß well. Beside the Storage Node settings you need to fix the username in FOG Configuration -> FOG Settings as well.

@cmurray139 Just to add a bit more information. default.ipxe -> http://x.x.x.x/fog/service/ipxe/boot.php

But I guess you will run into another issue as the FOS Linux system is another environment that you’d need to use the fake MAC address…

Nevertheless it’s an interesting idea. Please give it a try and see how far you get. Let us know what you find out and if we can help you with anything.

@wrinks Check the apache logs (see my signature) to hopefully get an idea why it returns HTTP 501 error.

If you just want a proof of concept you can download the current installer here as well: https://github.com/FOGProject/fog-client/releases/tag/0.11.16

Just cross linking this here: https://forums.fogproject.org/topic/13341/fog-registration-for-dell-optiplex-3630-errors

@chris178 said in FOG Network boot problem ACPI Error and IP Not Found:

FOG version:1.4.4

You are using a kind of old version and I guess the network interface card you have in the Lenovo m920q is simply not included in the kernel provided with your version of FOG.

Any chance you can update this setup or spin up a fresh new server with the current version of FOG?

@vpt First let me say, don’t get confused by the paths you see in the picture. When it says “Failed to create ... /images/1866...” this means /images on the local system. The FOS Linux booted to do the task mounts /ImageRepo/FogImages/dev on your QNAP into /images in the FOS Linux on capture. So what it is trying to say is that it cannot create /ImageRepo/FogImages/dev/1866... on your QNAP as far as I see it. Make sure it’s writable when mounted via NFS.

@imagingmaster21 Put those in /var/www/html/fog/service/ipxe/ and I’d suggest you rename the original ones beforehand just so you have a backup copy of those in case something goes wrong with the new ones.

@theland10 I have not seen the pigz: abort: only levels 0 error before and I am not sure what it might mean yet. A quick search did not reveal much. I might need to take a look at the pigz source code to get an idea. Not sure when I will get to that though.

This is when capturing the image!?! So using the wrong compression settings on deployment of an image with a different compression is definitely not the case here. Maybe use Zstd and see if it comes out differently…

@geardog Do you have a complete sector by sector image backup of the disk? If not I’d suggest taking one and then just go ahead and try: ntfsresize --expand --verbose --force /dev/sda2

@UWPVIOLATOR You better shut down the replication services NOW - systemctl stop FOGImageReplicator; systemctl stop FOGSnapinReplicator on your master node.

Read the important notice here: https://news.fogproject.org/fog-1-5-5-officially-released/

We can sort out the rest tomorrow.

@imagingmaster21 Please see my last post! Update the inits and see if that makes a difference…

@geardog said:

I guess now I try the previous command again to see if the bootsector error has been cleared to run the resize?

Exactly. Give it a try. Please take a picture again and post here.

@theland10 Hmmmmm, in the picture I see Received DHCP answer on interface net0 … Looks very different to what you told us before. Maybe debugging causes different timings within the driver and make it work?!

The error in the picture makes me think that maybe the default gateway option is not properly propagated to the client and it cannot reach IP 172.17.1.171 because of that?! Why is the IP different on the first TFTP pull (ipxe.efi) than on the second one (default.ipxe). Possibly it’s for a good reason but things just don’t add up for me here.

@fry_p We definitely need the exact partition info from your particular image. Please open a new topic on that one.

@imagingmaster21 I have not had the time to try and replicate the issue with the information you gave me. Will try to do so tomorrow. But as a first quick shot you can try updating the init files as I have fixed an issue that only came along when using FOG with NVMe drives. Could be the problem in your case.

You can download the new inits here: https://dev.fogproject.org/blue/organizations/jenkins/fos/detail/master/88/artifacts/

As well you need to adjust a setting as the new inits use a larger root filesystem. Please go to the FOG web UI -> FOG Configuration -> FOG Settings -> FTP Server and increase KERNEL RAMDISK SIZE from 127000 to 275000.

There should be no need to re-capture the image. Just put the new inits in place and try deploying the image again.

@geardog Try the following: ntfsfix /dev/sda2

@bnorwood Please start by scheduling a debug capture task. Boot the host and when you get to the shell run the following commands and post output here:

uname -a
ip a s
ls -1 /sys/class/net/ | grep -v lo | xargs -n1 -I{} bash -c 'echo -n {} :" " ; basename `readlink -f /sys/class/net/{}/device/driver`'

Note the backtick characters as well as single and double quotes. They all need to be used exactly as seen above.