Hi Tom.

I am seeing the same issues with FOG 1.0.1 and a Win7 client that used to work with snapins. For example, fog.log on client shows that is it downloading my notepad.exe test snapin and “Starting FOG Snapin Installation.” but it never pops up notepad, and I never see a "Snapin installation complete"in the log.

A couple quick suggestions to aide in debugging snap-ins, and a couple possible bugs reports:

1. the fog.log lists the ID, and some other info about the snap-in, however, it does not list the snap-in file downloaded. It just says "starting FOG Snapin download then Download complete. Would help to know that it was requesting the correct file in the client-side log

2. The fog.log shows FOG::SnapinClient ID:x (where x is the task’s ID in the DB)

however, no where in the FOG web interface does it list a snapin’s ID nor the taks’s ID. I can query the db directly, but another column (task ID) in the task lists would be helpful I think to normal end-users. Also, maybe list the snapin’s ID in snapins lists.

BUG 1: If I queue a snapin to be deployed to a client, I see the snapin in “active snapin tasks” and in “active tasks” OK, so far so good.

If I delete the task from “Active tasks” it is still listed in “Active snapin tasks” list

BUG 2: And finally I am noticing something odd in the FOG Client

On startup (Win 7) it goes through all the module startups and delays, etc… Then, after it finds and downloads the first snapin, logs “downloading complete” and “starting FOG Snapin INstallation.” the only module that logs to the file is the FOG::TaskReboot which logs over and over again every 5 mins:

FOG::TaskReboot Attempting to connect to fog server…
FOG::TaskReboot No task found for client.

No other modules seem to be doing anything after that. It’s like the Snapin module did not complete its task, and is holding every other module back from running - Except for the TaskReboot module.

[quote=“Tom Elliott, post: 25895, member: 7271”]Bill,

Sanboot is not as you’re thinking it is. On most systems, that particular sequence of lines works great. That line really just tells the system to boot from the hard-drive.

However, there are some known issues where sanboot doesn’t like to operate properly. Most notably with HP and Dell’s. For that, you have to change the sanboot lines to simply say exit and all should work.[/quote]

The laptop in question is an IBM Thinkpad (well, Lenovo).

Where do I modify the sanboot line? I see that the default.ipxe file specifies: [url]http://192.168.254.9/fog/service/ipxe/boot.php[/url]

But that php file creates the boot menu on the fly from a db query based on the host’s MAC address(es).

wait. ignore the 64bit vs 32bit coment.

OK, I have determined that this does appear to be some type of incompatibility with a Proxmox qemu VM.

My laptop successfully iPXE booted into the new FOG menu with a 400 second countdown to HD boot. Which it then wanted to boot from SAN (which does not exist)

I see in : [url]http://192.168.254.9/fog/service/ipxe/boot.php##params[/url]

that the (default) local boot is defined as:
:fog.local
sanboot --no-describe --drive 0x80 || goto MENU

I alse see (in the web admin interface) where to set the default timeout, but I do not see where to change the sanboot to /dev/sda1 (or whatever that option would need to be)

I would be happy to offer any additional information on my proxmox VM system to help in that regard.

Also, I tried the virtuo and realteck NICs in the VM with no changes to iPXE hanging. Any thoughts on the VM being 64bit vs 32 bit?

Thanks!

Ok… I am new to iPXE and my first interaction does not appear to be a positive one.

My virtual test machine gets the undionly.kpxe from the tftp server, file prints out a few lines, and then hangs.

See image:

[ATTACH=full]672[/ATTACH]

If it matters/helps, my virtual machine is on a proxmox 3.1 server - so the VM is a qemu VM with a virtualized Intel e1000 NIC

[url=“/_imported_xf_attachments/0/672_FOG-iPXE-20140423.png?:”]FOG-iPXE-20140423.png[/url]

[quote=“Tom Elliott, post: 25885, member: 7271”]I’m going to guess that you updated from 0.32 to 0.33?

Did you adjust the options 66/67 so that it points at the undionly.kpxe file?

The /tftpboot/pxelinux.cfg folder is not used in 0.33 anymore. Tasks are generated/checked directly from the database.

I’ll find the post with the changes needed to the FOG settings page so things will work properly for you.

Did you clear the original tasks table so as not to cause issues with DEBUG Messages?
From mysql command in the fog database:
[code]truncate table tasks;[/code][/quote]

<facepalm>

Of course I didn’t follow any of the on-screen instructions when I ran the install.

I saw the dhcp options message and thought to myself “yeah, I already set up my dhcp server next-server option… I’m all set…”

Sorry for the static!

Making modifications now.

Tom, I just got my v0.33beta FOG server vm back up and updated. I see the new columns we spoke about for the images (image size etc) Thanks!

I am having an problem getting an imaging task to start.

The issue I am seeing is that when I submit the imaging task, no file gets created in the /tftpboot/pxelinux.cfg directory specific to this host, so it just keeps rebooting due to the imaging task never actually starting, but the task being active in the db.

I checked permissions on the /tftpboot dir and the /tftpboot/pxelinux.cfg dir and both are 755 fog:root

Apache server runs as apache, so I changed the ownership to the apache user and re-tested. Still, no file is created for the host in pxelinux.cfg directory.

Junkhacker Not a problem. It’s really my fault for not being on top of the development before asking questions.

Firing up my 0.33b VM now.

Bill

Junkhacker, re: “actual size already displayed” I need to get my 0.33b demo server back up before commenting further. Our client is using 0.32 and that is where the request came from because on that version the only columns listed are:

Image name, Description, Storage Group, Edit

My apologies for asking for something that is already in upcoming release.

Bill

re: physical space on server vs. drive size…

Maybe provide both if possible? They are gzipped on the server, and getting “size on server” would be easy. However, obtaining and displaying the “actual size of image” would not really be possible unless it was calculated on creation and entered into the database.

At the risk of stating the obvious: gunzip -t on multi-gigabyte files is quite time and cpu intensive, so it would not be something that could be figured on the fly

Personally, I think something like “total size on server” would suffice. Or (being more creative) listing each partition and mbr in a smaller font under the image’s basic information might be nice too.

But getting back to our client’s request, it was really brought up to us in the format of “I have this image listed in FOG, and I am not sure if I actually uploaded the imgae or if this was/is still just a place holder… it would be nice if I could see if the file(s) exists or not and if they do, their creation date/time would also be useful”

So, really, just some additional basic information would probably be enough.

Bill