This was not a problem initially after upgrading from v11.3. It started about a week afterward. It is now quite consistent.
At a point where the boot sequence initializes the sound adapter, the screen goes black because the video is turned off, i.e., the output from the video adapter is ended. I say the “sound adapter” because I hear a faint thump from the speakers when the sound is initialized.
At this point the system is dead.
I can boot in Failsafe mode, usually. Which maybe implies a timing problem.
There is nothing in </var/log/messages> between the normal shutdown and the successful boot in Failsafe mode. The two intervening system crashes are not recorded.
and also immediately after a failed boot attempt, boot to failsafe mode and open the file /var/log/Xorg.0.log.old (which is the X log from the failed boot) and copy and paste it to SUSE Paste. And then post here the website / URL address.
Also while still in that failsafe session (after a failed boot) open with a text editor the file /var/log/boot.0msg (which is the dmesg log file from the failed boot) and copy its contents to SUSE Paste and then post here its website / URL address.
That makes no sense. That says you are using the ‘radeon driver’ from the ‘lspci’ command in FailSafe mode, and the Xorg.0.log.old says you attempted and failed to use the FBDEV driver during a regular boot. I should be seeing the opposite.
ie in FailSafe mode you should be using the FBDEV driver (and hence we should NOT see ‘kernel driver in use radeon’ in the lspci), and in the Xorg.0.log file we should see either radeon or fglrx failing.
It almost looks like you grabbed the xorg.0.log by mistake instead of the xorg.0.log.old (or the error is very unusual)
I can confirm that by the /var/log/Xorg.0.log file which has
ie in both cases, those files are showing the content of a ‘failsafe’ boot and not a regular boot.
I need you to attempt a regular boot. That will fail. Then attempt a ‘failsafe’ boot. Then provide those log files (Xorg.0.log.old and boot.0msg).
Those log files represent the previous boot attempt. If the failsafe boot fails and you need to boot failsafe twice, that does not help as it will only show me the failed failsafe boot, which is not what I want to review.
As oldcpu says I would definitely try adding the nomodeset flag when you do a normal startup, I have a Dell Studio 1558 and needed to add this after installing the ATI drivers from their repository otherwise my machine had exactly the same symptoms as yours.
Likely you are now booting to the ‘radeonhd’ graphic driver, which in fact is not as fast as the ‘radeon’ driver.
It is possible the ‘radeon’ driver will still work if you using both the ‘radeon’ driver and the ‘nomodeset’ boot code at the same time.
If you wish to test that hypothesis, before testing that I recommend you install the application ‘midnight commander’ (mc) which is a text editor that is easy to use in a full screen text mode. Once it is installed one just types ‘mc’ to launch it and the rest is pretty intuitive. mc may or may not already be installed. Keep that text edit capability in mind in case you ever get stuck in a full screen text mode.
Then with any text editor, edit the file /etc/X11/xorg.conf.d/50-device.conf uncommenting the line with ’ Driver “radeon” ’ in it so that the file looks like:
Identifier "Default Device"
# ## Required magic for radeon/radeonhd drivers; output name
# ## (here: "DVI-0") can be figured out via 'xrandr -q'
# #Option "monitor-DVI-0" "Default Monitor"
and save the change and reboot using the boot code ‘nomodeset’ . If that fails, then reboot to failsafe and remove the edit. Do NOT keep backup files in the directory /etc/X11/xorg.conf.d/