Latest FOG 0.33b
-
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.
-
r1065 is released,
Schema will need update to take on the latest table type for information.
init.gz has been updated to get send the image type back to the server for processing this report.
Imaging log now contains Image Task type. I’m out for the rest of the night and possibly day tomorrow as I need to get tires put on my car.
-
with sysprep… at work it names the machine NewDeploy and then the fog client changes the name to whatever is needed. Depending on when the unattend.xml sets the hostname doing it early may or may not work. I would have to research it.
Is there any chance of fixing the FOG client? At least then there is a solution that works with windows 7 (and probably 8).
-
Hi Tom
here some bug report
loadkeys : command not found in debug mode
web site translation didn’t work anymore on rev1064
bug fix
computer power off after imaging
and quick host registration loop[url=“/_imported_xf_attachments/0/468_auto.register.php?:”]auto.register.php[/url][url=“/_imported_xf_attachments/0/469_S99fog.zip?:”]S99fog.zip[/url]
-
lanfue,
I’m rebuilding the init.gz to fix the shutdown=“on” to shutdown=“1” issue you annoted in the S99fog.zip file. My configuration apparently also lost the kbd for some reason, so it’s also being added back in as we speak.
I expect some web site translation not working but the majority of it should still work. When you say it’s not working, are you saying it’s not loading the language translation at all or some parts of it aren’t working?
I’m fixing the auto.register.php based on the changes you’ve suggested. My guess is quick reg was looping because it was trying to inventory but there was no inventory to save. Sorry about that.
-
Never mind the translation. I put a step outside. Locale was set, but only for a small amount of time. The next link action change the environment and would reset to default of en_US.UTF-8. This is now fixed as well. Will post revision soon.
-
r1066 should fix all of the above, with some expectation that menu items won’t all necessarily be translated properly yet…
