Comment 4 for bug 596515

Ok, here's the critical section of the log:

[./plugin.c] create_backend:creating renderer backend for device /dev/dri/card0
[./plugin.c] load_driver:Attempting to load driver '(null)'
[./plugin.c] load_driver:drmOpen failed
[ply-renderer.c] ply_renderer_open:could not open rendering device for plugin /lib/plymouth/renderers/drm.so
[./plugin.c] create_backend:creating renderer backend for device /dev/fb0
[ply-terminal.c] ply_terminal_open:trying to open terminal '/dev/tty7'
[ply-terminal.c] ply_terminal_look_up_geometry:looking up terminal text geometry
[ply-terminal.c] ply_terminal_look_up_geometry:terminal is now 128x48 text cells
[./plugin.c] query_device:Visual was FB_VISUAL_PSEUDOCOLOR, trying to find usable mode.
[./plugin.c] query_device:Visual is FB_VISUAL_DIRECTCOLOR; not using graphics
[ply-renderer.c] ply_renderer_open:could not query rendering device for plugin /lib/plymouth/renderers/frame-buffer.so

So the DRM driver is failing to load; and the fallback to the framebuffer driver also fails (as expected - bug #564471) because there's no truecolor fb available.

The question is, why does the drm driver fail to load?

Please show the output of:

$ readlink /sys/dev/char/$((0x$(stat -c '%t' /dev/dri/card0))):$(stat -c '%T' /dev/dri/card0)/device/driver
$ ls -l /sys/dev/char/$((0x$(stat -c '%t' /dev/dri/card0))):$(stat -c '%T' /dev/dri/card0)/device/driver/

This may indeed be an arch-specific bug with the driver not being correctly exposed under sysfs.

> When I boot with the option you specified although the machine boot up, GDM
> never came up. Is that expected?

No, it's not.