1

After upgrading to "jessie" (debian 8) from stable (debian 7), the system hangs at a blank screen (displaying only an underscore at the top left corner), but otherwise displays no error message to support a diagnosis. The problem seems to be a failure to load X, and the following warnings are contained in /var/log/Xorg.0.log:

[     8.810] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[     8.834] (WW) Falling back to old probe method for vesa
[     8.834] (WW) Falling back to old probe method for fbdev
[445797.803] (WW) Open ACPI failed (/var/run/acpid.socket) (Connection refused)
[445800.781] (WW) Open ACPI failed (/var/run/acpid.socket) (Connection refused)
[526625.329] (WW) Open ACPI failed (/var/run/acpid.socket) (Connection refused)
[527190.989] (WW) Open ACPI failed (/var/run/acpid.socket) (Connection refused)

I have tried investigating the error messages relating to vesa, fbdev, and Open ACPI, but haven't found anything particularly helpful. The lack of cyrillic font does not seem very important and ACPI relates to power settings, so I suspect a solution might involve fixing the vesa and fbdev errors. I'm wondering if these messages mean something to anyone, and if so, if a remedy might be suggested.

Edit 1:

Some system information that may be pertinent:

lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09)

uname -a
Linux 3.2.0-4-amd64 #1 SMP Debian 3.2.60-1+deb7u3 x86_64 GNU/Linux

Edit 2:

I was checking an outdated log file (Xorg.0.log). Searching for errors and warnings in the most recently updated log file (Xorg.1.log) reveals the following:

[   232.705] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[   232.717] (WW) Falling back to old probe method for modesetting
[   232.717] (WW) Falling back to old probe method for fbdev
[   232.718] (WW) Falling back to old probe method for vesa

closed as unclear what you're asking by Braiam, jasonwryan, maxschlepzig, Faheem Mitha, cuonglm Aug 14 '14 at 8:10

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • which graphic card do you have? – pqnet Aug 13 '14 at 22:18
  • The timestamps look strange. Have you rebooted? – vinc17 Aug 13 '14 at 22:22
  • @pqnet: Sorry to not have added enough pertinent information. I have updated the question accordingly. I notice that uname -a shows deb7u3, whereas "jessie" (debian testing) is deb8. Perhaps the upgrade did not go to completion? – user001 Aug 13 '14 at 22:24
  • 1
    Try switching to another VT after booting (e.g. Ctrl+Alt+F2), logging in and running startx 2>&1 > startx.log and see what turns up in startx.log. – arnefm Aug 13 '14 at 22:28
  • 3
    445797.803 means several days after reboot. So, I don't understand how this is possible. Are you sure that the Xorg.0.log file is the right one? – vinc17 Aug 13 '14 at 22:29
1

From your information, it seems that everything is fine: no errors. But the X display may be on tty8 instead of tty7. So, switch to tty8 with Ctrl-Alt-F8.

EDIT: This is a known problem: https://bugs.freedesktop.org/show_bug.cgi?id=29920

Example of bug where the screen is black while startx works (this may be related or give some ideas): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744152

  • Thanks. I find that tty1 is command-line only; tty2 is graphical (it's what displays X after running startx via tty1); tty3--tty6 all display a login prompt; tty7 displays a static underscore in the top left corner (which is the same thing I observe when the system hangs on boot); and tty8 displays a blinking underscore in the same position. – user001 Aug 13 '14 at 22:48
  • 1
    @user001 I suppose that Xorg.1.log corresponds to the server started with startx. I suspect a bug (or misconfiguration) of your display manager. For instance, your display manager may crash before it starts a X server, as startx shows that there are no problems with X. – vinc17 Aug 13 '14 at 22:53
  • Thanks, I'm looking over the bug report you sent now and trying to see if I can figure out why the display manager is not running on boot. – user001 Aug 13 '14 at 22:54
  • 1
    @user001 Concerning your bootlogd problem, it could be the following bug: bugs.debian.org/cgi-bin/bugreport.cgi?bug=716948 – vinc17 Aug 14 '14 at 0:04
  • 1
    @user001 YOu are not required to accept an answer if it doesn't fix your problem. – Faheem Mitha Aug 14 '14 at 7:55
2

This sounds like your acpid daemon isn't running, for some unknown reason. You can confirm this if you're able to get shell access to the system like so:

$ pgrep -l acpi

You should get some response back. If you do you can double check how acpid is being invoked with this command:

$ ps -eaf | grep acpi

If it isn't running you might want to try forcing it during your system's boot by appending the following to your GRUB line for the kernel. You can do this during the initial boot by appending this:

$ apci=force

These options are discussed further in this article titled: BootOptions from the Ubuntu community wiki.

  • Thanks @slm. Seems I was checking the wrong Xorg log file, and the correct log file actually does not contain any acpi warnings (see "Edit 2") in the question. I did try what you suggested and found ktpacpid and ktpacpi_nvramd as active root-owned processes. – user001 Aug 13 '14 at 22:44

Not the answer you're looking for? Browse other questions tagged or ask your own question.