Feisty Beta: debian-installer does not mount cdrom

[Henk Koster]

Binary package hint: debian-installer

Problem occurs when installing Feisty Beta (either Ubuntu or Kubuntu) from i386 alternate iso in a Parallels or Qemu VM on two different computers. The installer starts as per usual (with boot options "install acpi=off fb=false hw-detect/start_pcmcia=false"), asking questions about language, then starts detecting hardware and fails when it can't find a driver for the cd-rom drive (even though the procedure runs off the CD up to this point). None of the offered choices works, nor does varying the device name (/dev/cdrom, /dev/hdb, etc). This stops the installation cold.

The virtual cd-rom in these VMs is an ide device, so the ide_cd/cdrom drivers should work.
For reference, the Debian Etch (KDE) RC-2 and Knoppix 5.1 CDs don't have this problem and install easily in either VM. Furthermore, earlier Kubuntu Feisty Herd-3 and 5 versions (also alternate i386 iso) did install properly in a Parallels VM, and the Herd-5 versions has been kept up-to-date without problem.

It appears that some change was made in Feisty Beta that causes the above problem.

[Andrew Shugg (ashugg)]

Confirmed. This is the same issue raised in part (b) of bug 96123 (rejected).

The issue just happened with me when trying to install from ubuntu-7.04-beta- server-amd64.iso under Xen. The qemu cdrom device is not detected.

I have a 6.10-server-amd64 installation alongside in another Xen domain which is working just fine. I also did an installation on another host in VMware from ubuntu-7.04-beta-server-i386.iso without any problems. (Different virtualised hardware, I know.)

[Benjamin Kay (benkay)]

I disagree. This bug does not have anything to do with kvm (bug 96123) , since I was able to reproduce it in qemu without using kvm or kqemu. It appears the problem has do to with how the ata related kernel modules in ubuntu-7.04-beta-server-i386.iso detect (or, rather, fail to detect) the virtual cdrom drive provided by qemu.

Steps to reproduce with qemu-0.8.2:
$ qemu-img create -f qcow test.img 3G
$ qemu -boot d -hda test.img -cdrom ubuntu-7.04-beta-server-i386.iso
Choose "Install to the hard disk".
If you try to install as usual, the installer will fail as described by Henk Koster when it tries to detect the cdrom drive. Instead, Alt+F2 at the "Choose language" screen to get a console. Then:
# dmesg|more
The output of dmesg is telling. I've attached a screenshot to save you the trouble of doing it yourself. It seems the cdrom drive is detected by the ata related modules, but can't be properly initialized.

There is a simple workaround that supports the idea that the ata related modules are to blame. If you remove all the ata and scsi modules and then load the ide_generic module, you can Alt+F1 back to the installer and complete the installation normally.
# ls /dev/hdc
ls: /dev/hdc: No such file or directory.
# modprobe -r ata_generic ata_piix libata sg sd_mod scsi_mod
# modprobe ide_generic
# ls /dev/hdc
/dev/hdc

A permanent fix might involve ensuring that the module ide_generic is loaded before the module libata, or just treating this as an upstream bug in the kernel's ata modules. I really think this should be fixed before the 7.04 final release, though.

[Benjamin Kay (benkay)]

It appears that this bug vanishes if qemu-0.9.0 is used. In light of this, perhaps we should just encourage users to use the newer version of qemu.

[Colin Watson (cjwatson)]

Device detection here is largely handled by the kernel. Reassigning.

[Soren Hansen (soren)]

Confirmed. Assigning to kernel team.

[Soren Hansen (soren)]

I still have this problem with 0.9.0, by the way.

[Ben Collins (ben-collins)]

Seems PIIX doesn't like ata_piix as a driver. Using ata_generic (with all_generic_ide=1 option) or using piix makes things work properly. So the end result is I have moved support for PIIX chipsets back to the IDE piix.ko module. ata_piix will continue to handle the sata chipsets.

[Stanislaw Pitucha (viraptor-gmail)]

Reopen please (probably).

Before last update everything worked fine for me (ide disk as /dev/sda*) on:
00:1f.1 IDE interface: Intel Corporation 82801DBM (ICH4-M) IDE Controller (rev 03)

After kernel update disk doesn't work when booting up:
[ 4.240000] ata_piix 0000:00:1f.1: version 2.10ac1
[ 4.240000] PCI: Enabling device 0000:00:1f.1 (0005 -> 0007)
[ 4.244000] ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 19
[ 4.244000] PCI: Setting latency timer of device 0000:00:1f.1 to 64
[ 4.244000] ata1: PATA max UDMA/100 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x0001ffa0 irq 14
[ 4.244000] ata2: PATA max UDMA/100 cmd 0x00010170 ctl 0x00010376 bmdma 0x0001ffa8 irq 15
[ 4.244000] scsi0 : ata_piix
[ 4.408000] ata1.00: ata_hpa_resize 1: sectors = 117304992, hpa_sectors = 16641696
[ 4.408000] ata1.00: ATA-7: SAMSUNG MP0603H, UD100-19, max UDMA/100
[ 4.408000] ata1.00: 117304992 sectors, multi 16: LBA48
[ 4.416000] ata1.00: n_sectors mismatch 117304992 != 18446744072098803360
[ 4.416000] ata1.00: revalidation failed (errno=-19)
[ 4.416000] ata1.00: limiting speed to UDMA/100:PIO3
[ 4.416000] ata1: failed to recover some devices, retrying in 5 secs
[ 5.512000] ieee1394: Host added: ID:BUS[0-00:1023] GUID[0003252130005814]
[ 9.592000] ata1.00: ata_hpa_resize 1: sectors = 117304992, hpa_sectors = 117304992
[ 9.608000] ata1.00: n_sectors mismatch 117304992 != 18446744072098803360
[ 9.608000] ata1.00: revalidation failed (errno=-19)
[ 9.608000] ata1.00: disabled
[ 10.112000] scsi1 : ata_piix
[ 10.432000] ata2.00: ATAPI, max UDMA/33
[ 10.600000] ata2.00: configured for UDMA/33
[ 10.600000] scsi 1:0:0:0: CD-ROM HL-DT-ST DVD-RW GWA-4040N 1.02 PQ: 0 ANSI: 5

Cdrom was found though and worked.
Removing all ata modules and loading manually piix and ide_generic allowed my box to boot.
Not all libata modules could be removed though - current situation (lsmod fragment):
scsi_mod 142348 3 sbp2,libata,sr_mod
piix 10756 0 [permanent]
ide_generic 2304 0 [permanent]
ata_generic 9092 0
ata_piix 15492 0
libata 125464 2 ata_generic,ata_piix
ide_disk 17024 3
ide_cd 32672 0

[Dmitry Ivanov (vonami)]

I can confirm this. After update to 2.6.20-14.23 dmesg looks as Stanislaw Pitucha wrote above.
But the previous kernel 2.6.20-14.22 also doesn't work for me (bug #105424).

The controller is
00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 01)

[Ben Collins (ben-collins)]

Available in 2.6.20-15.25

[yeti (utu)]

Neither 2.6.20-15.25 or -15.27 this solve problem for ICH5 and actual (as opposed to virtual) IDE cdrw.

Maybe there's a resource conflict you can work around.
Here's what I get for for 'dmesg | grep quirk' at the command line:
[ 21.438490] PCI quirk: region 1000-107f claimed by ICH4 ACPI/GPIO/TCO
[ 21.438494] PCI quirk: region 1080-10bf claimed by ICH4 GPIO