Latest FOG 0.33b
-
fog.download found an issue with multicast. I stored the command in a variable and needed to eval it first.
r1144 released as a fix for multicast download. MPS is working now. Haven’t fully tested SDR. MPA isn’t tested either as it’s usually taken care of and only has one extra step but is basically the same as MPS.
-
r1145 released.
Fixes an issue where if the state of the multicast task is in-progress, it will kill the task, but not remove it. We don’t want that, so this has been corrected. If it’s complete, or canceled, the task gets killed properly.
-
I’m guessing this mac thing is to be expected. The inventory.php file uses the base64_decode for the MAC Address. It appears the bas64 command being sent for one of these jobs is not working properly. I don’t know why yet though. Maybe because it’s expecting something else for the mac address?
-
could it be sending the wrong format?
-
I’m starting to think it’s because the mac address is sent during image task creation. Meaning the mac being set within a script isn’t working properly. Specifically, the inventory task from the gui starts the fog.auto.reg script. I’m thinking the mac variable within that command isn’t working properly. If I go to debug and run this script, all seems perfectly fine. Can you try the same?
Boot your client into Debug mode (no tasks).
Once at the command prompt type:
fog.auto.reg and press enter.Does it still fail?
-
Tom that works it imports the machine into the database no problem with missing information of course.
-
i installed the r1145.
now i test single disk multiple partition upload, and multicast download to 25 pc, then i report results here.my partition schema:
sda1 ntfs
sda2 ext4
sda3 linux-swap
grub 2.x installed.one question: FOG_PIGZ_COMP variable is to do compression when image is crated. Is used the cpu of client or cpu of fog server? support multithread/dualcore cpu?
Tom, thankyou very much for your work, if you need hardware to help developement i can donate to you, let me know.
-
[quote=“fabritrento, post: 21934, member: 21607”]i installed the r1145.
now i test single disk multiple partition upload, and multicast download to 25 pc, then i report results here.my partition schema:
sda1 ntfs
sda2 ext4
sda3 linux-swap
grub 2.x installed.one question: FOG_PIGZ_COMP variable is to do compression when image is crated. Is used the cpu of client or cpu of fog server? support multithread/dualcore cpu?
Tom, thankyou very much for your work, if you need hardware to help developement i can donate to you, let me know.[/quote]
is all ok but a error is printed on client:
- FOGFTP: Failed to rename file. Remote Path: /images/labinfociro, Local Path: /images/dev/00215a68eb2a, Error: ftp_rename(): Rename failed.
this is a bug introduced with latest test releases.
-
FOG_PIGZ_COMP is now included in the FOG Web GUI as a range input field. The range is from 0 to 9.
0 means worst compression, and should mean the fastest upload speed with the largest amount of disk space in use.
9 Means the best compression, but slower upload speed.I don’t want to remove the field as the FOG Upload Scripts rely pretty heavily on it.
I don’t know what’s causing the FTP issue you’re seeing as I’ve not yet seen the error myself. Maybe provide some more information about the type of image it is. Specifically if it’s Multi-Part, raw, or Resizable.
-
Found the issue with deployed inventory update.
fog.auto.reg was trying to send a variable ${mac_deployed} if the fog script is deployed from the FOG GUI, the inventory appears to update appropriately, but the scripts, if deployed, tries to send an unset variable. Added to the fog.auto.reg script now is the mac_deployed variable.
Now I found another bug doing this. When the inventory is performed, it performs it like it’s a new host. This means it actually resets, to an invalid, hostID and hostname.
I’m testing once again to make sure this works as expected as we speak.
-
r1146 should fix these issues. As always, if you notice anything else, please let me know.
-
r1147 released.
Fixes an issue in fog.upload where I was supposed to check if sector 63 is not the case, but actually but if sector 63 is the case.
-
Hey Tom,
So the hardware inventory is still having issues. after the hardware inventory updates the database instade of restarting I get an error “* No Active task found for hostname (Mac Address)” It could be because of two nics I will try to remove one and let you know.
-
Also it seems when I add computers to the database this way it will not allow me to remove them from the database it just sits there loading been loading for about 3 min so far.
-
Just got done testing it happens with one nic also.
-
What revision are you on?
-
I am on 1147 the one you just released.
-
[quote=“Tom Elliott, post: 21939, member: 7271”]r1147 released.
Fixes an issue in fog.upload where I was supposed to check if sector 63 is not the case, but actually but if sector 63 is the case.[/quote]
i test right now if upload problem ( ftp error) is solved
-
r1149 released.
Should fix issue with ntfsresize once upload is complete.
-
r1150 released.
Should truly fix inventory deploy bug.
Was awaiting ##@GO but being sent ##. All the other scripts referencing the Post_Wipe.php file were requesting ##, so made the change to the script (fog.auto.reg) and updated the init.gz
