@FeasiblePear Have your admin update to the 1.4.0RC release over 1.3.5 stable. 1.3.5 stable had a bug with resizing hard drives under certain conditions. 1.4.0RC1 addressed this issue. I think the devs are up to 1.4.0RC8 which address a few other bugs from 1.3.5 stable. Its well worth the update to the current RC release.

@tom.langenfeld I also agree it sounds like an IP address conflict with the FOG server.

Once you determine one way or the other on the IP address conflict I want you to do the following from the FOG server linux console.

(you may need to install the traceroute utility if its not installed by default).
Run a traceroute from the FOG server to a device on this remote vlan where you are getting the tftp timeout. If you have success on a traceroute back to the remote vlan then…

From a windows computer on that remote vlan, see if you can ping the fog server IP address.

If success then install the tftp client program on the windows computer from Program and Features. See if you can tftp get undionly.kpxe from the FOG server.

If success then you must confirm that you have dhcp options 66 and 67 set correctly for this client vlan.

@wanderson This will assist you: https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG

@UWPVIOLATOR What I would do is run the maintenance commands, and then I would open up notepad and change all the maintenance commands into select statements. I’d then ask the team to start noting what they do, when they do it concerning fog. Then I’d just start running those select statements every 15 minutes to every half hour - and when the bad row pops up, I’d ask around and see what people did during that time. I’d also look into the history table for things there during the same time. I’d look in the apache error log for something during that time. Even if you find no errors in these logs, it’s worthwhile to see what IS in there during that time, those can be clues. Then - I would begin the tedious task of reproducing the problem and identifying the single thing that is causing it. Reproducing the problem is a lot of educated guesswork based on what you think is causing the problem. If at the time the issue happens for example, someone was registering and imaging a new system - You’d have to test registering by itself - then imaging - using the same image they did - and possibly even in debug mode to identify the single thing that is doing it. Just as example. What I’m expecting though is it’s being caused by something being done in the web GUI - you guys just need to figure out what that thing is - and narrow in on it by separating out variables & unknowns and testing individual things. Example - I don’t know if my application isn’t working or if my antivirus is blocking it. Well, uninstall the AV and try. You have to isolate. And to begin isolating, you have to have a general idea of what you’re isolating.

@Wayne-Workman thanks! solves the problem

Thanks EVERYONE! this should give me enough information on getting 700+ updated and moved over to the correct OU although I didn’t really wanna start mucking around with the DB but I’ll take a snapshot before doing so. Thanks!

@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.