Hang during boot after kernel update (2.6.20-16.28) due to "missing" hddtemp partitions

Bug #117621 reported by Vajra Vrtti
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
hddtemp (Ubuntu)
Invalid
Undecided
Unassigned
linux-source-2.6.20 (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

Binary package hint: linux-source-2.6.20

After updating to kernel 2.6.20-16.28 the boot process hangs, apparently while starting the X server. Usually the system hangs with a black screen at the point it should display the GDM (login) screen. Less frequently a frozen X shaped cursor is visible in the center of the black screen. The keyboard is inactive: 'caps lock' or 'num lock' do not work. The HD led blinks every 2 seconds. A hardware reset is required.

The problem occurs with both 'nvidia-glx' and 'nv' drivers (standard install from Ubuntu repositories).

The system works fine with the previous 2.6.20-15 kernel.

Otherwise, I was able to boot kernel 2.6.20-16.28 in recovery mode and and successfully start the X server (startx) from the command line. That gave me a desktop in root mode. I manually started GDM and restarted the X server (ctrl+alt+back) and that gave me my usual GDM login screen, from which I was able to login to my personal account. After an initial error message saying 'failed to initialize HAL' the system was quite functional, including Beryl. Although /dev/sda and /dev/sdb were changed to /dev/hde/ and /dev/hdg/ I could access all partitions, including NTFS read/write. The only problem was that I could not mount neither my cdrom nor my USB pendrive. Trying to access the cdrom from Nautilus gave an error message saying '/dev/sdc0 does not exist'.

Revision history for this message
Vajra Vrtti (vajravrtti) wrote :

The attached documentation referes to a boot using the 'nv' driver.

Revision history for this message
Vajra Vrtti (vajravrtti) wrote :
Revision history for this message
Vajra Vrtti (vajravrtti) wrote :
Revision history for this message
Vajra Vrtti (vajravrtti) wrote :
Revision history for this message
Sitsofe Wheeler (sitsofe) wrote :

The drive naming issue is Bug #116996 ...

Revision history for this message
Sitsofe Wheeler (sitsofe) wrote :

Thank you for your bug report (very thorough).

Varjra:
If you disable beryl can you do a successful boot with the nv driver? Do you get any further if you remove the splash option from grub?

Revision history for this message
Vajra Vrtti (vajravrtti) wrote :

I think Beryl is definitely not involved. I have never have Beryl started automatically. I always begin with a Metacity desktop and start Beryl manually from "System Tools->Beryl Manager". Anyway, for the test I explicitly set the desktop manager to Matacity in Beryl Manager and then rebooted using the 'nv' driver and kernel 2.6.20-16.28. It made no difference. I got the black screen exactly as before.

After a successful boot with 2.6.20-15 Xorg.0.log seems the same, with the following lines added at the end:
(II) Configured Mouse: ps2EnableDataReporting: succeeded
Could not init font path element /usr/X11R6/lib/X11/fonts/misc, removing from list!
Could not init font path element /usr/share/fonts/X11/cyrillic, removing from list!
Could not init font path element /usr/X11R6/lib/X11/fonts/Type1, removing from list!

In the syslog, the message "apm: disabled - APM is not SMP safe" is followed by the start of the Bluetooth daemon. Since I don't use Bluetooth, I tried to uninstall the package bluez-utils, because other people were reporting network problems. But that also made no difference.

Revision history for this message
John Haines (wanderer) wrote :

I can confirm this as well...
Can't have anything to do with Beryl, as I have never had that on my system...

Revision history for this message
Vajra Vrtti (vajravrtti) wrote :

I decided to test a fresh installation on a different partition. I installed Feisty from the same CD I used before. After rebooting the new installation, and without making any customization, I let Update Manager apply all available updates. Surprisingly, the new kernel 2.6.20-16.28 booted without any problem. Not only that, but my cdrom and my USB pendrive also worked fine.

We may conclude that the problems were unrelated to anything in my hardware and must have been caused by some other installed software. As time permit, I will continue to install all the packages I have in my normal system, as well as replicate its configurations.

Revision history for this message
Sitsofe Wheeler (sitsofe) wrote :

Vajra:
Can you attach the
/etc/fstab
and
/etc/initramfs-tools/conf.d/resume
from both the old and new installs?

Revision history for this message
Vajra Vrtti (vajravrtti) wrote :
Revision history for this message
Vajra Vrtti (vajravrtti) wrote :

PROBLEM FOUND.
The reported problem was caused by 'hddtemp'.
The system boots OK with kernel 2.6.20-16-generic after removing that package.
As far as I can see, all applications are working fine.

Revision history for this message
Sitsofe Wheeler (sitsofe) wrote :

Punting from linux-source -> hddtemp . I guess hddtemp should learn to use UUIDs...

Revision history for this message
Vajra Vrtti (vajravrtti) wrote :

ATTENTION!
A system using kernel 2.6.20-16 will hang during installation of package 'hddtemp'. In such case, a hardware reset will be required. The next boot will hang while loading the X server. If there was no previous kernel to fall back the system will be unusable, unless the user is skilled enough to boot in recovery mode, run a 'dpkg --configure -a', and then remove 'hddtemp' from the command line.

Revision history for this message
Vajra Vrtti (vajravrtti) wrote :

This problem seems to be solved in kernel version 2.6.20-16.29.

Revision history for this message
Sitsofe Wheeler (sitsofe) wrote :

Vajra:
A new kernel (2.6.20-16.29) reverting the piix changes was released: http://www.ubuntu.com/usn/usn-470-1 on 08 June 2007. Additionally a new wiki page describing how references to partitions should be UUIDs/labels has recently appeared: https://wiki.ubuntu.com/UsingUUID . This will have changed the partition block device names back to what hddtemp was expecting.

The underlying problem is actually still there though (hddtemp should be default to using UUIDs/labels for partitions and shouldn't hang when it can't find them).

Revision history for this message
Sitsofe Wheeler (sitsofe) wrote :

Closing linux-source-2.6.20 product as libata change has been reverted (see Bug #116996 and Bug #117314 ).

Changed in linux-source-2.6.20:
status: New → Fix Released
Revision history for this message
Adam Niedling (krychek) wrote :

I'm closing this bug based on the original reporter's last comment.

Changed in hddtemp:
status: New → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.