Latest FOG 0.33b
-
Hi Tom.
Running new install of r1141 on Ubuntu LTS 12.04 to test capone, but image upload seems to be doing a raw upload rather that an ntfs one.
Attached are pxelinux.cfg files and screenshots from r1126 and r1141 clients
r1126 works OK, r1141 uploads as raw.John
[url=“/_imported_xf_attachments/0/520_boottest_r1141.zip?:”]boottest_r1141.zip[/url]
-
I’m working on a fix for this issue as I’m well aware of it already. My fix is basically rewritting the fog scripts and adding an upload and download script, to separate the code base slightly for easier management. I’m still testing it.
In the mean-time, Find the lines that deal with setting the fstype variable in the FOG Scripts, and make sure they’re using double quotes rather than single quotes, I don’t think Shell scripts like single quotes to identify strings the same way php does, which may be what’s causing the issue.
Does your system have multiple MAC’s? You can check what’s being sent to the inventory.php service file from your access log file. Chances are, I’m only guessing, is it’s sending the data as something like:
inventory.php?mac=00:01:ab:2c:3f:1b%7C00:01:ab:ac:af:ff which would explain why it’s not liking the MAC Format. -
It’s VMs with one NIC, will check tomorrow
-
r1143 released.
With it comes a notice:
[B]FOG SCRIPTS ARE IN ALPHA/BETA TESTING ONCE AGAIN.[/B]init.gz is perfectly fine by itself but I’ve rewritten the main fog script. Three new files (besides fog.bkup2 which is the original fog script) are included to help me with managing what goes wrong where.
fog.checkin performs checkin tasks for download, upload, and multicast. I Have test this and it works for download/upload, haven’t yet tested with multicast checkin, though it should work as it’s a part of the download checkin anyway.
fog.upload, I’ve tested single disk resize and single disk multi-part functions. It should work as well. I’ve also dabbled, a little bit, with the raw upload at it too seems to work fine.
fog.download, I’ve tested single disk resize download and a minor single disk multi-part test. Don’t know if mps (single disk multi-part) is working properly though I haven’t seen any major issues thus far. I’ve not tested anything dealing with multicast yet.
As a side note, it appears the fstype is working as expected now, though I haven’t had a proper chance to verify this is the case.
As I test various things and notice issues, as always, I’ll update and figure out a fix. If you haven’t noticed by now, I’m working in a progressive aggressive pattern now. I find an element that is “broken/borked” and work it out until I have a fix in place.
-
Hey Tom,
I am having the same issue a VincentJ the machine only has one nic and it only happens when I send the command to to do a hardware inventory from the fog advance snapin module. If I do a full inventory from the machine it self everything works fine the machine also only has one nic installed and its a physical machine not vm.
-
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.
