Unable to Deploy Image
-
Recently I am having issues deploying an image to clients. I am able to upload the image from the device to the fog server but then deploying to another machine - nothing.
Download task created for [U]machine [/U]with image [U]DellAllinOne8GBWIN764[/U]
The log show the machine ran for a total of 4 seconds.
fog machine 2015-02-04
20:55:04 2015-02-04
20:55:08 00:00:04 DellAllinOne8GBWIN764 DownloadI am still able to pxe. The full registration works, but again reboots before the image deployment piece starts. Same outcome when creating a task for the machine.
This is not specific to one device - I’ve tested other devices with the same outcome. Can someone point me in the right direction?
Running [B]1.2.0[/B]
Kernel 3142 -
Also - it is not specific to this image. I have 5 different images, none that will allow the machine to start the process.
Started sometime last week… maybe an Ubuntu update? I did not have an issue imaging prior to whatever happened.
-
Are you able to run a debug download task on one of your machines? Please provide some more information on when exactly the machine reboots if it does.
-
Well - I will test that as soon as I revert back to an older kernel. The new one will not allow these machines to register. I’ll start fresh Monday.
-
Yes (after updating to the new kernel) I can boot to debug.
Is there a log file somewhere that will tell me what is happening when the device attempts to download an image?
It runs through the process and displays “task complete, restarting” all in a matter of seconds. Fog thinks it has uploaded the image without issue but it never makes it to the progress screen showing the imaging partition.
Sounds like this guy also had my issue:
[url]http://fogproject.org/forum/threads/windows-client-notices-task-reboots-and-boots-into-pxe-but-just-goes-back-to-windows.10139/[/url]The resolution was: TFTP Server Settings were set incorrectly
Hopefully this helps you point me in the right direction. Thank you for your time.
-
I’ve verified that my TFTP Server settings match the fog server. (instructions via [url]http://www.fogproject.org/wiki/index.php/Unable_to_connect_to_TFTP#For_Versions_.24-.32[/url] )
My tftp username/password match my fog server un/pw. The storage group matched the fog un/pw.
Running tftp -v X.X.X.X -c get undionly.kpxe - reports no issues. I received a reply (103272 bytes in 0.1 seconds) etc.
The firewall is disabled. (sudo ufw disable).
My fog server is not the dhcp server - dhcp is setup on a windows box.
-
The tftp test you have is correct.
What is the option 67/filename setting on the DHCP server set to? My guess, you still have it pointing at pxelinux.0
-
I checked that as well - it is pointing to undionly.kpxe
-
if you’re running 1.2.0 and [quote=“Just10, post: 41920, member: 28415”]
It runs through the process and displays “task complete, restarting” all in a matter of seconds. Fog thinks it has uploaded the image without issue but it never makes it to the progress screen showing the imaging partition.
[/quote]
then your tftp settings are likely correct, and it’s a different issue -
I guess I’m confused.
If you’re able to boot to the Debug system, the problem is not in anyway to deal with TFTP.
Using different/newer kernel’s poses problems?
Can you take a video and post it so we can see what you’re referring to?
-
the computers that you’re trying to download images to, have the hard drives been initialized? are they brand new?
-
Tom,
When I noticed I had an issue, I upgraded to the Kernel - 3.14.2. I was then unable to pxe boot to the fog page (to register the client, memtest etc). I installed Kernel - 3.18.4 and resolved that issue.
Here is the video (excuse the auto focus). I have a task set to download. The video ends at the point that the machine restarts back to the fog pxe menu and the tasks shows complete.
[media=youtube]X29p6H78EXw[/media]
-
The machines were delivered to us from Dell w/ a french version on Win 7 installed - they have an OS loaded on them already.
I’ve also attempted this using a laptop that I have imaged prior and receive the same outcome.
-
This definitely sounds like what junkhacker states.
Your drives are completely uninitialized and cannot find a partition to boot from.
This isn’t a kernel issue. The unable to pxe boot sounds more like the file was just bad, not necessarily a direct problem with the kernel. This meaning, the kernel trying to load was wrong for the init and probably ended in a kernel panic, or in the case of memtest, the file memtest.bin was missing or not correct. My guess is you’ll still see issues with memtest of the file is bad as your redownloading of the kernel would have no affect on memtest directly.
To fix the partition problem try the steps here:
[url]http://fogproject.org/forum/threads/quick-format-to-ntfs-with-fog-for-noobs.10349/[/url]If this does not help, the other thing I’d think to check would be the format the mbr file is trying to push. If you do a download debug, it should pause you a whole bunch of times. When it gets to the No Extended Partitions point, ctrl + c out of it back to terminal.
Once in debug - download, you’ll get terminal prompt. Type the command fog and wait for the no extended partitions point and ctrl+c out back to the terminal. Then run fdisk -l, what’s the output.
-
do you mind upgrading to an svn version? there are a number of features that have been improved, and while i can’t guarantee that whatever is causing your problem has been “fixed” it is possible. at any rate, the debug mode in the newer versions lets you actually read what’s going on during a task instead of just blurring by.
my production server is currently running svn 2948 and appears to be stable. normally i would recommend updating to the latest svn, but i know that tom is working on a few things pretty heavily right now and a few features might be disabled or broken.
to update to version 2948:
[CODE]cd ~
mkdir svn
cd svn
svn checkout https://svn.code.sf.net/p/freeghost/code/trunk@2948
cd trunk/bin
sudo ./installfog.sh[/CODE] -
There’s only one feature that’s “broken/disabled” for right now.
That’s the group page membership capability to change the image right from that particular screen. Everything else should be stable and functional.
-
I am now running 2948. Same issue. Running through download debug now. I will report back shortly.
-
How does your partition layout look like? Please run this command on one of your clients (e.g. bootup in debug mode):
[CODE]sfdisk -d /dev/sda[/CODE]
Which files do you have on your FOG server?
[CODE]ls -al /images/DellAllinOne8GBWIN764[/CODE]
What image type is configured? Single Disk Multiple Partitions? -
ls -al /images/DellAllinOne8GBWIN764 shows:
d1.mbr
d1p1.img
d1p2.img
The image is multiple partition - single disk.sfdisk -d /dev/sda shows:
/dev/sda1/ : start= 2048, size= 204800, Id= 7, bootable
/dev/sda2/ : start= 206848, size= 976564224, Id= 7
/dev/sda3/ : start= 0, size=0, Id=0
/dev/sda4/ : start= 0, size=0, Id=0 -
after typing that… I realize the image is probably larger than 40gb. If our techs put 40gb drives in these machines - I have a bigger problem.
