@Alf Usually the ACPI errors don’t actually cause a halt. See them as warning more than errors. Still you can ad noacpi in the host settings as Host Kernel Arguments.

In that one picture you have rcu ... errors after the ACPI warning. Those are really causing a problem/system halt! Other users report those on other systems as well and we are not sure how those can be fixed.

If I get you right you said you have used FOG 1.5.4 before and exactly those systems showing the problems did work fine with FOG 1.5.4, right?

@Redbob Can you please take a picture of the iPXE error (connection reset) on screen and post that here?

As well I’d ask you to get the boot menu listing again and post here - but this time use the MAC address of the client having this issue: http://172.24.3.71/fog/service/ipxe/boot.php?mac=aa:bb:cc:dd:ee:ff (instead of aa:bb:cc:dd:ee:ff put in the correct client MAC)

@davemccracken Please take pictures of the errors on screen and post those here.

@davemccracken How exactly did you schedule the debug task? This shouldn’t happen on PXE boot. In the “Unknown request type” picture we see that the kernel command line is missing parameter type=down that we see in the picture of your initial post. Please try this again. Go to schedule a deploy task as you normally would but just before you hit the button to create the task there is a checkbox to enable debug mode for this deployment.

Then boot up the Hyper-V machine you want to deploy to and when you get to the shell start the deployment with fog command. It should show pretty much the same output as posted in the first picture (if you haven’t changed anything) and when it errors out you just type in: sgdisk -gl /images/Win10-Gold/d1.mbr /dev/sda

My guess is we’ll see that the disk of the target machine is just a little too small…

@george1421 said in Problem laying image on a virtual machine:

Is there some way to build the minimum space needed from the metadata collected during image capture?

I am sure there is. Something like tail -1 d1.partitions | awk '{print $4+$6}' (or d1.minimum.partitions if that exists) would get the minimum sector count of the destination disk needed. And for sector count of the disk in question I’d run blockdev --getsz $disk

@george1421 said in rcu_sched stall OR kernel panic on PowerEdge R640:

I still have my kernel dev environment setup. What do we need to enable in the kernel for debugging?

First enable CONFIG_EARLY_PRINTK and CONFIG_EARLY_PRINTK_EFI in the kernel config and edit arch/x86/boot/compressed/eboot.c and search for the function called efi_main. Add print statements like efi_printk(sys_table, "Text output\n"); at various places in that function to find out where exactly it locks up.

Then when using the kernel the OP needs to add earlyprintk=efi (or earlyprintk=vga) to the kernel arguments.

@magikmw said in Trouble with DHCP after loading undionly.kpxe (xcp-ng):

I’ve dumped DHCP/TFTP traffic passing through the hypervisor,

That’s great and looks really interesting. First I noticed that packets seem to be partly duplicated in the PCAP. I see 18 DHCP Discover packets from your client within one second (0.85 s really) before the DHCP server sends an Offer. Very slow response in a network. Similar with the subsequent DHCP Request and DHCP ACK - 9 Requests (this time in a very short time) before ACK is sent. Looks really strange to me.

To make a long story short, I just noticed that on the first round (BIOS PXE boot) there are two Offer and two ACK packets, one of each VLAN tagged and one of each without. On the secount round (iPXE) I only see DHCP Offers with VLAN tag (ID 20 by the way). So to me it seems like the DHCP server behaves different depending on the DHCP Discover packet. Even more strange than the stuff before.

VLAN is the key I suppose! Can’t you terminate the VLAN on the switch or hypervisor?

@Wayne-Workman bump

@Wayne-Workman bump

@george1421 @Quazz @djgalloway Great work!!! Thanks to you all. I will add this in the next days!

@Trev-lchs Please open a new topic and post all your details: FOG version, exact error message (best a picture) and so on!

@merrittw First I may ask you to post the full install error log. The part you posted is just teh beginning.

@george1421 said:

If I remember correctly php-bcmath was removed in version 7.x.

I don’t think so - see here.

@loutrage said in IPXE Boot Problem - No such file or directory after installation of SSL:

I have my own CA deployed on my network.

Are you aware of the fact that the fog-client won’t work with your certificate? It’s not impossible to make it work but it’s not easy.

I saw this post https://forums.fogproject.org/topic/12908/ipxe-could-not-boot-no-such-file-or-directory and I tried the solution of @Sebastian-Roth but nothing change.

What exactly did you do and what was the outcome? You need to recompile the iPXE binaries to include your certificate to make this work. The buildipxe.sh script mentioned does this for you. After that you either need to rerun the installer (not sure if it’s wise in your situation with a highly customized setup) or manually copy the new binaries from /path/to/fogproject_git_repo/packages/tftp to /tftpboot.

@george1421 @robbit As for the commands to get the very latest develpment version (called dev-branch) you need to add one more command to what was posted below:

sudo -i
cd /root/fogproject/bin
git checkout dev-branch
./installfog.sh

Leaving that one command out doesn’t breach anything but you’ll end up with current master 1.5.7 again.

About the slow speed. Do you have Toshiba drives? https://forums.fogproject.org/topic/13620/very-slow-cloning-speed-on-specific-model

@loutrage said in IPXE Boot Problem - No such file or directory after installation of SSL:

We tried a lot of things and we have always the same problem.

This is not going to help any. Give us more details on what exactly you have tried and what happened. Otherwise we can’t help you properly.

Is there a way to see if our CA is correctly import in the binaries

Yes there is but it’s a bit of work:

cd /path/to/fogproject
mv src/ipxe/src/ipxescript src/ipxe/src/ipxescript.orig
mv src/ipxe/src-efi/ipxescript src/ipxe/src-efi/ipxescript.orig
echo -e '#!ipxe\nshell' > src/ipxe/src/ipxescript
echo -e '#!ipxe\nshell' > src/ipxe/src-efi/ipxescript
cd utils/FOGiPXE/
./buildipxe.sh
cd ../..
sudo cp packages/tftp/*.* /tftboot

Now when you boot a client it won’t go to the menu but drop to the iPXE shell.

iPXE> certstat
...

This should give you the certificate it has embedded in it’s store within the binary.

@TBuzaTechnician said:

sudo ./installfog -S -y
...

Who told you to use sudo ./installfog.sh?? Don’t use it this way!! Use

sudo -i
cd /path/to/fogproject/bin/
./installfog.sh ...

@TBuzaTechnician Ok, back to work, lets tackle this.

Compiling iPXE binaries that trust our SSL certificate......Failed!

Have you checked the install error log (fogproject/bin/error_logs/fog_error...) to see if there is any hint in there on why this fails?

In other words, I want to send an installation package to run on a remote machine, and not have to touch it. I will be remotely deploying images to the machine as well.

Can you give us more details on the tools you use for this? I am fairly sure this is a kind of new thing not many people have done before (except @Wayne-Workman) and it might be a bug in the installer preventing from it to work in your setup. The more we know about it the better we can help.

@Deimos said in Installation stops during setting up fogproject password:

But where can I add/replace this to the installation-script?

Take a look here: https://github.com/FOGProject/fogproject/blob/master/lib/common/functions.sh#L1261

You find that file in fogproject/lib/common/functions.sh on your system…

@martial There is a good description on how to find which hosts are causing this: https://forums.fogproject.org/topic/8448/response-error-multiple-hosts-returned-for-list-of-mac-addresses

@Quazz Thanks, done: https://github.com/FOGProject/fos/issues/31