gutsy install cd (alternate or desktop) will not detect cdrom within qemu

Seen here too. Looks like a kernel regression.

Relevant debug messages (all prefixed with "ata2.00: ":
ATAPI, may MWDA1
configured for MWDA1
exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
(BMDMA stat 0x5)
cmd a0/01:00:00:00:00/00:00:00:00:00/a0 tag 0 cdb 0x12 data 36 in
res 48/01:02:00:00:00/00:00:00:00:00/a0 Emask 0x2 (HSM violation)
ata2: soft resetting port
(repeat three times)

qemu works with Debian Etch, so I'm assigning this to the kernel people for further investigation.

Same here with daily build for 20070625.

I just tried the Tribe 2 release (alternate) and I still have the same issue. Any info you need on hardware, logs, etc please let me know. I'd very much like to get this resolved so I can test Gutsy.

Same here with gutsy (alternate and desktop cds). I see the previously mentioned kernel messages (BMDMA) with gutsy-alternate cd.

feisty-desktop seems to find the cd and load full (the progress bar), but fails after that. It switches to text mode and I see a lot of SQUASHFS errors and it finally fails with: "User not known to the underlying authentication module" printed 10 times.

This is on IBM T42p.

- Naveen

I can boot gutsy-desktop-i386.iso (Tribe2) with QEMU if I do the following:

In the boot menu
 1. Push F6 ( Other Options)
 2. remove: "quiet splash --"
 3. add: "break=top"
 4. Push Enter

Later when you see "/bin/sh: can't access tty; job control turned off"

type the following:
 modprobe ide-generic
 exit

...Start from CD image continues :-)

Note: I have not tried alternate yet.

For gutsy-alternate-i386.iso (Tribe2)

In the boot menu
 1. Push F6 ( Other Options)
 2. remove: "quiet --"
 3. add: "ata_piix.blacklist=yes"
 4. Push Enter

The installer will now work fine in QEMU.

Verified. This fix works for me as well using gutsy-alternate-i386.iso Tribe 2 release for installation in (k)qemu.

Verified. The above technique works with gutsy-desktop and gutsy-alternate Tribe 2.

I know this probably doesn't belong here, but has anyone had success with feisty installation in (k)qemu? The above technique seems to allow it to continue, but it throws up a lot of "SQUASHFS error: sb_bread failed reading block 0xxxx" and "/usr/bin/expr: Syntax Error" for scripts. It finally stops/hangs after "Running local boot scripts"

- Naveen

FYI: I have filed a bug report on the Debian QEMU package:
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=431829

I recently installed Kubuntu 7.04 aka Feisty (standard edition) in
Qemu to then upgrade to Gutsy without any problem.

Bug in OpenSuSE too with possible QEMU fix.

https://bugzilla.novell.com/show_bug.cgi?id=291775

I downloaded Qemu+Kqemu source from the Qemu webpage.

I applied the patch philips pointed out:
  https://bugzilla.novell.com/show_bug.cgi?id=291775
The actual patch:
  https://bugzilla.novell.com/attachment.cgi?id=158316&action=edit
The guest OS successfully detects the QEMU-CDROM now.

The guest kernel doesn't panic anymore when I use kqemu. I don't know if the resolution was compiling with GCC3.4, or if there was a change in the source I downloaded.

Host system:
  Celeron 1.3GHz w/ 1Gb RAM (D201GLY mini-itx motherboard)
  Linux 2.6.22-12-server #1 SMP Sun Sep 23 18:45:59 GMT 2007 i686 GNU/Linux
  gcc-3.4 (GCC) 3.4.6 (Ubuntu 3.4.6-6ubuntu2)

Qemu source:
  qemu-0.9.0.tar.gz
  kqemu-1.3.0pre11.tar.gz

Guest OS:
  Ubuntu gutsy install CD
  Debian Etch install CD
  Ubuntu gutsy

-Bryan

IMHO the following bugs might be related :
https://bugs.launchpad.net/ubuntu-jeos/+bug/163113
https://bugs.launchpad.net/ubuntu/+bug/163140
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/120316
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.15/+bug/33269

This bug affects JeOS too. Should I report it as a seperate bug against JeOS ?

I used the ISO with MD5(ubuntu-7.10-jeos-i386.iso)= 341ca65a187c71643079a2f9ee5523b5 to create an image from it.

I created the image like this :
qemu-img create -f qcow jeos.img 10G
qemu -m 512 -cdrom ubuntu-7.10-jeos-i386.iso -boot d jeos.img -no-acpi -std-vga
I needed this workaround to create the QEMU image : https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/120316/comments/7

I don't know if it should be reported as a seperate bugreport for JeOS, but
if it uses Ubuntu's repo's then it will likely be fixed as soon as Ubuntu's
bug is.

I'm rather curious a to what is causing this bug.
Any ideas?

On Nov 20, 2007 12:38 PM, ubuntu_demon <email address hidden> wrote:

> This bug affects JeOS too. Should I report it as a seperate bug against
> JeOS ?
>
> I used the ISO with MD5(ubuntu-7.10-jeos-i386.iso)=
> 341ca65a187c71643079a2f9ee5523b5 to create an image from it.
>
> I created the image like this :
> qemu-img create -f qcow jeos.img 10G
> qemu -m 512 -cdrom ubuntu-7.10-jeos-i386.iso -boot d jeos.img -no-acpi
> -std-vga
> I needed this workaround to create the QEMU image :
> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/120316/comments/7
>
> --
> gutsy install cd (alternate or desktop) will not detect cdrom within qemu
> https://bugs.launchpad.net/bugs/120316
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

I don't know if it should be reported as a seperate bugreport for JeOS, but if it uses Ubuntu's repo's then it will likely be fixed as soon as Ubuntu's bug is.

I'm rather curious a to what is causing this bug.
Any ideas?

The qemu (+ bochsbios-qemu) package seems to work for me, on a system otherwise running pure gutsy.

The Hardy Heron Alpha series was recently released. Alpha2 and subsequent releases contain an updated version of the kernel. You can download and try the new Hardy Heron Alpha release from http://cdimage.ubuntu.com/releases/hardy/ . Please note that Alpha3 will be released within the next day or two so you may want to wait. If you can, please verify if this bug still exists or not and report back your results. General information regarding the release can also be found here: http://www.ubuntu.com/testing/ .

A new task against the actively developed kernel has been opened and the task against linux-source-2.6.22 is being closed. Thanks!

What is the bug number for the new updated task?

It's the same bug report, you'll just see that in the info table at the top of this report a "linux" task has been opened and the "linux-source-2.6.22" task has been closed. Thanks.

I'm seeing this problem trying to install from ubuntu-8.04-beta-server-i386.iso on qemu. I also have ata_PIIX drives. Trying the two fixes mentioned above (adding ata_piix to the blacklist and break=top) did not help. break=top actually appears to have stopped me earlier in the process of installing. I'm not able to choose a language because it won't respond to my keyboard and mouse.

Anyone have another idea for a workaround until this gets fixed? I'd like to do some package testing, but need a clean system. :-)

What makes this bug incomplete rather than confirmed? I'd be glad to gather up some information if it is still incomplete, but it seems like this should be marked confirmed.

I'm using the Hardy RC now, and tried the Hardy live disc on my installed Hardy host. Works as it should now here.

Hi Christer,

Since you are the original bug reporter, can you confirm this is resolved for you with Hardy final?

Appears to be working with hardy final, yes.

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.