Success
I first tried bzImage32 network boot ok “client system info” returned
invalid or corrupt kernel image.
boot:
next I tried bzImage
network book ok client info passed
Ready to image the T440s Monday morning should be fine Ill report back to let you all know.
Thanks for the roadmap much appreciated
John R

Is the tftp server correct?

Does the file undionly.kpxe exist in /tftpboot/?

Have you copied the contents of /tftpboot/* to /var/lib/tftp/?

Don’t know if you got it right by now, but here it goes how I solved it.
I write another thread in BUGS, about this.
It has to do with the way the script fog.download counts partitions.
If you really need multicast with multiple partitions:

unzip init.xz (the same goes for init32.xz) with xz -d init.xz mount the init file in a loop device with: mount -o loop init sometempdir/ go to sometempdir/bin with cd edit fog.download, and search for the part that does the multicast write, for your “method” (mps or mpa) look for the part that does a loop on each partition, and fix it in a way that it checks for the existence of the file
(something like if [ ! -f $imgpart ] ; then echo “Partition file missing …jumping”; sleep 1; else writeMulticastImage; fi )
(look in the “not multicast” lines or the previous multicast method, for just linux type) save your file, and back to the init file dir. zip it with xz -C crc32 init

Put the task again to try it.

Try it again …you should briefly the message “Partition file …” and get the correct ones to the partclone/partimage program stream

Other related bug is in the MulticastTask.class.php. If you have 10 or more partitions, you need natsort() instead of sort().

Maybe you need a (not so much experienced) linux shell programmer to help.

P.S. Be sure to have also installed the php-process extensions to PHP, as the killing of multicast tasks uses posix_ functions in it. (That is for a CentOS / Redhat server; on Ubuntu server I have not tested or searched for them)

I can not promise anything but I will look into implementing this feature into the new FOG Service. It shouldn’t be overly difficult. If and when I do get around to it, would you be willing to beta test parts of the new service to see if the local port network printers work properly (I don’t have any to test on)?

Network issues I’ve experienced: STP taking too long to enable forwarding between network stack reloads, poor quality network wire or damaged runs (this is where I experienced your exact error message, it will work on dhcp, but fail on bigger packets), and amazingly enough, bugs in the switches (in my case, Cisco SG200’s with layer3 protection that could not be disabled - a firmware fix is available now) that caused issues with UDP on privileged port ranges (NFS), and slow DHCP servers.

Tom, first, thank you so so much for the work you do on the FOG project. I have been a fan for many many years. I thought that LVM support had been achieved in this latest release. So my heart is broken, but its cool. Fog is still a great product and hopefully one day LVM support will be included. I can only hope to one day contribute like you do. Thanks again!

To add on to this, While I completely agree with Jayme’s post, it seems to me that this issue is known about.

First, it seems to me that as you’re using XP, this problem is a known issue in a few threads. I’ve been doing my best, but as I, as many of us here do, work in a school district, am pretty swamped at work. The quick fix, from what I could think of, is to push XP/Vista images into the same category as how all the rest operate. Windows 7/8/8.1 resizable images are typically stored in /images/<imagepathname>/{rec,sys}.img.000

XP and Vista supposed are a singular file in the format of:
/images/<imagepathname>

I’ve pushed the changes to bring xp and vista into the same realm as Windows 7/8/8.1, but haven’t had any of either of these images to test it with as I have been busy at work. I’m sorry.

Second, the “hanging” for a second then error exit seems to me that the problem is more related to locating the file which leads me to the information in the "first’ part of this posting.

While I understand the “reddit” post may or may not have been done by you, it seems that Junkhackers response was an indirect (“We need more information.”) rather than a direct stab at you. The comments therein that post seem a bit harsh and rash. While it could’ve been stated more clearly, he was simply trying to get the point across that he uses those systems to actually do work and they work fine. He probably wasn’t using XP, and he was attempting (I think) to tell you the system in and of itself works fine.

The fog user password is correct? What I mean, is while the Storage Management Page is showing the same settings, is it possible somebody changed the user password on the FOG Server itself? Or even yet, that the password never held or became corrupted on the server?

You can reset the fog user password on the fog server with:
[code]sudo passwd fog[/code]

Retype the password for the fog user twice and all should start working.

Ok. I will give it a try as soon as I can. Thanks.

Glad you got is sorted, sometimes, a fresh install isn’t such a bad idea (even if you JUST installed fog) 😉

his comment is a quote from the ipxe forums about the different options to compile ipxe with. we do have a .pxe but have not had any use for a .kkkpxe

if i am correct about it being fixed, then it is in the svn, yes

Thanks for letting us know, personally, I am like you, I don’t really use the Multicast features, just when someone says it’s not working so I can see what it is doing 🙂

Thanks for all the information it may help in finding the culprit and fixing it!

Of course if you troubleshoot further, feel free to leave some notes.

Moving the file should be fine. The reason the task isn’t completed is because it can’t link properly to the image. The fact that you’re seeing the “scrolling” asterix’s tells me that the image upload is complete, just it can’t copy the file from /images/dev to /images/<imagename>. Once it performs that feat, the task will complete from the DB. It’s just unable to perform the copy at the moment. You can safely power off the “uploading” machine, perform the move from /images/dev/<macaddress> to /images/<imagepathname>

It was. Debian creates that line by default. I fooled around with the localhosts file and DHCP config in order to get the isolated network running and in the process changed the former. Perhaps I was telling the computer there was only one machine on the network? I don’t understand enough about computer networking and how a PHP script creates a magic packet to fully answer the question.

Curiously WOL still does not work for uploading images, but since our technician computers are within 20 feet of my desk that is not a big issue.

UPDATE: Well WOL worked once for an image upload. Still not going to worry much about it though.

so I thought.

thanks Tom!

If you’re daring, are you trying out the latest SVN? I ask because with Mentaloid’s help, he created a setup to not startup certain services until FOG has a network device and mysql is running. I don’t know if this will fix mysql from starting at reboot, but you could try this version and see if it helps you out at al.

Another issue I’ve seen and written about on my github site is about a similar issue with FOG. [url]https://github.com/mastacontrola/fogproject/issues/1[/url]

This details one of the larger issues as well as a potential means to allow restarting mysql on reboots. i don’t know if it will work all the time, but it’s best I’ve been able to come up with.

You all must remember. I’ve added support for GPT and MBR since the release of 1.0.0. 0.32 and below only allowed MBR style disks to be imaged. Many times, I’ve seen now, that FOG is actually trying to create non-existent image files because the disk is setup in a particular manner but the partition table doesn’t match up. Meaning it’s creating non-existent partition where there really shouldn’t be any partitions. Because of this, fog can’t find the partition or write to it so it skips that partition and continue’s on in the process. In the case of GPT when expecting MBR, the data never has a place to be written to so it just “complete’s” while no information has actually been written. Please verify this by running a debug task and checking your system against fixparts, or in the case you intend to maintain GPT tables, make sure the data is where it is expected to be.

Go Team Venture!

PartClone is uploading as it should now with svn2250. Thank you very much.

Now to convert my image library from PartImage to PartClone.