IDE hard drives not visible

Bug #222322 reported by Don Malcolm
40
Affects Status Importance Assigned to Milestone
Debian
New
Undecided
Unassigned
Fedora
Invalid
Medium
linux (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

Binary package hint: linux kernel

Not all IDE hard drives being detected and reported in fdisk -l.

In earlier kernels IDE devices were accessed as hda hdb hdc hdd. It would seem that these are now being mapped to sda sdb etc.

One of my IDE hard drives is not being detected.

The problem seems to relate to putting hard drives on the secondary IDE controller. For example when you have one drive as master on hda and another as master on the secondary controller on hdc. Only hda is picked up and converted to sda. Unfortunately hdc is not visible. Doing 'fdisk -l' only reports on drives on the primary controller.

Furthermore, in other configurations, I have had only drives on the secondary controller being picked up, with drives on the primary controller invisible.

My hardware is under two years old.

Gutsy works fine. Gutsy correctly addresses my IDE devices.

I have for much of yesterday and today been attempting to install Hardy. But without success. I tried a fresh install of Dapper, and upgrade to Hardy, but that failed with unresolvable dependencies, that did not resolve when instructions to -f install were followed.

So I did a fresh install of Gutsy and upgrade to Hardy. This correctly addressed my IDE devices in Gutsy, but failed after the upgrade (otherwise successful) to Hardy.

Being totally disillusioned with Hardy, I installed Fedora Core 8 (just released). Interestingly, the same fault occurred there also. So this leads me to believe the source of this show stopper bug, is somewhere upstream.

I am forced to abandon Hardy, and will make do with Gutsy, until a resolution to this bug is made available.

Maybe related to this. On another machine that has no IDE devices connected, the grub bootloader in Hardy failed, and gave the option of LILO during the install. It now is fully functional using the LILO bootloader.

Revision history for this message
Don Malcolm (lpad6) wrote :

This problem appears to be a kernel issue. When I select kernel 2.6.22-14-generic from the grub menu during boot up, the IDE addressing behaves normally, and I can access all my hard drives. When I select kernel 2.6.24-16-generic the IDE addressing is screwed, and I can only access some of my hard drives.

Note also that at no time was there a sdc or sdd. When running the 2.6.24-16-generic kernel, there is at most just sda and sdb. I have three hard drives, and with the 2.6.22-14-generic kernel there is hda hdb and hdc.

Revision history for this message
Don Malcolm (lpad6) wrote :

Just checking back through prior bug reports. I found two bug#222115 and bug#221677 that may relate to this one. Going further back there are several other complaints of not being able to access a CD drive.

Revision history for this message
Don Malcolm (lpad6) wrote :

When I attempted to install Hardy for the first time, the install location was on hdc the master on the secondary controller. The install completed, and upon reboot, it reported file not found. I believed at the time this was due to the grub loader getting confused about where things are located.

I swapped the IDE controller cables, to make the install location on hda the master on the primary controller. The install is now successful excepting that I can not address all my hard drives.

It makes no difference if Hardy is installed from disk, or upgraded from a prior version. Previously I reported that the problem happens with the 2.6.24-16-generic kernel, and not with the 2.6.22-14-generic kernel. This was done with all else being the same. That is, I booted into the same partition, only selecting a different kernel in the grub boot menu.

Attached is the output of lshw taken when running Dapper from the second partition on the master on the primary IDE controller.

Revision history for this message
Don Malcolm (lpad6) wrote :

Attached is the output of lshw taken when running Hardy from the first partition on the master on the primary IDE controller.

Revision history for this message
Darko Surjan (dsurjan) wrote :

Looks like bug#93655. Is your /etc/fstab migrated to uuid? If it's not, you should run /usr/lib/udev/migrate-fstab-to-uuid.sh

Revision history for this message
Don Malcolm (lpad6) wrote :

No Darko, it is not to do with uuid in the fstab.

For the record, the fstab does use UUID to identify the disks.

Please read more carefully. You will see that I have stated, that fdisk -l does not report all my disks. Furhermore you will see that I have included output from lshw. If you would kindly take the time to examine the output of lshw from Dapper and Hardy installs, you will see that a disk is missing from the Hardy install that is present in the Dapper install. Note that this output was taken from my current hardware configuration. As I have stated above, Dapper is installed in the second partition on the master of the primary controller. Hardy is installed on the first partition on the master of the primary controller.

Furthermore please note that when attempting to install Hardy in a disk on the seconday IDE controller, the install fails because it fails in the kernel to identify all my drives. I suspect the reason for the file not found message I stated above, was that it installed on the disk on the secondary controller, but then on reboot, the disk was no longer visible.

It does not appear to me to be a configuration issue, but rather a kernel issue. Why? As I stated above, the problem also exists in Fedora Core 8, also by booting Hardy but with the Gutsy kernel, all disks are identified properly. Simply changing the kernel and only the kernel to an earlier kernel, the system is fully operational with all disks correctly identified in fdisk -l.

Point taken regarding use of sda in place of hda. I was not aware of this change. It would seem there are bugs in this change over.

Configurations that failed for me in Hardy:

1) Two drives, with one as master on the primary controller, and one as master on the secondary controller. Only one drive shows up in fdisk -l

2) Three drives, with two on the primary controller and the other as master on the secondary. Only two drives show up.

3) Three drives, with two on the secondary controller and the other as master on the primary. Only two drives show up.

At the moment, I am running Hardy with two drives on the primary controller, with both drives accessible, and the third as master on the secondary controller, and is not visible in fdisk -l.

Revision history for this message
Don Malcolm (lpad6) wrote :

One other thing I will mention. When running the live Hardy CD, the same symptoms exist. I can see two of my three drives in fdisk -l. Definitely need a new kernel.

Don Malcolm (lpad6)
description: updated
Revision history for this message
In , Don (don-redhat-bugs) wrote :

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.14eol) Gecko/20080418 Ubuntu/dapper-security Firefox/1.5.0.12eol

Description of problem:
Not all IDE drives are visible to fdisk -l.

I have three drives, two on the primary IDE controller, and one as master on the secondary IDE controller. Only the two on the primary IDE controller show up in fdisk -l.

All three hard drives are visible in earlier kernels that map IDE drives to hda hdb hdc etc. With this kernel, they are mapped to sda sdb but there is no sdc.

I initially encountered this problem in Ubuntu Hardy 8.04. When I first attempted to install Ubuntu Hardy, it was on the master on the secondary controller. It installed but failed on reboot. So I swapped IDE cables, and installed on the master on the primary controller. While it now installs, it still does not recognise all three drives.

Running Fedora Core 8 exhibits the same symptoms of not making all IDE hard drives visible. I suspect that were I to attempt an install on a drive on the secondary controller, Fedora would also fail.

Another configuration that also failed in Ubuntu Hardy is two drives, one as master on the primary controller, and the other as master on secondary controller. Only one drive is visible.

More information and details of hardware can be found at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/222322

I believe the problem to be in the kernel. See the above link for more details.

Version-Release number of selected component (if applicable):
kernel-2.6.23.1-42.fc8

How reproducible:
Always

Steps to Reproduce:
1. Boot Live Fedore Core 8 CD
2. Login terminal session as root
3. Run fdisk -l

Actual Results:
Only can see two of my three drives. See launchpad for more details.

Expected Results:
To be able to access all three hard drives.

Additional info:

Revision history for this message
In , Dave (dave-redhat-bugs) wrote :

Please install the latest errata kernel, (which will likely have the same bug),
and attach the output of the dmesg command here.

Thanks.

Revision history for this message
scananza (scananza) wrote :

I think I have the same problem as you guys, after gutsy->hardy upgrade I lost my cdrom drive which used to be addressed as /dev/hda (my HD is serial ata and so not connected to the standard IDE bus). I only have a /dev/sr0 and /dev/scd0 entries which relate to scsi emulation stuff, I think. The cdrom is in fact undetected by all the ubuntu high-level subsystem (gnome, and stuff). I tried to do a fresh install and the installer stops telling me it's unable to mount the cdrom drive.

I think a patch to the kernel to fix this is quite urgent because it makes many systems almost unusable.

Revision history for this message
Don Malcolm (lpad6) wrote :

I posted this problem on Bugzilla. They have a kernel update available that I have been asked to try. I will try with Fedora Core 8 later Today when I can get some time to test this.

They also asked for the output of dmesg. So I have attached the output of dmesg here for my Hardy install.

I booted into Hardy, opened a terminal window, then as root run fdisk -l, and captured the output of dmesg to file as attached.

Revision history for this message
scananza (scananza) wrote :

I add a little thing about my fresh install try: before installation hung telling not being able to mount the cdrom drive, the screen was flooded but such messages (process stalled for a couple of minutes):

ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata3.00: cmd a0/01:00:00:20:00/00:00:00:00:00/a0 tag 0 dma 32 in
         cdb 46 00 00 00 00 00 00 00 20 00 00 00 00 00 00 00
         res 40/00:02:00:0c:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
ata3.00: status: { DRDY }
ata3: soft resetting link
ata3.00: configured for UDMA/25
ata3: EH complete

I also attach my box fstab, if it can be in any way useful.

Revision history for this message
scananza (scananza) wrote :

errata: I meant dmesg, not fstab ;^)

Revision history for this message
Philipp Enoeckl (philofive) wrote :

i have the same problem here, complete new Hardy Server installation
my second harddrive is unmountable, same error messages than scananza.
I am using the gutsy kernel now on the machine (some other things are not working like apt-cdrom add), however i will wait, until there is a kernel-patch available, before i start using the machine properly

Revision history for this message
In , Don (don-redhat-bugs) wrote :

Created attachment 303962
Output of dmesg

Revision history for this message
In , Don (don-redhat-bugs) wrote :

The problem still exists and is unchanged after a fresh install and running
yum update to apply the latest updates. The output of uname -a is:

Linux home 2.6.24.4-64.fc8 #1 SMP Sat Mar 29 09:54:46 EDT 2008 i686 i686 i386
GNU/Linux

Revision history for this message
Don Malcolm (lpad6) wrote :

I am now thinking this problem may be related to the specific hardware that I am using. The full hardware listing is included above in the output of lshw when run on Dapper. The one from Hardy is missing one drive.

There are a couple of warning messages in the dmesg listing included above.
Driver 'sd' needs updating - please use bus_type methods
Driver 'sr' needs updating - please use bus_type methods
Some people suggest that these messages are of no consequence. I don't know, it just what I have read.

I think this problem is in the kernel, and will require a new kernel to fix this.

Revision history for this message
In , Chuck (chuck-redhat-bugs) wrote :

The disk should be recognized here as ata2.00:

  ata2: port is slow to respond, please be patient (Status 0x80)
  ata2: SRST failed (errno=-16)
  ata2.01: ATAPI: ASUS DRW-1608P3S, 1.24, max UDMA/66
  ata2.01: configured for UDMA/66

Is the cabling right on this channel? libata is a lot pickier than old IDE about
drives being jumpered correctly and connected to the right connector on a
parallel cable.

Revision history for this message
In , Don (don-redhat-bugs) wrote :

Thanks Chuck. Spot on. The cable end that typically goes in the controller was
in the CD drive, with the center connector in the controller, and the short
lead to the hard drive. The jumpers were correct.

I relocated the hard drive to be near the CD drive, and with the two
connectors that are close to each other, connected one in the CD drive and one
in the hard drive, with the long lead going to the controller on the
motherboard.

Other than relocate the hard drive, the only thing I did was change the IDE
cable around, and it is now working fine.

Once again, thanks Chuck, well spotted.

The only last comment I have, is that older versions of Linux handle the
reversed connection of the IDE cable, and for the less technically competent
user than I, they may find swapping around an IDE cable outside their
abilities. Basically for the average home user, they would be unable to
resolve this problem, and for some users, unable to install Fedora Core 8.
Therefore I encourage that this bug report remain open, until a fix to the
kernel/libata is made to make it more tolerant of cabling.

Revision history for this message
Don Malcolm (lpad6) wrote :

Thanks to the Red Hat team, I am now able to access all my hard drives. Refer to https://bugzilla.redhat.com/show_bug.cgi?id=444334 for details.

The problem for me turns out to be an issue with how the IDE cable is connected. The center connector is near one end, and the end furthest away from the center connector is typically connected to the controller on the motherboard. In my case, the end typically connected to the motherboard was connected to the CD drive, and the center connector to the controller on the motherboard, with the short end going to the hard drive.

I relocated the hard drive to be near the CD drive, and using the two connectors near each other, connected the CD drive, and to the hard drive, with the long end going to the controller on the motherboard.

Other than relocate the hard drive, the only change I made is to the IDE cabling. Now it works fine. I can access all three hard drives.

One last comment. For the less technically competent user than I, relocating drives and changing cabling, would be prohibitive. The average home user may not be able to fix this problem, and for some users, they would be unable to install Hardy. I recommend that this bug report remain open until a fix is made to the kernel/libata that is more tolerant of cabling.

Revision history for this message
scananza (scananza) wrote :

Hi Don,
If found out that I also had the longest tail of the IDE cable attached to the CDROM and not to the MB but, unfortunately, that didn't solve the problem (I also switched to a brand new IDE cable, just to be sure, since the old one was pretty twisted and deformed).

My setup is quite simple: just the CDROM as primary master, there are no other devices, the second bus is empty.
I tried to connect the CDROM both to the middle and to the end connector but no way.
BIOS recongnize correctly the device as primary master and the kernel detects a scsi-emulated cdrom, loads the proper devices /dev/sr0 and /dev/scd0 but NOT the standard /dev/hda. For the rest of the operating system the cdrom simply doesn't exist and forceing apps to use /dev/sr0 just hangs them.

This bug is really annoying, if it's kernel-related stuff, I hope a new patched kernel will be added to repositories as soon as possible.

Revision history for this message
In , Chuck (chuck-redhat-bugs) wrote :

Maybe Alan can explain why libata is pickier than old-IDE about correct PATA
cabling... I sure can't.

Revision history for this message
In , Alan (alan-redhat-bugs) wrote :

Nor me - and I've also seen the reverse case. With a dodgy cable you are into
timing and luck when the drives come up and it may just be that because we reset
the bus to get a clean start that this happens to cause a timing problem between
the drives due to the wrong cable.

Given PATA command blocks are never checksummed I think I prefer the failure
case to obscure random corruption anyway.

Revision history for this message
Don Malcolm (lpad6) wrote :

Scananza,

Follow the link above to the Red Had Bugzilla site for the full resolution discussion. There it is stated, that problems exist with both cabling and jumper settings. In my case, recabling with the long end to the controller, fixed my problem. The bios handles the boot hugely faster now. My jumper settings are for the hard drive as master with slave present, and for the CD/DVD as slave.

In your case, make sure the long end of the cable is connected to the controller, and that the jumper settings on the back of the CD drive are configured for master. Not cable select or anything else.

Revision history for this message
In , Don (don-redhat-bugs) wrote :

I have been running with this configuration since purchase of this computer
around two years ago. The computer was configured by the assembler in this
configuration prior to my purchase. The only thing I did was to add two drives
on the other controller. Having the center connected to the controller on the
motherboard, has worked fine excepting that now I have changed it around, I can
see that the bios was handling the boot slowly. It is booting much faster now.

I don't believe there to be any physical problem with the cable. It is just that
it was installed in a non optimal direction.

It surprised me that changing the cable around made a difference. Because
Windows and versions of Linux prior to the latest releases, handle the alternate
arrangement of the IDE cable fine. It is just the latest releases of Linux that
have a problem with the non optimal arrangement.

After changing the cable around, and seeing this fixed the problem, I changed it
back. The problem returned. I then changed it around to having the long end to
the controller again, and it works.

Revision history for this message
scananza (scananza) wrote :

I've checked out the jumper, it's correctly closed on MAster; the cable has the long edge connector attached to the MB and the opposite side is stuck into the CDROM, the central connector is free.

For the sake of (computer) science, I can try if setting it to SLave or CableSelect makes it work... :^D

Later on today I will compile kernel 2.6.25 myself and see if the problem persists even with the latest IDE driver.

Revision history for this message
scananza (scananza) wrote :

....just for fun I've just effectively tried it SLave, no way (I would have been surprised of the contrary, actually)

Revision history for this message
scananza (scananza) wrote :

Tried 2.6.25 kernel and problem went away, so for me it's totally a kernel issue. Hope a fix will be released soon for 2.6.24 serie since nvidia subsystem won't compile against my 2.6.25 vanilla sources... :^\

Revision history for this message
HIRANO Takahito (hiranotaka) wrote :

I added the bug watch by mistake. Try to revert...

Revision history for this message
Lulu58e2 (cwmaguire) wrote :

I had this same problem (IDE HDD and DVD-ROM wouldn't show up automatically in BIOS, and wouldn't show up in Hardy even when I got the BIOS to recognize them): I re-cabled with the long end to the controller and it fixed the problem.

THANKS!

Revision history for this message
Philipp Enoeckl (philofive) wrote :

Funny enough, my problem went away as well. My solution was kind of crazy, but it worked. I have a master/drive slave/cdrom and another master. Problems always came with the second master.

After rejumpering the first master to cableselect (no master!) AND removing the cdromslave, my second harddrive is suddenly detected and works. Don't ask, i have no clue why, it makes absolutely no sense at all, but it works :-)

Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

Per Don's comment - https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/222322/comments/14 - I'm going to close this report. For anyone still experiencing issues, the Ubuntu kernel team is actively developing the upcoming Intrepid Ibex 8.10 release. If you could test the latest Alpha for Intrepid - http://www.ubuntu.com/testing and open a new report if your issue still exists that would be great. Thanks.

Changed in linux:
status: New → Invalid
Changed in fedora:
importance: Unknown → Medium
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.