Posts made by Tom Elliott

He’s referring to the bugs found/fixed and finally getting an image to upload.

His is also a very special case, in that he’s trying to (successfully) do an image of a Dual boot system.

download the new init.gz with the original fog script: (slightly modified to use double quotes where there was single quotes.)

[code]cd /tftpboot/fog/images
mv init.gz init.gz_r1161
wget -O init.gz --no-check-certificate https://mastacontrola.com/fogboot/images/init.gz_origfog[/code]

just run the command:
[code]svn info[/code]

Can you try sysprep without driver pack installation?

It would seem possible, to me at least, that that whole Hostname early thing is causing the issue. To my knowledge, hostname_early sends if the hostname=blahblahblah in the 01-XX-XX-XX-XX-XX-XX file is filled out. It’s supposed to check if hostname_early is enabled on the server and, if so, set this up, but I have a sneaky suspicion that this variable is being sent in either case.

While this doesn’t affect me, it would seem to make sense that driver packs are making changes to the sysprepped system, after another change has already happened. This would, theoretically, explain why you’re seeing this issue. This is what my mind is telling me. I really haven’t changed anything too drastically. I can, if you’re willing, create an init.gz file with the original fog script and see if all works for you.

I ask this because I am only using a sysprepped image at work and all works perfectly fine.

If you revert the system to r1141 (before the fog scripts were regenerated) and deploy an image, then update to r1161, and re-upload the image, then try to redeploy, does it work?

r1161 released should fix the inventory issue.

In your /etc/exports file, can you add to:

/images *(…) Add at the end, inside the parenthesis, fsid=0
/images/dev *(…) Add at the end, inside the parenthesis, fsid=1

Then restart the nfs-kernel-server service with:
[code]sudo service portmap restart
sudo service nfs-kernel-server restart[/code]

Still need some more information.

You say the problems exist before FOG Starts to pull/push an image from the computer. Does this mean that it’s booting into FOG, or it just gives the menu but never loads the bzImage/init.gz file?

If it is booting into fog, does it not find the hard-drive or network?

Have you tried other kernels? I’m guessing you are just using what came with 0.32, which if memory serves, is 2.6.39.2 for the kernel. I’ve got a kernel built on 3.13 and has all possible linux drivers for networking installed. It also has many options for Hard Drive such as SATA, SAS, PATA, RAID, etc… so it may cover all of your bases here.

It is possible to upgrade ubuntu without reinstalling FOG again, but if you don’t remove FOG and you perform the installfog.sh script again, it will not “reinstall” it will just use your original settings and update as and where necessary.

The passwords are not updated through the config.php file. The only exception for that is the initial install when you first install FOG. They’re only there to make sure things are setup. The only password you need in place is the MYSQL_PASSWORD in /var/www/fog/commons/config.php and in /opt/fog/service/etc/config.php

After that, make sure all passwords are set using the FOG GUI.

The first place to check is under Storage Management->Storage Node->Management Username/Password.

The second place to check is under FOG Configuration (Other – The ? icon.)->FOG Settings->FOG_TFTP_FTP_USERNAME,[FONT=Ubuntu][COLOR=#333333]FOG_TFTP_FTP_PASSWORD[/COLOR][/FONT]

[FONT=Ubuntu][COLOR=#333333]The PXE Menu passwords will be encrypted when you enter a new password and click Save PXE Menu, so there is no need to encrypt with FOG Crypt. FOG Crypt is used for the Active Directory password.[/COLOR][/FONT]

When you say, not connecting, what do you mean?

It won’t let you image?

If that’s the case, make sure the /media/ImageDisk directory and all subs have chmod 777 recursively:
[code]chmod -R 777 /media/ImageDisk[/code]

Next, make sure the .mntcheck files are in place with the following command:
[code]touch /media/ImageDisk/.mntcheck
touch /media/ImageDisk/dev/.mntcheck[/code]

With any luck, this issue is now fixed.

It seems, with all the coding I’ve done, I made a little typo, I had a 2 where a 3 should have been. Basically what this means is, it was converting your hard-disk to gpt. The imaging would work fine because, for all technical purposes, the partitions were created and created properly, but then sgdisk would run when it shouldn’t have.

Hopefully this fixes our issue with this. r1160 should contain this fix.

This particular issue seems to me a problem with the switching equipment. Maybe you had a broadcast storm (a switch with a cable that plugged back into the switch forming a loop) and sending all the data in the wrong direction on the network. I’d start be removing as many variables as you can. Take that system and a mini switch and plug the fog server nic directly into the switch. Connect the computer to the switch and try imaging.

r1160 released. Should properly fix capone now. Had a variable sending the full image path name rather than just the image name. This caused issues because imagePath was looking for the file(s) in: /images/images/winxp, or something similar, and would return as invalid image file.

r1158 released.

Addresses the issue jbsclm reported.

Still trying to figure out Greg’s issue in the other thread, though I’m not seeing the same problem.

As for jbsclm’s reported issue of Windows XP resizable giving bsod, if you try to image to the same system, does it give the same problems? Are you sure it’s a problem with FOG and not a problem with the image?

jbsclm,

I’ve pinned this particular issue out.

I’m still trying to replicate Greg’s issue so if I’m not responding right away, you know why!

Thank you for reporting and being patient with me.

Do you mind doing me a favor? Can you give me the steps I need to do to try to replicate the hang so I can trouble shoot.

I’ve already installed capone plugin.

I’ve not set it up with anything as I don’t understand how it works.

And you’re sure, what you’re searching for, is actually in the table?

I’m trying something out if you’re patient with me.

Please update to r1157 and try again.

The only major change for the fog scripts was in 1141 fog creates the partitions 1 and 2 in windows 7 based image deploy. In 1142, in the fog.download script, I removed this but starting to think it is still needed. r1157 contains this and hopefully helps you out. I think the reason you’re seeing that error is the 100MB partition doesn’t actually have any data on it which may contain the information your system is looking for.

I haven’t a clue as to where to begin looking.