@Tom-Elliott Thanks Tom, the update resolved the issue. I upgraded to 1.4.0-RC7.

@Warget that is beyond the scope of the fog forums. You could try posting on spiceworks.

@george1421 Got it, thank you again!

@seb38300 Correct it may ask you for authentication. The user ID and password will be ones that you setup in the fog gui under User Management.

@Frank said in Error "Undefined index: pass" in capture:

@Wayne-Workman I’ve followed the troubleshooting guide in case of “Update database…failed” and tftpd passwords are OK.
The error happens in fog.imgcomplete script, in “curl” line. If I do the curl at command prompt I get this:

curl -ks --data ‘mac=98:90:96:d8:29:4d&type=up&osid=9’ http://<ip_of_main_fog_server>/fog/service/Post_Stage2.php

Type: 8, File: /var/www/html/fog/lib/fog/fogbase.class.php, Line: 837, Message: Undefined index: pass. Host: <storage_node_ip>, Username:fog

SOLVED!! So simple as a firewall rule! Shame on me.
Fog main server was unable to contact client to port 21.
What had made me crazy was log messages, which seemed to have no sense.
Thanks anyway.

@Tom-Elliott said in Single disk, resizable - failed to set disk guid:

@dylan123 So the issue, if you’d like it fixed for now (I’ll relook at this code though).

Can you open the file, and add the /dev/sda components?

In other words make the file read as:

/dev/nvme0n1 dcfabb9e-4507-415e-b9a9-e437017df63b /dev/nvme0n1p1 1:0C86C94F86C939CA 1:9c90a090-937d-4c9b-9a25-0381f463b590 /dev/nvme0n1p2 2:6CCA-8BF5 2:7e69ccb9-b499-4bf5-8528-293b71e42988 3:2de320a9-99b6-4191-aeeb-1c15e96fae1d /dev/nvme0n1p4 4:CC34D93B34D9296A 4:b1911679-d848-4e8b-82fc-98616b55452e

Hey @Tom Elliott, tried the above code and that worked perfectly!

Will download the new init’s as suggested and see if that works also, thanks.

@george1421 Thank you for the quick reply! As a follow up, I managed to update to 1.4.0 RC6 and was then able to deploy an older image without trouble (single disk - resizeable). It completed, and resized successfully. Take care!

@george1421 @Tom-Elliott

Thanks for the help again!

@Fimlore Yes, only changing the “IP” to point at the relevant VLan’s. I’m sure there’s more stuff that would need to be worked out of course, but at least you can see it can be worked out. And I’m typically just a message away.

Also, with notepad++, you can change the formatting from Windows to Linux, to prevent these kind of issues

That did it! Thank you!

@george1421 yes this has been solved. Sorry for the delay I have been out the last few days

@Tom-Elliott yes

Nevermind disregard this post I switched out the adapter and now it is booting. thanks for your time.

@alh said:

To me it is not clear why at this stage (after we booted from the undionly.kpxe and therefore already found our desired boot server) one does not simply hard-code the IP of the FOG server here during installation?

The iPXE binaries are not being compiled on installation time but provided as binary. Therefore we can’t just hard-code the FOG server IP.

Update 1.4 RC 5 fixed the issue. Thanks for everyones help!

@aboushard After a client finishes deploying the image it sends a request to the FOG server to tell it “Job done”. I am wondering if this is happening in your case as well. Can you please take a look at the apache access and error log files just after the client finished. See my signature on where to find those logs.

@george1421 said in Storage nodes not deploying images:

@EuroEnglish AFAIK, multicast sessions are only hosted by the master server. Unless something has changed in the multicast bits only the master server sends out the image.

This has changed, the non-master storage nodes are now able to multicast too. It’s something Tom worked on maybe 6 months ago. It was so multicast wouldn’t go across the WAN link and conform to the settings set in Location Management.

You were absolutely correct. The Cisco switch was running regular Spanning tree. It has been modified to use the fast spanning tree and it worked like a charm!

@dylan123 As stated earlier, I got an instant “Failed to get IP via DHCP” error when I had just the dongle plugged directly in. I also am already using the “has_usb_nic=1” argument. Lastly. I have both the dongle MAC and the USB hub MAC listed in the host.