Latest FOG 0.33b
-
I know what the problem is, and have fixed the issue. During all my “changes” I forgot to require the text.php file for menu generation, as well as the language bar generation.
Hopefully 1056 will work much more betterer.
Please forgive my single file overlook there. I’ve been modding a lot of files lately, so I think it warrants a missed file here and there.
-
you should give coding lessons
i’ll do some more tests tomorrow
-
r1057 released.
This should remove erroneous error messages, such as Illegal Offset Type, and the functions need to match. I doubt I’ve gotten all, but it should be close.
-
Something I’ve noticed… When you make a host the client settings are all off.
The Rename early still isn’t renaming my machines. and the fog service seems to be giving an error.
Could one of the changes in the database mean the client is looking in the wrong place?
[url=“/_imported_xf_attachments/0/466_HostnameChangerError.png?:”]HostnameChangerError.png[/url]
-
Are the services enabled on the FOG Server; they have to be globally enabled, and enabled on the Host as well.
Rename early works on mine, but that was testing with Windows XP. I’ll test again with both XP and 7 just to be on the safe side.
-
It is globally enabled and enabled on the host. I was thinking a change in database might be the cause due to ‘Hostname not found in the database’
I know the database from 0.33 isn’t compatible with 0.32… has this variable been moved/renamed.
My client OS is Windows 7 Enterprise 64.
-
to my knowledge, the host name field is still stored in hostName on the hosts table. However, I’m not sure if this was the case with 0.32.
I’m checking my code right now, but I’m not seeing why it would be returning with that.
-
Can you perform a restart on the client, and read the error logs from the FOG server?
I want to see where it reports the errors and at which times. Mine is close, but your’s is already operational.
Again, you can do this when you want.
-
where is the error log from the fog server stored?
-
/var/log/apache2/error.log I think.
-
Here is what i found…
10.0.0.211 is the VM i images
10.0.0.226 is my management VM with the web gui opendoesn’t mean much to me, there is a ton of log in there…
[url=“/_imported_xf_attachments/0/467_serverlogextract.png?:”]serverlogextract.png[/url]
-
Well those errors are easy to forget. I don’t see anything useful in those logs.
-
other than letting you remote into my test setup so you can look under the hood, i’m at a loss other than the server isn’t giving the client a hostname to change to… or the client isn’t looking in the right places. how is your test with the early hostname changer and windows 7 going?
-
It’ll be tomorrow for me. By that I mean its 3 am and I still haven’t slept yet.
-
r1059 released. It will require a database update, but it’s automated. So if you update, you’ll see the typical database install/upgrade redirect. It’s only adding, so no worries about data being lost.
It adds FOG_PIGZ_COMP to the gui as a means to automating and telling what kind of compression you want.
r1060 released as I forgot to add the Host.class.php file updated to reflect/add this change and add it to the pxe generated file.
-
As far as I can tell, hostname changer early isn’t working with windows 7. However, I am still performing some testing as all I’ve got to work with on Windows 7 is sysprepped images. This means it’s just waiting for me to type a username and hostname. So maybe it is working, but I don’t have proper methods to test…yet.
-
All,
I think I’ve finally got image logging actually working again. It was broken before because the task never sent the image name. The function, itself, worked find, but the sql task required the imagename. I added that to some of the service files and added it to the calls to set the function (including adding the function on the Upload tasks).
Also I found an issue with Windows XP images. While, after you initially upload a proper image you could deploy the image. You couldn’t then take that image and upload a new one. It’s because parted naturally creates the partition starting on the first sector. Because XP usually starts at 63, it didn’t match with the “checks” within the fog scripts. So you couldn’t use an already made XP image that’s been deployed to upload a new image. Lets say for performing updates, or adding your necessary other softwares. I’m looking at a fix for this. Basically, I haven’t seen any issues with the system even if it is starting on sector 1. Theoretically, I just need to upload the image, then redeploy that same image on the machine and wait for it to boot. If it works I’ll update the fog script and init.gz on svn.
-
Alright,
So as it turns out, we do still need the 63s and it was created. fdisk in this doesn’t natively show sectors, it shows, as far as I can tell, cylinders. Changed out the fdisk -l with fdisk -l -u, and it seems to work properly for xp now. Will update shortly.
-
r1063 has all these corrections. Prettier (more like Pre_Stage1.php) Post_Stage2.php. FOGFTP->delete now recurses directories if they exist and delete the files within, then deletes the directory so delete functions works nicer. They also exit cleanly, meaning if it fails (most likely because the file doesn’t exist) it’s not going to impact the operation therein. This means I was able to remove the checkexists function.
I know I have to be close to meeting everyone’s expectations.
-
r1064 released. Should fix the error of saying WEB_ROOT is already defined. Also updated the db schema. If you didn’t get it before, I’m sorry it was missed, I thought it was there, but apparently it wasn’t.
Yay imaging log. Now to add another field to the imageLog table that tells you if it’s an upload or download imaging task.
