Sending Discover - Loop & Unable to locate MBR
-
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…
-
