Possible to run headless?

Possible to run headless?

Has anyone succeeded in running AMT systems headless, with no monitor cable attached?

Noticed that when there is no monitor cable connected, I do not get any visual with the KVM-over-IP either.
Once I do connect the monitor cable the missing visual appears instantly.
I do can access the BIOS and GRUB with kvm-over-ip, so might be a (Debian) Linux only issue.
(it's not the standard screen blanker. pressing a key doesn't solve it)
publicaciones de 21 / 0 nuevos
Último envío
Para obtener más información sobre las optimizaciones del compilador, consulte el aviso sobre la optimización.

Problem seems to be limited to recent Linux distributions versions that use the Direct Redering Manager.

Created a bug report for the Intel driver in freedesktop's bugzilla.

I have Fedora 16 on one of my systems - I'll see if I can duplicate this later this afternoon.

Oh.. it looks like you already figured out what the issue was. This did work fine with no monitor on my Windows systems. Do you have this problem if your OS allows your monitor to shut off? ie, would setting it so that it would never shut down (the "non" monitor) allow the connection to take place?

I would think that if you enabled the user consent option, things might not work in a headless environment, as well so user consent would need to be disabled.

There is no power saving mode active (at least not one I can set. perhaps there is an automatic one if it thinks no monitor is attached), and yes user consent is disabled.

The only workaround I found so far is disabling graphic acceleration for the text console completey (kernel boot option"i915.modeset=0")
That's why I think the problem might be in that Intel driver, or in the related code that detects the capabilities of the monitor attached (EDID?)
Problem only occurs if the monitor cable is missing on boot. If it is connected at boot, but you disconnect it later, the visual will stay.

Very intersting. I have sent this question on to our engineering team to see if this is a known issue.

Hi Max,

I'm being asked to provide the following information:

Which tool are you using to open the KVM session?

Which version of AMT is on your system?

What are the exact steps you are trying to do? (when you remove the monitor? And when
its attached?)

Some of this may be scattered throughout this thread - let's get it all together in one place.

Which tool are you using to open the KVM session?

Our own custom software (it's the developer's forum after all :-) )
Which double checks that KVM and listener are up & running (usingCIM_KVMRedirectionSAP andAMT_RedirectionService), then connects to the redirection port16994, performs authentication using your digest authentication protocol, and then behaves as a normal VNC RFB 3.8 client.
Which version of AMT is on your system?

AMT 7.0
What are the exact steps you are trying to do? (when you remove the monitor? And when its attached?)
  • No monitor cable connected
  • Start system
  • Connect to AMT KVM console using our software: you can see BIOS boot process, grub boot loader boot progress. The grub boot loader messages telling it is loading kernel & ramdisk are the last you see. After that the screen goes either blank totally, or only the bootloader messages stay, like shown in the screencast.
  • If you close the AMT KVM console, and connect again to the console, you get a total blank screen.
  • Near the end of the screencast at 1:20 I get tired of waiting and do connect the monitor. As you can see visual appears instantly (along with a drm kernel warning message, you always get when you connect or disconnect a display)
  • No monitor cable connected
  • Start system
  • Connect to AMT KVM console using our software, add the i915.modeset=0 kernel boot parameter in grub.
  • As you can see with that parameter added display does works properly, and get the login prompt within seconds.

The exact AMT version turns out to be

(Never had much luck with the KVM viewer of the Manageability commander either.
Always gets stuck at "try connecting".)

Hi Max,

Sorry for the delays - we have the engineering team looking into this. The do think it is a bug in the Linux Driver (but they are still doing some tests.) Here is another question for you:

What happens when you boot passing the
"nomodeset" option to the Kernel? (you need to pass this option to
kernel in the boot loader)


What happens when you boot passing the
"nomodeset" option to the Kernel? (you need to pass this option to
kernel in the boot loader)

With "nomodeset" it works fine as well (looks the same as with i915.modeset=0)

Apologies for the delay - could you let us know some additional information?

1) Are you seeing the following error?: "Error: 0x80862000: Unsupported or inactive display
adapter" message after some time (about a minute).

2) Also - could you provide the register dump using
intel_reg_dumper (http://intellinuxgraphics.org/intel_reg_dumper.html)

This would help us understand whether we are seeing the
same problem on our platform.


Excellent - I have forwarded the bug report to our engineering team who is looking at this issue.


I know this is an old post, but is this fixed?  Is the only option to change the Kernel boot parameter?

I'm having the same issues as reported here, with slightly different config and setup:

I have Fuel OpenStack running with nodes.  When I connect to AMT Remote Desktop, I get a black screen, as soon as I connect a physical monitor, I can see the screen (both on the physical screen as well as on the vnc viewer).  As soon as I disconnect the physical cable I lose the vnc viewer screen as well.

The catches are:  I can't install the tools to run update-grub on the node, so changing the kernel boot is not an option for ubuntu.  The fuel server is running centos and the nodes are running ubuntu, I get the same results from either.

The viewer I'm using is the latest version of Real VNC Viewer.

Any help would be appriciated.


Hey John

The basic issue is that the system isn't detecting a connected monitor, so to save power the GPU is being powered down. My recommendation is to use a display emulator to trick the system into thinking there is a attached monitor

We just bought a couple of Dell Precision Tower 3620 and we cannot make AMT KVM (VNC) headless.

Without a monitor attached we didn't see anything (no bootup process, no bios, no operative system). All works good with a monitor attached.

BIOS is updated (1.3.4) and Intel AMT 11.0.0.

Connecting to http://host:16992/events.htm we got this event:

    System board    No video device detected.

Our configuration is:
User consent required: NONE
Default Visible monitor: Primary default (also Secondary tested)

The curious fact is that VNC is working and keyboard send keystrokes to the host, but the screen is just black.

I will write to Dell and I hope there is a workaround, but the conclusion is that not all AMT workstations can run headless out of the box.

Best Reply


The basic issue is that without something being plugged into a video port, the on board GPU gets shut down. Since the GPU is not displaying anything, all you get is a blank screen. You can use a display port or HDMI display emulator to resolve the issue you are seeing.




We bought some Intel vPro motherboard (ASROCK Q170M vPro) and we are facing the same issue.

No remote display if no physical display plugged into the motherboard.


Is there a way to 'not need' a display port emulator and have the onboard GPU always active even if not display attached ?

When no display and no emulator, is it still possible to power on / power off the machine remotely ? or all is stuck because no external display beeing connected ?




Hey Christophe,

Turning off the GPU when no monitor is attached is a power saving behavior controlled by the OEM BIOS. As I am not familiar with the ASRock boards, I would look in the BIOS for a setting. However I doubt it will be there.

As to other features of vPro, they are all available, so long as you are not doing KVM in conjuction with another operation.

<< Turning off the GPU when no monitor is attached is a power saving behavior controlled by the OEM BIOS.  >>


Note that KVM functionality does work in the BIOS, just not in Linux.


Issue is in the i915 Linux driver, and Intel seems unwilling to fix it.

To quote your co-worker Daniel Vetter (Intel OTC), in the formal bug report:



Daniel Vetter 2013-11-18 17:42:27 UTC
I'll wontfix this - it's kinda a feature request 
and we can work around it by forcing the connector state already. 
Doing proper kvm output detection needs a bit of code, but judging by the amount of noise 
in this bugzilla the demand isn't high.


Note that not many people complaining about this, does not mean there is no demand. It is more likely many of your customers just did not find the right place to complain...

Deje un comentario

Por favor inicie sesión para agregar un comentario. ¿No es socio? Únase ya