Mailinglist Archive: opensuse-bugs (3710 mails)

< Previous Next >
[Bug 645986] New: kernel upgrade from kernel-desktop-2.6.34-12 to kernel-desktop- hangs machine
  • From: bugzilla_noreply@xxxxxxxxxx
  • Date: Wed, 13 Oct 2010 00:11:06 +0000
  • Message-id: <bug-645986-21960@xxxxxxxxxxxxxxxxxxxxxxxx/>

Summary: kernel upgrade from kernel-desktop-2.6.34-12 to
kernel-desktop- hangs machine
Classification: openSUSE
Product: openSUSE 11.3
Version: Final
Platform: x86-64
OS/Version: openSUSE 11.3
Status: NEW
Severity: Critical
Priority: P5 - None
Component: Kernel
AssignedTo: kernel-maintainers@xxxxxxxxxxxxxxxxxxxxxx
ReportedBy: cbowlby@xxxxxxxxxxxxxxxxxx
QAContact: qa@xxxxxxx
Found By: ---
Blocker: ---

Created an attachment (id=394558)
--> (
RPM CLI output results

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:
Gecko/20100914 Firefox/3.6.10

There are multiple areas where this is occurring. During the "update" phase of
the installation, using the system update applet via gnome's update
notification applet, using software management to do an update, and finally
installing the kernel via CLI based calls.

The symptom is that when within X-Windows/Gnome, the system locks up during the
install phase (it can download any variant of the patch (full RPM, delta, etc),
it can create the "install" RPM in the case of a delta download, but always
during an installation will it lock solid. It causes a hardware lock as well,
during the update phase of the install.

If, however, the system is dropped to init 3, the system wont hang, but it also
does not complete an install, and the system can be manually rebooted. If an
SSH connection is used to install a kernel while the system is still in init 5
state, it too does not cause a complete hardware lock.

With guidance from the forums, I have traced, what appears to be the root
cause, of the problem to the hwinfo utility, and have managed to get an strace
of the process in action during a hang. I also have output of the CLI based RPM
install if that will also help.

hwinfo --framebuffer

Seems to be the cause, and in fact it can be used to lock the system up.

Hardware details are as follows:

Intel Core i7-950 3.20 Ghz
12 GBytes DDR 3, triple channel memory.
ATI Radeon HD 4670
Gigabyte GA-X58A-UD7 mobo
1 x Intel X25-M SSD (second revision - with TRIM).
6 x 1 TB Seagate 7200.12, software raid 6 on /dev/md0 (currently not

Reproducible: Always

Steps to Reproduce:
Update during install phase:
1. Select the kernel update to be applied, remove all other components
2. Start update, watch until install starts.
3. Reboot machine due to hung/non-recoverable lock.

Update after install, using update applet, X-Windows (init 5)
1. Select only the kernel update to be applied, and start update.
2. Watch as the process downloads the delta, creates the new RPM.
3. Reboot machine due to hung/non-recoverable lock.

Update post install, in init 3 - with framebuffer:
1. use zypper to try an update via "zypper up kernel-desktop"
2. 50/50 chance system hangs, or remains responsive and can be canceled.

Update post install, with init 5 - via SSH connection:
1. Download the RPM that has the kernel version to be upgraded to.
2. rpm -ivh kernel-desktop-
3. wait for system to try to build initrd file.
4. hung at this point, but can recover system using CTRL-C.
Actual Results:
If all commands/update requests are made from within X-Windows, even if it is
at a command line, the system locks solid.

If all commands are run at init level 3, or from an SSH connection and the
system is in init level 3 or 5, the install stalls, but the system remains
recoverable by using CTRL-C.

Expected Results:
kernel update completes.

Configure bugmail:
------- You are receiving this mail because: -------
You are on the CC list for the bug.

< Previous Next >