Posts made by mxc

@Sebastian-Roth Ok here is a video of the original machine that was imaged showing when it tries to boot from pxe. I have been unable to get the video from a machine that has had this image deployed to it as they are busy being used in training at the moment but the video below is pretty much what happens to them as well. Its odd because the pxe boot that is used to copy the image to the server works without problems.

https://drive.google.com/open?id=1Jd41t2JMfF-fT-_s9gu9x3Pz7kPnwaPV

This is what it looks like if the hard disk is the first boot device. On the machines that have had the image deployed, they just end up pxe booting. Will try and see about adding a uefi entry once the training is over.

https://drive.google.com/file/d/1-raEQt-t6j5ziMqJV7s-M1LCbQk6JAeD/view?usp=sharing

Sorry had to use links due to file size limit. I might be the boot option as you suggested so will play around with that when we get the time and check the uefi entry.

thanks @Sebastian-Roth will do a video capture and test the machines tomorrow. I will try changing the exit options to test the result too. I did change those setting from the default so maybe that is the issue. Although when the image was deployed to a different type of hardware device it didn’t give any issues. UEFI definitely sounds like it could be an issue in this scenario.

Hi all,

We have some oldish Jetway Mini-Top 700 that support uefi, if its relevant. We imaged one of these devices installed with Ubuntu 18.04. Upon reboot of the machine that was imaged, PXE boot is first tried, and instead of successfully booting from the hard disk we get the following:

launching grub
begin pxe scan
start cmain()

And the device hangs. We can turn off pxe boot in the bios and the device that was imaged can then boot without issue. However any machine who has the image of this device deployed hangs at the grub prompt even if we turn pxe boot off in the bios. It seems to completely ignore the bios setting.

We tried reinstall grub off a live ubs on the deloyed machines figuring it was easier than trying to reinstall them but no matter what we tried the grub prompt hangs. It looks like the devices are still getting hte pxe image from fog and trying to boo the hard disk but failing. As stated they shouldn’t even try network boot as we turned it off in the bios. Very odd.

Any ideas?

I know this is going to sound weird but the Linux KVM image started failing to find the tftp server as well. Once I set up tcpdump to investigate on the fog server it all started working.

I tried the same with the windows image and now its working too. Only straw I can cluck at here is latency of some kind in the vm network layer. Maybe by delaying the boot up it gave the dhcp server time to respond?

Will see what I experience going forward and try and build up a conceptual model of what is going on so I can test and verify.

Hi @Sebastian-Roth

That fixed it Thanks for your and Tom’s assistance.

Hi @Tom-Elliott

Sorry, I mentioned it on the other post. I should have put it here too. It was version 6557 but I have since upgraded to fix the white screen of death bug. I am not at the office now so can’t get the exact version but it was less than 3 hours ago that I did a git pull.

regards

Hi @Tom-Elliott

Just to let you know I tried to upload a non-resizable image and it too failed after the upload on the “Update database” step as well. I couldn’t see anything in the mysql log files.

Maybe one of my tables is corrupted?

cheers

Hi @Sebastian-Roth,

I think I was wrong in my understanding that the Ubuntu instance times out. I have been trying so many things while also doing a full days work I get a bit lost

Will do the wireshark dump tomorrow.

kind regards

Hi @george1421

The F12 is the option that SEABIOS uses to allow one to interrupt the boot process to choose which device to boot. It can be configured to boot straight into PXE mode if desired.

I think I may have been mistaken on the need to push F8. The F8 settings come from my dnsmasq configuration file. I am not sure if its needed but it was added a year ago to get things working so its just been left there.

So in short the Ubuntu PXE boot in the vm works fine.

The windows vm is on the same infrastructure. It appears never to download anything from the tftp server. I will run a tcpdump on the tftp server tomorrow and see what gives.

Thanks for the help.

@Tom-Elliott I didn’t have my cell phone with me but the upload fails on the reboot when it i says it is resetting the partition sizes. It fails saying

“Updating data - Failed” or something like that. Basically it looks like it fails trying to update the db after a successful upload and resize?

Will bring my phone tomorrow.

@Tom-Elliott Done - looks like its working now

Hi all,

The version on the fog front-end says: 6557. A correction to my report. The white screen of death happens when I attempt to create an upload event on a new image. The error from apache’s error log is>

[Mon Mar 07 13:38:57.813384 2016] [:error] [pid 3431] [client 192.168.19.229:38518] PHP Fatal error:  Call to a member function isValid() on null in /var/www/html/fog/lib/fog/host.class.php on line 547, referer: http://192.168.19.2/fog/management/index.php?node=host&sub=deploy&sub=deploy&type=2&id=8

Thanks

Will do so tomorrow. Thanks for the reply.

Hi @Sebastian-Roth,

Thanks for the reply. I will be able to test again tomorrow. Where can I get log files for the failed uploads and downloads to get more data? I can watch the screen but its usually too fast to get the exact error message.

The one thought I had was that if it is going to resize the partitions and then extend the file system it will probably only be able to extend the last partition to take up the full space available? If so I will try with an image where the last partition is the root partition and put the swap etc in the front of the drive.

regards

Hi all,

We have an image with an extended and some logical partitions. This image can deploy on some machines ok but on another, even with the same specs, it would not. This was with Fog 1.2. The error that would flash by was something along the line of “Invalid logical partition number”.

To try and fix this we upgraded to FOG 1.3 from Git. The installation now fails with a different error about the logical partition but this time mention partclone as the utility that failed.

From what we can gather this may have something to do with GPT/MBR drives. The image is MBR but the drives were previously partitions with GPT, although this step in the process seems to go fine according to the console messages. (Again the message disappear to quickly for us to note them down accurately and we are unaware of how to find the log related to them.).

In the end we overcame the problem by creating a new image and using physical partitions only. It would be good to know where to begin to start unraveling this problem. i.e its is generally hard to troubleshoot problems with fog. Is there some check list somewhere?

thanks

Hi all,

We have some VMS which we use to image for a bunch of machines in our training room. We updates those and refresh the master image on FOG from them. There are some differences in how the PXE boot works with the VMs compared to the physical machines:

1. For an Ubuntu VM we have to intervene and press F8 to get pxe boot to happen. If not the pxe boot times out and the vms boots. On our physical machines doing nothing will cause the PXE environment to boot without issue.

2. We have one Windows XP machine which is used for the trainers machines as there is one course which requires PDF slides that need one to authenticate to a secure server ever time they are displayed (I know its really stupid but its not up to us.) Unfortunately this features doesn’t work in the PDF viewers on Linux so we use the Windows XP vm to display the slides. This VM won’t boot to PXE no matter what. The PXE boot process starts but it always fails to find anything and ends up booting the VM.

Any ideas why there are these different behavious? I should imagine that once the bios start booting PXE there shouldn’t be any difference in the process of locating the pxe image file, downloading it and booting to the fog menu as this all happens before the OS boots up?

Thanks

Hi there,

We have a training lab with a range of generic machines which we want to image via FOG. The machines all run Ubuntu Linux. When creating an new image we can;t get the “Single Disk (Resizable)” option to work. It just fails to upload. What does the "Single Disk (resizable) mean? I am assuming a single disk with multiple partitions - i.e. an already installed “master”.

What are the requirements that make a single disk resizable? We create the image in a VM with a 20GB disk and would like the partitions to expand to fill up the entire disk on the lab machines if possible.

thanks

Hi all,

I upgraded our fog server to 1.3 using git (just in case anyone finds this after 1.3 is released). I did the db upgrade and all appears fine. I just had to update the admin user password on ftp/tftp etc but after that all seemed fine.

When I try and create a new image I just get a white screen of death when I click save. I can successfully update an existing image that existed from before the upgrade but cannot seem to create a new image.

Any ideas?