using deploy image via pxe with more than two nics

[JJ Fullmer]

@mosi So you’re saying that
You boot an unregistered host to pxe
You select deploy image
It does nothing and jumps back to the menu.

You then disable the second nic in the bios, it then does work.

Does it work if you register the multi-nic host and then deploy to it? You can just delete the registration later if desired. If you don’t install the fog client on the server, having it registered there will just make it accessible for future imaging.

[mosi]

@JJ-Fullmer
yes you got it.

yes it works, when I register the host. (tried using full host registration)

[JJ Fullmer]

@mosi But you have a use case where you want to be able to image a server machine without ever registering it in fog, yes? Is it not working on a multi-nic device new fog version 1.5.10 or is this the first time you’ve tried it on a multi-nic device?

[mosi]

@JJ-Fullmer
yes thats the use case. Because we want to deploy the image just once and then give the server to our customers. There is no need for additional configuration or management done using fog.

The fog version is the latest stable release 1.5.10.

And yes I’ve tried it on a system with one nic. Two nics
and three nics. With two nics the image deployment is working fine.
As soon as there is a third nic the deployment-process wont start and switches to the console (screenshot)

[george1421]

@mosi So it pxe boots OK with 3 nics, its just FOS Linux that is getting confused.

If you change which nic port is connected to the network, does that change the results? I’m not talking about disabling the network adapter only changing which one is getting an IP address.

With the default configuration where you get that hardware testing menu, if you manually register the computer with FOG, then schedule a deploy task, but before you hit the schedule task, tick the debug checkbox. Then pxe boot the target computer. Can you get into debug mode that way? The idea is to get console access to the target computer under FOS Linux. Then we can start debugging.

Your method of deployment is typical for an MSP or system rebuilder. FOG does support this mode of “Load and Go”.

[george1421]

@mosi For you to get the system info page something has to be going wrong in the master fog script.

specifically around this line https://github.com/FOGProject/fos/blob/e3e7e93cc249a92b512862f308481f1ee055740d/Buildroot/board/FOG/FOS/rootfs_overlay/bin/fog#L63 mode needs to be quickimage for “image deploy”, but just below quickimage is sysinfo (the screen you see). If the only change you do is enable a nic or not, we need to understand how this impacts the script. In general it shouldn’t but we need to understand why.

[mosi]

@george1421

Yes I can enter the debug mode with the manually registered host and can access the fog server from there.

One thing i forgot to mention before is, that when I try to use deploy Image with the 3 nic setup, the boot screen asks me to enter the password more than once before I get into the sysinfo screen.

I’ve recorded the screen while trying to use the deploy Image task on a 3-nic system.

https://simstation-my.sharepoint.com/:i:/p/m_mosinz/ETT2beum2k1LhypzAhEEb3kBVPxCAw341gmb2dpzlzdrYw?e=slvhDD

Hope this helps.

[george1421]

@mosi If you can get into debug mode then lets check some things out.

With a manually registered computer can you deploy the image to the target computer? The same image as you would use in deploy image? Does it work? You don’t need to deploy the entire image, I’m only interested if partclone starts.

Now enter into debug command line mode by deploying the same image that is failing with deploy image. At the fos linux command prompt key in ip a s and collect the IP address of the target computer. (Post the output of ip a s here too). Now give root a password with passwd keep it something simple since it will be reset on next reboot anyway. Now key in fog and press enter. Keep pressing enter until you see the “Running post init scripts done” message. Now press ctrl-c. This will drop you back to the fos linux command prompt. Finally key in the following set > /tmp/variables.txt

Now use winscp or scp command to copy out that /tmp/variables.txt command using the ip address you collected and root and password you set above. The variables will post what FOG is telling FOS Linux to do with the backup job.

[mosi]

@george1421

parteclone starts without any problems and is able to deploy the image when I run the fog command from the debug-shell.

ip.txt

variables.txt

[george1421]

@mosi Ok so now the question is why does it deploy correctly using scheduled deploy vs quick image (old name for deploy image in ipxe)? I’m going to have to think a bit on this one.

[mosi]

@george1421
I’ve figured out, that it does not change on different hardware (tried two different servers) and also tried it on a VM with three configured nic’s.

[JJ Fullmer]

@mosi Are you saying you recreated the problem on a VM with 3 nics or the problem doesn’t happen in that case?
Also, are all nics connected to the network? Are they in a nic team/bond/aggregate link? Connected to different subnets? only 1 connected?

EDIT: I tested this in a VM and recreated the problem. It didn’t matter if 1 or all adapters were connected, if 3+ exist on an unregistered host it behaves as @mosi describes.

UPDATE: I also tried some previous bzImage and init versions, all the same behavior.

[Sebastian Roth]

@george1421 said in using deploy image via pxe with more than two nics:

specifically around this line https://github.com/FOGProject/fos/blob/e3e7e93cc249a92b512862f308481f1ee055740d/Buildroot/board/FOG/FOS/rootfs_overlay/bin/fog#L63 mode needs to be quickimage for “image deploy”

I guess you found a old bug thas has been in the code for a very long time. There really is no script called fog.quickimage in the FOS inits. Should be in /bin/ but there is non. So to me it seems like when the quickimage case is called it’s just ignored and fog.sysinfo is called.

The name was even updated in the schema at some point: https://github.com/FOGProject/fogproject/blob/65fe719e58f89398a1e3f45412d7305993eb282e/packages/web/commons/schema.php#L3315

@JJ-Fullmer said:

I tested this in a VM and recreated the problem. It didn’t matter if 1 or all adapters were connected, if 3+ exist on an unregistered host it behaves as @mosi describes.

What kind of virtualization do you use? I was not able to reproduce this on virtualbox yet. Seems like I am doing something wrong because when I get to an iPXE shell and let ifstat list the network interfaces I only see net0.

EDIT: Ok, got me. When using the default iPXE binary undionly.kkpxe this is not happening because it seems to only detect one network interface. Switching to ipxe.pxe brings up the same issue for me. What I noticed is that when you are asked to enter username and passwort to authenticate before the image deploy you submit with ENTER but get back to the same password dialog again with the information entered already. So hitting ENTER once again finally gets you past the authentication screen?!?!

EDIT2: Same problem when trying to join a multicast session on a VM with three NICs. Two NICs does not cause the trouble for deploy or multicast. Moving this to bug reports.

[JJ Fullmer]

@Sebastian-Roth I realizing it doesn’t matter as much now since you got it recreated, but I am using vmware workstation and I am using the ipxe.efi boot file.

[Sebastian Roth]

@mosi This issue is fixed in the latest dev-branch version. Please update.