I’m using openSUSE 11.4 with the Tumbleweed repository (kernel 2.6.39.3-37-default). A few weeks ago, I noticed that my splashscreen disappeared during boot, shutdown and hibernation. There is the following message :
bootsplash: found, but framebuffer can't handle it
For a few days, I have another more annoying problem : when I want to shutdown my computer, it doesn’t power off. The computer stays stuck with the message :
Master Ressource Control : previous runlevel: 5 switching to runlevel: 0
Master Ressource Control : Running /etc/init.d/before.local
Same thing when I want to reboot. I get the message that it switches to runlevel 6, but it is stuck.
With YaST, I tried to modify /etc/sysconfig, and set the key System/boot/halt to “poweroff” instead of “auto”, but the behaviour is the same. I don’t remember modifying anything in my BIOS before the power off problem happened. I didn’t check which updates I was installing, but I am quite sure I updated my kernel since it started without any improvement. Does anyone experience the same problems with Tumbleweed ? If this is a configuration problem, where should I look for ?
Recently Greg KH clarified the Tumbleweed problem reporting - file a report in bugzilla
You might like to try enabling multiversion kernel in /etc/zypp/zypp.conf, then giving a 3.0 series kernel a try (from Index of /repositories/Kernel:/HEAD/standard ), still rc7 but expect 3.0 “final” based kernel soon, which can be expected to arrive in Tumbleweed soon enough. If the 3.0 kernel fixes your shutdown problems that would be good info.
To get the magic into Mainline kernel, reporting hwinfo, BIOS version and what you needed to do may be longrun helpful, rather than waiting for someone else to do it.
Following robopensuse’s advice, I tried with kernel 3.0rc7 and it solves both the splashscreen and the power off problems. I also tried the boot flags “bios” and “acpi” on 2.6.39-3, but both problems are still there… I don’t have time to check the other flags now, but I can do it tonight if needed.
I didn’t file a bug report as I though Tumbleweed was considered stable and therefore tested enough to avoid “important” bugs such as this one. I’ll be aware for next time. Kernel 3.0 is near final, so I’ll keep using it. Is it useful that I report the bug or will 3.0 will be pushed to Tumbleweed soon enough ?
If you find a bug in a “stable” system releaae it’s actually MORE important to file a bug. It’s less likely to just “go away” by itself due to upstream updates.
Every release, even very stable ones have lots & lots of bugs, it’s inevitible in huge complex systems, evolving to suite the environment which changes quite rapidly with hardware changes and also new ways we use PCs.
I encountered the same problem (with LXDE in Tumbleweed-11.4), but I’ve been much too busy to report it. It is good to learn others are following this up.
I tried that in a 32-bit tumbleweed-11.4 LXDE but it did not solve the shutdown problem. The PC still freezes at same point in shutdown on the PC in which I applied it. I have not tried the 3.0 rc7 kernel in tumbleweed yet. I note 12.1 M3 does not have the boot problem on the same PC with LXDE.
Are they though? I haven’t seen a Bugzilla # for this (but I haven’t searched for it), I would but I don’t have the problem (rather I have a different problem when a particular disk is used & not otherwise).
the PC display stops updating when shutting down with the error (and no key sequences do anything):
Master Resource Control: previous runlevel 5:, switching to run level: 0
the hard drive light occasionally flashes and the PC just stays here for over 30 minutes (I shut it down then by holding down power switch in case of laptop, or pressing rest in case of desktop).
If no one else see’s this, then its possibly systemic in terms of how I have done something on these PCs with Tumbleweed, although given I have only had the repos OSS, Non-OSS, Update with lowest priority (lowest number), Tumbleweed with a higher priority, and Packman with highest, I can’t see how that can cause a problem. … I do note I had the “pcie_aspm=force” boot code in place when a kernel update was done, and I may try removing that boot code, and then force a re-install of the same kernel and see that causes this problem to disappear.
But frankly, I don’t have much time to investigate. Even to write a bug report would stretch my available time.
I removed the boot code ‘pcie_aspm=force’ . I noted appamor was installed (I thought I had removed it - makes me wonder if a ‘pattern’ update had re-installed it or I had my PCs mixedup in my head). Anyway, I checked yast’s run time services, and noted appamour was disabled and not runnig. I then removed appamor from YaST. I also forced a reinstall of the 3.0 tumbleweed kernel.
I then attempted a reboot nominally (not using that command) and obtained asimilar (same ? ) failure shutdown. This time the last two messags were:
Are you using a 3.0 kernel, because there has been RCU issues (now fixed) which could cause deadlocks during shutdown thanks to RCU/scheduler interaction - article at LWN http://lwn.net/Articles/453002/ Subscriber Only 27th July, ought to be readable by all 3rd August.
On one PC I installed the 3.0.0-38 kernel that comes with tumbleweed. It has the exact same problem. 3.0 kernel does not solve the deadlock during shutdown that I observed.
Do you have appamor enabled ? I either had it removed or disabled, and I am wondering now if its removal/disabling could have contributed to the problem. Other than that, and the ‘pcie_aspm=force’ that I removed, I can’t think of anything that I may have done to systemically cause this in two pcs with tumbleweed. I am very conservative with repositories, there only being OSS, non-OSS, Update, Tumbleweed and Packman.
If I get the time this weekend I may raise a bug report (or if everyone else has appamor enabled/installed I may try to install that and see if its return cures the problem).
Both my computers afflicted with this problem were very old PCs running tumbleweed-11.4 on LXDE. I finally got around to looking at the /var/log/messages file on my PC with nVidia hardware and I noticed this for the shutdown that was not working:
Jul 24 18:15:53 stonehenge01 su: (to root) oldcpu on /dev/pts/0
Jul 24 18:15:55 stonehenge01 kernel: 68.312029] wlan0: no IPv6 routers present
Jul 24 18:16:16 stonehenge01 shutdown[2394]: shutting down for system reboot
Jul 24 18:16:16 stonehenge01 init: Switching to runlevel: 6
Jul 24 18:16:17 stonehenge01 kernel: 90.569133] bootsplash: found, but framebuffer can't handle it!
Jul 24 18:16:17 stonehenge01 kernel: 90.569281] [drm] nouveau 0000:01:00.0: Setting dpms mode 3 on tmds encoder (output 2)
Jul 24 18:16:17 stonehenge01 kernel: 90.589503] [drm] nouveau 0000:01:00.0: 0xDDF3: Parsing digital output script table
Jul 24 18:16:17 stonehenge01 kernel: 90.589532] [drm] nouveau 0000:01:00.0: Setting dpms mode 0 on tmds encoder (output 2)
Jul 24 18:16:17 stonehenge01 kernel: 90.589538] [drm] nouveau 0000:01:00.0: Output DVI-I-1 is running on CRTC 0 using output A
Jul 24 18:16:17 stonehenge01 kernel: 90.589589] bootsplash: found, but framebuffer can't handle it!
Where ‘stonehenge01’ is the name for this computer.
I also noted a failsafe boot had no problems shutting down.
Those errors about the framebuffer suggested I needed to either change the vga mode or suppress the splash. After some failed attempts at different vga settings, I decided to suppress the splash, and I applied the boot code ‘splash=off’.
After that shutdown worked properly.
I confess having a computer fail to shutdown because of a splash setting is nasty behaviour. I also suspect this ‘feature’ of not shutting down problem has been encountered hundreds of times in the past by other users on other distros … and openSUSE on older versions. I simply never paid attention in the past and I had to reinvent the wheel to solve this myself. That will teach me for not paying attention.
… anyway, … its solved as near as I can tell. I will test this soon with my other pc with the problem which has ancient AMD/ATI hardware. But for the old nVidia hardware PC … Shutdown works now with boot code: splash=off
Now I see that message, I think someone posted that on Factory list. They have updated bootsplash. I kind of remember someone else commenting about how they got rid of all the splashy **** after every install along with various other “insane” defaults. I thought the splash screen came early-ish when I shutdown, but I have a “hit escape” reflex when I get splashes; didn’t think of that at all.
As noted above, boot code ‘splash=off’ solved this for old nVidia hardware (FX5200 graphic card). I then used the ‘splash=off’ boot code on an older old PC that also had this problem in Tumbleweed-12.1 (with AMD Radeon IGP 330M/340M/350M graphic) and the shutdown finally worked fine.
So in summary to fix the shutdown problem that I encountered, the ‘splash=off’ boot code works (to allow shutdown) on an old nVidia FX5200 and old AMD Radeon IGP 330M/340M/350M on tumbleweed-12.1. That is true for the older 2.6.39 kernel and the newer 3.0.0.38 kernel.
