Screen blanks after "Loading hardware drivers" in Alpine 3.5 likely due to framebuffer driver configuration.
After upgrading from Alpine 3.4 to 3.5 (Kernel 4.4.41-0-grsec or 4.4.44-1-grsec, architecture is x86_64), the screen blanks after the message “Loading hardware drivers”. The system is still running, and I can still log on by typing a valid username and password (although I cannot see anything on the screen yet).
After logging on as root I can get a visible console screen at the native resolution of the monitor if I load the fbcon module by typing “modprobe fbcon” (i.e. the console becomes visible immediately after loading the module).
After logging in as any valid user (with or without first loading the fbcon module), I can type “startx”, and the graphical interface starts and works as usual (including hardware acceleration), except that it shows up under the same tty as the login instead of under tty6 or tty7, as it used to. If I haven’t loaded the fbcon module, there is still no console upon logging out of the graphical interface.
Alternatively, I can set the following parameter on boot “radeon.modeset=0”, and the console will remain visible after “Loading hardware drivers”, although it will not change to the native resolution of the monitor. After logging in as root, I can get a working console at native resolution by typing “modprobe fbcon” then “modprobe radeon modeset=1” to set the video driver for modesetting. If I do not enter “modprobe radeon modeset=1”, I can still get to the graphical interface by “startx” (again, under the same tty as the login), but without hardware acceleration.
Note that the fbcon module was not required for a visible console at native monitor resolution in Alpine 3.4 (or 3.3, or 3.2; I don’t know about before that). I don’t have a problem with the fbcon module, but I simply don’t like the system booting into a blank screen by default. And, graphical interfaces back under tty6 and tty7, would be good.
I believe this problem is related to changes in the framebuffer driver
configuration, probably changes to fix Bug #5191:
https://bugs.alpinelinux.org/issues/5191
This likely also caused the problem reported in Bug #6490:
https://bugs.alpinelinux.org/issues/6490
Related reports:
https://forum.alpinelinux.org/forum/general-discussion/kernel-4434-r1
https://forum.alpinelinux.org/forum/installation/install-latest-version-no-console-after-reboot-solved
https://forum.alpinelinux.org/forum/kernel-and-hardware/limbo-boot
(from redmine: issue id 6723, created on 2017-01-23)
- Relations:
- relates #6490 (closed)
- Changesets:
- Revision a7d79124 by Timo Teräs on 2017-01-24T09:49:19Z:
main/eudev: load fbcon when graphics subsystem is loaded
If this does not work, you probably have not setup udev-trigger
init.d service to run. Use 'setup-udev' script to fix this.
ref #6490
ref #6723
- Revision 4dbfdda9 by Timo Teräs on 2017-01-25T07:29:32Z:
main/eudev: load fbcon when graphics subsystem is loaded
If this does not work, you probably have not setup udev-trigger
init.d service to run. Use 'setup-udev' script to fix this.
ref #6490
ref #6723
(cherry picked from commit a7d791240b62a09a49b910469aad1ef54e69aa2a)
- Revision 818fc799 by Natanael Copa on 2017-01-25T07:31:51Z:
main/openrc: fix hwdrivers to load fbcon on /dev/fb0
Instead of checking for fb module we check for /dev/fb0 since we now
compile fb directly into the kernel instead of module.
We also allow blacklisting it by using `modprobe -b`
ref #6723
(cherry picked from commit ab0a08bd0106ce966db6049ca05a0ef7133c7ae0)