Sending Discover - Loop & Unable to locate MBR
i was verry happy when i upgraded to the trunk & could link my NAS to fog.
But I discovered 2 new errors , and that is the reason i was scared to change upgrade to the trunk.
**First Error : **
I use my Virtual Machine in Xen to upload an image , but before that i need to do an quick registration.
When i’m doing the registration he is keeps looping : ’ Sending Discover…’. He don’t want to do the registration?! So i can’t upload or deploy images on that machine.
**Second Error : **
I uploaded with an PC in virtualbox an image (weird - this machine don’t have the Sending Discover message). I used ‘Multiple Partition Image - Single Disk’. I mean , you always got 1 partition from 100-500mb for that windows boot idk. & then the rest of the partition is just C:\µ
But when i use this image to deploy on an other Computer i get next mistake :
Image Store Corrupt : Unable to locate MBR (RestorePartitionTablesAndBootLoaders)
Args passed: /dev/sda 1 /images/QNAPTEST
Computer will reboot in 1 minute
How can i fix this 2 errors?
i tried it again and it was workign now.
@boeleke We have updated the files a couple of times lately. Please make sure you update and re-run the installer before testing…
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.
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).
This is solved ! :)
@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!
@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.
boeleke last edited by boeleke
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!
Yes, you can all call me dumb.
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…
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.
boeleke last edited by boeleke
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
Well I can say the FOS kernel is much smarter :relaxed: 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!
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!,
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?
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.
@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?
The version is 6549 - just upgraded from Git.
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?
@george1421 I also feel it needs to be added,
What version of FOG are you running? The exact version (shown in the cloud on the GUI.)