Kernel 2.6.20-16 ATA drives weren't recorgnized as SATA anymore (Feisty)

Bug #117876 reported by fnf
4
Affects Status Importance Assigned to Milestone
linux-source-2.6.20 (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

Binary package hint: linux-image-2.6.20-16-generic

I upgrade to 2.6.20-16-generic this morning, from 2.6.20-15-generic. The kernel didn't recognize my ATA Hitachi drive as SATA as the previous kernels did.

The system also stopped to ask me to enter the image name to resume when it was checking for resume suspend image. I had to press 'Enter' to continue, after that, all things are normal (except the above problem). I wonder whether this should be in a separate bug report ?.

Steps to reproduce:
 - Boot with 2.6.20-16-generic kernel, Ubuntu Feisty Fawn desktop with the latest updates applied.

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

Thank you for your bug report.

VAnhTu1987:
Assuming that lspci lists your controller as an ICH4/ICH5 (or possibly an ICH6) the device renaming issue sounds like Bug #116996 . The issue with the "broken resume" might have happened because /etc/initramfs-tools/conf.d/resume references your suspend partition using a /dev/ syntax rather than a UUID...

Revision history for this message
fnf (vanhtu1987) wrote :

Hi.

The idea controller is indeed of the ICH7 family. I noticed several people in the #116996 thread also had the resuming problem, but '/etc/initramfs-tools/conf.d/resume' uses UUID, I doubled checked.

I can do S2D/resume normally with the newest kernel, only if there's no resume image, it asked for one. Booting with the -15 kernel was fine.

Let me know if you need more details, thanks.

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

Hmm ICH7 controllers should not be affected by the change in -16. Can you include the output of
lspci
cat /etc/fstab
cat /etc/initramfs-tools/conf.d/resume
. Can you also use
sudo vol_id /dev/hda1
where hda1 is the name of your swap partition to see what its current UUID is.

Revision history for this message
fnf (vanhtu1987) wrote :

The result is attached below, currently I'm running the -15 kernel though. Here is the vol_ids of my two swap partitions:

$ sudo vol_id /dev/sda7
ID_FS_USAGE=other
ID_FS_TYPE=swap
ID_FS_VERSION=2
ID_FS_UUID=62d5b70c-566b-4eab-ad74-b946d71d7152
ID_FS_LABEL=
ID_FS_LABEL_SAFE=

$ sudo vol_id /dev/sda14
ID_FS_USAGE=other
ID_FS_TYPE=swap
ID_FS_VERSION=2
ID_FS_UUID=465cadaa-6446-4f1b-8876-d40c62a5d4c8
ID_FS_LABEL=
ID_FS_LABEL_SAFE=

How are these different from the symlinks in /dev/disks/by-uuid/ ?.

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

VAnhTu1987:
You could reference those directly but usually things that use UUIDs have a means to resolve a UUID directly into a /dev/ device (perhaps some programs don't cope well with following symlinks when they want a device node?).

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

It turned out that some ICH7 controllers were affected too. See https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/116996/comments/79 . Are things any better with the new 2.6.20-16.29 kernel release?

Changed in linux-source-2.6.20:
status: Unconfirmed → Needs Info
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for linux-source-2.6.20 (Ubuntu) because there has been no activity for 60 days.]

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

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