@dpotesta50 I wanted to add to Wayne’s very important questions that we also need to know what exactly you see before the screen you posted the picture of. It surely is a blue partclone screen and it has the actual error printed. You need to take a picture of that!

Five minutes sounds a bit fast for uploading a whole Windows 8.1 installation but what do I know, maybe you have 10G ethernet links and very fast disks as well. How long does it take to upload your Windows 7 image? How full are your disks when you boot up Windows7/8.1? Compare and see if it matches the upload times.

To check file sizes directly run ls -alhR /images in a terminal on the FOG server.

Hmmm, good point! If the files are there you can either open them using a console editor (vi, pico, nano) or tools like less, more and cat. But you can also check out those using the file command:

file /var/www/fog/service/ipxe/bzImage
/var/www/fog/service/ipxe/bzImage: Linux kernel x86 boot executable bzImage, version 4.2.3 (root@debian64) #1 SMP Mon Oct 12 11:56:21 EDT 2015, RO-rootFS, swap_dev 0x6, Normal VGA

I just ran into the same issue - yeah replicated! In /etc/php.ini there is no timezone defined. Lookes like this:

...
[Date]
; Defines the default timezone used by the date functions
; http://php.net/date.timezone
;date.timezone =
...

Changed it to date.timezone = Europe/Berlin (removed the leading ;) and systemctl restart httpd.service fixed this for me!

@zago123 Well, please tell us more about the computer model you have issues with. Exact model name, ethernet card (screenshot of the details from Windows device manager for example).

The picture you posted looks like you are booting those machines in legacy BIOS mode (using undionly.kpxe). Have you tried switching to UEFI (using ipxe.efi binary) yet?

/export/images/dev not /export/dev I reckon

@drc0nc The file sizes look pretty good to me! “mess of crazy characters” sounds correct too (binary data). I totally forgot that Tom added kernel debug and loglevel into the web interface already. So you can go to FOG Configuration -> FOG Settings -> FOG Boot Settings to enable FOG_KERNEL_DEBUG and crank up the FOG_KERNEL_LOGLEVEL to 7! Hope we will see any messages then!! Keeping my fingers crossed.

I thought about maybe the kernel and initrd binaries not getting downloaded properly while the client boots up. But in the picture you posted some time ago it shows that both seam to load fine (AFAIK ok means loaded fine and verified on the client):

/bzImage... ok
/init.xz... ok

Edit: The first message I see when enabling the DEBUG/LOGLEVEL settings is early console in setup code.

See here: https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_FTP

@unknownhost99 Could be as Wayne said, a rogue DHCP server or could be a dozen other things. There is no reason to hide internal network IPs. More often than not we see things on the screen that you don’t see. So you might post a full picture and tell us which IPs your DHCP server and which your FOG server has.

By the way, what is serving DHCP in your network? Has your setup ever worked or is it a fresh install? Which version of FOG?

Beside that you can take a look at the files in the TFTP directory on your FOG server to see if they do exist: ls -al /tftpboot

As well see if the TFTP server is running on your FOG server: netstat -antup | grep 69

Post the output of both commands here.

filename in /etc/dhcp/dhcpd.conf seams ok. But what does next-server look like? Is the DHCP server running (service isc-dhcp-server status)?

Try this troubleshooting guide: https://wiki.fogproject.org/wiki/index.php/Troubleshoot_TFTP

@drc0nc No, errors won’t be in any log file AFAIK. Only on screen.

Have you tried other iPXE binaries? There are different ones coming with FOG. Change your DHCP settings to point to undionly.kkpxe (double ‘k’) or ipxe.pxe/kpxe/kkpxe and see if it makes any difference.

Or should we try booting iPXE via CD/USB and load the kernel from there? I remember that some time ago it was impossible to boot iPXE over network on Mac OS X clients. Everyone just booted those via CD/USB. Has been fixed now for a while but maybe your HP books are also causing some kind of weird issue when booting iPXE over network. It’s pretty late here and I can’t go into the details of compiling iPXE just now. But you can try generating a USB/ISO file yourself online: https://rom-o-matic.eu/

Select Advanced, USB or ISO, NIC type: undionly, PXE_STACK, IMAGE_BZIMAGE, CONSOLE_FRAMEBUFFER and the following three lines as embedded script:

#!ipxe
dhcp
shell

When you get to the iPXE shell you can issue different commands. For example loading kernel/initrd to boot (untested - so might have minor typos in it):

kernel bzImage loglevel=7 debug initrd=init.xz root=/dev/ram0 rw ramdisk_size=127000
imgfetch init.xz
boot

If updating and re-running the installed does not work for you then we need more information! When you load the page and get the 500 HTTP error see what you have in the apache error log /var/log/apache2/error.log (Debian/Ubuntu) or /var/log/httpd/error_log (RHEL/CentOS/Fedora)…

@Shiigehiro Probably confirmation was done already?! As you can post here things seem fine I reckon.

This command might help you finding out what kernels you have:

$ file /var/www/fog/service/ipxe/bzImage*
/var/www/fog/service/ipxe/bzImage:   Linux kernel x86 boot executable bzImage, version 3.15.6 (root@debian64) #1 SMP PREEMPT Fri Jul 18 23:58:44 EDT 2, RO-rootFS, swap_dev 0x5, Normal VGA
/var/www/fog/service/ipxe/bzImage32: Linux kernel x86 boot executable bzImage, version 3.15.6 (root@debian64) #1 SMP PREEMPT Fri Jul 18 23:58:56 EDT 2, RO-rootFS, swap_dev 0x5, Normal VGA

This output is on a 1.2.0 test install on my laptop. So I guess 1.2.0 came with 3.15.6

Sounds a bit like you have two DHCP servers answering clients’ discovery requests in your network. Sometimes they pick up IP and PXE information from FOG and sometimes they pick up whatever the other DHCP server provides (probably only IP without PXE info)??? Just a wild guess…

@tian Can you please update to the very latest version (plus run the installer) and see if things are fixed? Tom just uploaded the new inits…

@Steve-Owen I’d think this forum post should be of much help to you as it explains how to convert/extract files from FOG backups. After you extracted the whole image (big file!) you need to convert that raw image to vmdk which can be done using qemu-img or VBoxManage tools: https://stackoverflow.com/questions/454899/how-to-convert-flat-raw-disk-image-to-vmdk-for-virtualbox-or-vmplayer

Be aware that you need a lot of disk space for the conversion steps. I wonder if it more appropriate to deploy the FOG image to a VM and using that VMDK.

Tom Elliott said:

The issue is VirtualBox. It will only work on the initial load up of the System from a “cold” status. If you only restart the system, you will get this message because the VB resources aren’t releasing the NIC properly.

I’ve tried it and it works like a charm without any problem! FOG 1.2.0 and trunk, Virtualbox 5.0.0 in Windows 7, bridged network with any of the available network adapters (PCnet, Intel, virtio-net …), cold start as well as warm start! I just cannot find a way to reproduce.

My guess is that this issue got fixed within virtualbox at some point. Please check your version and maybe install a newer one. In case this is still not working for you I need to know your virtualbox version and network settings.

Let me guess… It hangs on “Initialising devices…”?!? Please take a picture or video as Wayne suggested so we are able to see the same things you see. Otherwise helping is somewhat more complicated if we don’t see what’s going on.

@raftor The files don’t seam obviously damaged but from the error you see I am pretty sure they are. How did you transfer the files?

Please compare the file size (ls -al /images/laprimera see the numerical value e.g. 8561167 for d1p1.img) on both the old & new server and if those match exactly compare the MD5 sums as well (md5sum /images/laprimera/*)!