hard drive not detected since gutsy update

NB: this is a internal hard drive.

It seems it's dying on first platter access to read the partition tables, *or* it is chewing some corrupt partition information and barfing after that. The backtrace seems to point to my first hunch. I wish I could do more :-(.

Thanks for your answer Rudd-O.
But why Feisty have no problem to mount that drive ? And why I can boot on this partition ?
Because, if I understand your answer, it's a problem, maybe material, of my hard drive.
I think, if you're right, that I'll try to resolve the problem with the manufacturer software.

I have no idea but I *know* that one of my machines dies right after finishing booting here with Gutsy. The stopgap measure was to just boot with the older, feisty kernel (letting grub know that the default boot entry was the feisty one because that machine is headless and I don't have time to lug around a monitor just to diagnose the clunker). There's no easy way to point-and-click your route to the installatin of the feisty kernel, but if you manage to do it, you will have no problems because the feisty kernel works just fine with Gutsy.

I'm really sorry I can't fix the issue, but you should really report this backtrace in Launchpad Bugs.

Silly me, I thought I was answering to an LP question instead. :-)

It seems to be a problem with Seagate hard drives and the Gutsy kernel.

I confirm this bug and just added an Open Question #16234. My details:

I upgraded Feisty to Gutsy but found Gutsy reboot hung with the message:

udevd-event[2118]: run_program : '/sbin/modprobe' abnormal exit
Busybox v1.1.3 (Debian 1:1.1.3-5 ubuntu7) Built-in shell (ash)
(initramfs)

On typing return or exit Gutsy continues to boot BUT my 2nd hard drive, containing my Linux swap partition, isn't recognised (the drive also contains two network shared ntfs partitions). Rebooting into the 2.6.20-16 kernel (left over from the Feisty installation) loaded the 2nd drive with my Linux swap file but there were problems with X 'forgetting' the configuration file and dropping back to either a 640x480 or 800x600 safe mode resolution on reboot.

As this pc is a second machine I thought I'd experiment by wiping out the Ubuntu upgrade, trying a fresh install instead to see if that produced better results. Gutsy hung during the boot-up process with the same udevd-event report stopping at the initramfs prompt and the 2nd hard drive wasn't seen by the live CD either. Typing return or exit got the boot to continue. I still couldn't get the 2nd hard drive recognised from within the fresh Gutsy install either. There were a few problems getting the restricted driver working and my splash screen was the wrong resolution.

I re-installed Feisty, left it as a vanilla install (no n-Vidia restricted driver, sharing or any extra packages) and updated the system. All running smoothly. Rebooted and ran a system upgrade to Gutsy again - same problem, hanging at the udevd-event but this time the code was [2124] and no 2nd hard drive with Linux swap! Looking at other posts I tried booting into the 2.6.22-14 kernel and ran 'sudo update-initramfs -u' but the problem persisted.

Deciding to check /etc/fstab and /dev I think I may have discovered where the problem lies but am unsure how to fix it. Both fstab and /dev list my hard drives and partitions as hdax or hdbx NOT the now more common sdax or sdbx, There are no references to sd's in /dev although I believe initramfs is looking for drives with the 'sd' prefix in /dev (I only have hd's), despite how they are configured in fstab or /dev.

Can anyone help me please?

The Problem seems to be in a list of Seagate harddrives which require special treatments. Here is the source code that causes problems:

static const struct drive_list_entry hpa_list[] = {
 { "ST340823A", NULL },
 { "ST320413A", NULL },
 { NULL, NULL }
};

You see the *two* affected harddrives. The firmware version, which is the second field in the struct is set to NULL. The function strstr(const char* haystack, const char* needle) chokes on a NULL-needle. Looking at the other places where such a list is constructed and how these lists are used, the fix (or at least workaround) is easy:

static const struct drive_list_entry hpa_list[] = {
 { "ST340823A", "ALL" },
 { "ST320413A", "ALL" },
 { NULL, NULL }
};

I changed the source and built a custom kernel for the affected system and it works now. Hope this helps.

Beginning with the Hardy Heron 8.04 development cycle, all open Ubuntu kernel bugs need to be reported against the "linux" kernel package. We are automatically migrating this bug to the new "linux" package. However, development has already began for the upcoming Intrepid Ibex 8.10 release. It would be helpful if you could test the upcoming release and verify if this is still an issue - http://www.ubuntu.com/testing . If the issue still exists, please update this report by changing the Status of the "linux" task from "Incomplete" to "New". We appreciate your patience and understanding as we make this transition. Thanks!