Can only deploy if device connected to HDMI



  • FOG version: 1.4.4
    SVN Revision: 6077

    Hi there.

    I have managed to get a working FOG setup where I connect the FOG server and any hosts I want to deploy to a switch. From this point, I simply power on the hosts and they talk to the FOG server, get an IP from isc-dhcp running on the FOG server, register themselves and get an OS installed. All of this is working fine.

    After I managed to get this all working, I decided to try 4 hosts at the same time. I had two connected with HDMI and 2 without. I was watching the process unfold on the screen for the two devices which were connected via HDMI. Both these devices managed to boot with PXE, register and deploy the OS. I also have a little green LED light up on the device when the OS boots up the first time it is run. Both these two devices had a green LED to indicate they finished.

    The two devices which were not connected to HDMI did not manage to register nor get the OS. I plugged in their power again to try again but saw the same result. I then plugged in HDMI to one of them and it managed to get to the registration screen. I powered it off/on again without HDMI and it failed again. I then powered it off/on with HDMI connected again and it got to the registration screen again so I let it register and get the OS etc.

    I now have 1 device left which will manage to get to the registration screen ONLY if HDMI is connected. If HDMI is not connected, it seems to be stuck in a reboot cycle where it keeps trying to boot to PXE and failing. I can tell this by looking at the Ethernet lights. Unfortunately, I cannot plug a screen in to see how it is failing because when it has a screen plugged in, it works. Note the particular devices I am using need to have HDMI plugged in before they are powered on.

    Does anyone know why my devices cannot PXE boot without an HDMI cable plugged into it? Is there some log file within FOG I can view to see what the problem may be?

    Regards


  • Developer

    Maybe buy something like an active HDMI Switch just to make it happy (e.g. I found Vention HDMI Splitter Switch 5 input 1 output HDMI Switcher for $15). Also the specs of the board show a DSI/eDP interface. Maybe there is some kind of cheap adapter/or mini-TFT you could hook up to that.

    But let’s see what you find out with tcpdump and take it from there.

    Edit: Ahh, google is your friend again… (possibly related, but maybe not)
    https://github.com/raspberrypi/firmware/issues/211
    https://www.raspberrypi.org/forums/viewtopic.php?t=11259
    https://communities.intel.com/thread/76913


  • Developer

    @george1421 said in Can only deploy if device connected to HDMI:

    The only other variable here is actual firmware value settings. Understand I’m only thinking about the fact that you have identical devices but they are behaving differently.

    From what I read those devices don’t behave differently at all. Each doing the same weird thing when being without a connected HDMI display. So the difference described is not between machines but only between them if either a display is connected or otherwise if it’s not. Did I get that right?

    I remember those days when BIOS still complained about not being able to boot when there is no keyboard connected. @roarcore Do you have everything disconnected when this is happening or is it just the display?


  • Moderator

    @roarcore said in Can only deploy if device connected to HDMI:

    all these devices are exactly the same hardware wise and they all have the same firmware.

    The only other variable here is actual firmware value settings. Understand I’m only thinking about the fact that you have identical devices but they are behaving differently.



  • Thanks for the quick responses!

    Before I follow the tutorial George gave me, I will provide you with a few more details. The devices are called UP Boards: http://www.up-board.org/up/specifications/

    These are 64 bit Intel Atom devices which support UEFI. Their BIOS is American Megatrends Aptio Version 2.17. Before I do the PXE process, I flash the BIOS of all devices to ensure they are all running the same version. Unfortunately, they only have a HDMI port for display.

    I am not ruling out a problem with my BIOS firmware provider; I believe it could be a problem with some sort of check for PXE booting where it checks for Ethernet media and some sort of display.

    Just to be crystal clear on the situation: all these devices are exactly the same hardware wise and they all have the same firmware. They are all able to PXE boot but only if HDMI is connected.

    I will get back to you guys with tcpdump/wireshark.


  • Developer

    @roarcore Well, this is a new one! Haven’t heard of this before.

    Adding to what George already said, pay attention to the LED on the network card on the back of the machine. Does it come on? Does it blink (usually means traffic on the NIC)?

    Can you try the same but using a different display connector, good old VGA or DVI or DisplayPort… same thing happening?


  • Moderator

    @roarcore Are these some kind of normal office computer or is this an industrial or embedded device?
    If they are not pxe booting into the FOG menu then I can say it would be hard to get any kind of log. My initial reaction is this is a hardware issue with the device.

    As a test, it would be interesting to know; if you pxe boot the device, does isc-dhcp show it assigns an IP address to the device? That would tell you if the device was even trying to get onto the network. The other thought to see if it was even trying to come online would be to follow this tutorial: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue And then look at the pcap with wireshark. The dhcp cycle is discover, offer, request, ack. See if the client even sends out a discover packet. If you have no discover packet then the computer is hanging before it tries to boot.

    Also since you have some that work and others that don’t. Are they the same model? If so, then do they have the same version of firmware (hint: the newest firmware doesn’t always mean the best)


Log in to reply
 

428
Online

39.3k
Users

11.0k
Topics

104.4k
Posts

Looks like your connection to FOG Project was lost, please wait while we try to reconnect.