Sending Discover - Loop & Unable to locate MBR
-
@Tom-Elliott
The version is 6549 - just upgraded from Git.@george1421
This virtual vm is hosted on a server xenServer with 4 network interfaces. But only eth0 can be used for fog & other things. Normal FOG isn’t doing this.What do you guys think what can be a solution?
-
@boeleke Unless I’m missing something really obvious, why does this VM Client have more than 1 ethernet adapter defined?
The screen shot from above appears to be the FOS (Fog OS) booting and it is getting stuck setting up the eth1. Why does this vm have eth1?
-
Fog booting? This is a Windows Client booting over the Network. And I choose for Quick registration . So he is doing the registration , that i can find him in FOG gui.
-
OK I think we have a language disconnect here. No problem lets just reset a bit.
From what I understand you have a virtual host machine running on Xen, correct?
Also you are trying to boot that Xen virtual (client) machine via PXE so you can register that in fog, correct?
As you are trying to boot it (the Fog client OS ie the thing that clones and restores the target computer) for registration it is getting stop at sending discover… for eth1. I can see that from your OP.
My question is why is there two network interfaces in the virtual client you are trying to register with FOG?
-
Hi there George!
Sorry for my bad english haha
The FogServer AND the virtual Windows 10 are running on Xen.
I try to run the virtual windows 10 via PXE to register it.Yesterday my Fogserver was not updated yet to ‘Fog Trunk’ & it worked.
But after the update, i can’t register this windows 10 Xen-Client anymore.About the second interface.
I got 4 network-interfaces on my server and when you make an Windows VM , he will add this 4 network - interfaces automatically. (See pictures)
Is this giving a problem? Why isn’t it giving a problem in ‘normal fog’?
Do you guys have already a solution for the MBR-error?
Greetings & Thanks!,
Tom
-
Well I can say the FOS kernel is much smarter
than the older kernel. If it sees it, it will try to enable it. I assume on these other interfaces there is no dhcp server that is where it is getting hung up. Is there any way to only connect the wanted interface to this VM, or at least down the links? I do have to say I’ve only used VMWare so these magical ghost network adapters had me a bit stumped.As for your mbr issue. I have no experience with using a nas as a storage array. But I might look into the images folder on the nas and give us the output of
ls -lafrom that image folder on the nas. It sounds like your upload wasn’t complete. -
Hi there George,
so you guys made the kernel too smart? Haha!
I deactivated the interfaces in windows & it keeps failing. Maybe that the interfaces keeps enabled while booting. Then i removed the interfaces in Xen & it worked now. Maybe you guys need to try to solve this , that u don’t stuck & can’t do anything?
So i guess this is solved , but a bit weird. We got a couple of computers with 2 NetworkInterfaces so it can be anoying :)!Here is a picture for second error :
Where you see ls -la from /FogTrunk --> Map with the images
and ls -la from /QNAPTEST --> ImageMap
-
The smart kernel is only an issue if there is no dhcp server on each network interface that is reporting up.
As for the second error. It looks like you have not enough files in that folder. If this is a mbr system you should have something like d1.mbr. So I can understand the error. In general I think you have a bad capture there. You might want to check to see if that mbr file got left behind in the ./dev folder.
-
There is definitely d1.mbr missing. Tom has fixed the inits lately. Can you please upgrade to the very latest trunk version and upload the image again? Then try deploying it…
-
Yes, you can all call me dumb.
-
Is that version 6551 ?
if yes , then i just upgraded it.I can’t test it till monday if this is working so…
I’ll let you guys know something monday!Ow ps . : maybe some stupid question , but what happens if you upload an image (name : test) & 2 weeks later you upload a new image to ‘test’. Is this going to give some problems?
Thanks for the help!
-
@boeleke Uploading over images is perfectly fine and done quite often.
It should work fine either way, although it does mean the original test will no longer be recoverable.
-
https://www.youtube.com/watch?v=-nEe2MOZgg4
@boeleke About the network issue on boot up: It seams like the virtual network adapters within your VM seam to be detected as connected although the physical NIC is not connected. I don’t really know what we can do about it from our side. I recommend you to disconnect those virtual network interfaces from the VM as you don’t really need those. From what I can see here it should be possible to remove/disconnect virtual network interfaces from a VM. As well there is a video on youtube on how to add/connect a virtual adapter. I am sure this is possible! -
This is solved !
-
Actually your issue has brought up and important point that the developers talked about over the weekend. In that there may be computers where there may be multiple ethernet adapters but only one valid ethernet adapter for deployment. In your case only one ethernet adapter will receive a dhcp address, but at the time of registration the preferred ethernet adapter isn’t known. I can think of a few use cases where this might be the case in the wild. The first one that comes to mind is where you would have a laboratory PC with two network adapters, one connected to the business LAN and the other connected to an instrument network or just an instrument through a cross over cable. In this case the instrument network may not have a dhcp server.
With all of that said, the developers took this information and came up with a potential solution to this issue. Could you do something to test this for them? Update your fog server to the latest trunk release and then setup your original condition where you have 4 network adapters but only one connected to the subnet where your fog server lives. Once that is setup could you try to boot and register this vm client? If everything goes well you should be able to register this device now. The patch will test each interface to see if it returns an IP address. The first interface that returns an IP address wins here. If you have multiple interfaces that each return an IP address, the first interface will be used. To bypass this behavior you will have to manually register this device setting the preferred mac address the FOS client needs to use for imaging. (I do have to say its a sweet bit of coding they did to correct this issue).
-
Hi there George1421,
good to know that u guys worked on it.
Today i’m deploying / uploading images. I’ll try to test it this week.
When i tested it , i’ll give u a sign over here.Greetings
Tom -
@boeleke We have updated the files a couple of times lately. Please make sure you update and re-run the installer before testing…
-
