Bug 609049

Additional note: This only fail with IDE cd-rom, SCSI cd-rom works OK

With "-drive file=xyz.iso,if=scsi,media=cdrom" works fine, but with "-drive file=xyz.iso,if=ide,media=cdrom" (or directly -cdrom) fails.

*** Bug 608918 has been marked as a duplicate of this bug. ***

Any news here? This still occurs here with an image from today. 

Sadly, I don't see any easy way to get libvirt to use a scsi instead of IDE cdrom, so it's anoying to work around.

Live images also doesn't boot in vmware and from USB created with livecd-iso-to-disk on real hardware.

(In reply to comment #4)
> Live images also doesn't boot in vmware and from USB created with
> livecd-iso-to-disk on real hardware.    

https://bugzilla.redhat.com/show_bug.cgi?id=613213

*** Bug 618517 has been marked as a duplicate of this bug. ***

This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle.
Changing version to '14'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Any news at all here? 

Not being able to boot live media here makes testing a pain. ;( 

Hopefully we have the other issues fixed now (livecd-tools fix to find syslinux files in the right place so you don't get a black screen on boot and squashfs corruption that would result in no root found). 

So, any news on this? Do we even know what version(s) of qemu are affected?

A quick workaround would be to have libvirt/virt-manager add code to attach CD drives on the scsi bus.

I'm doubtful this is related to the read disc info command, as even the scsi implementation doesn't emulate that cmd. It could be something totally different in qemu code that hasn't been exposed so far.

Can anyone point me to changes in the livecd creator tools that I might go through to identify what could've caused this?

Also, can someone try creating a livecd from older (F13) livecd creator tools to verify this is really some change in the livecd creator tools causing this regression?

Thanks

I believe the cdrom_id code is what you want to check into.
The reporter reports that cdrom_id doesn't read things correctly, or come up with the correct data, cdrom_id is in udev in /lib/udev/cdrom_id

(In reply to comment #8)
> Any news at all here? 
> 
> Not being able to boot live media here makes testing a pain. ;( 
> 
> Hopefully we have the other issues fixed now (livecd-tools fix to find syslinux
> files in the right place so you don't get a black screen on boot and squashfs
> corruption that would result in no root found). 
> 
> So, any news on this? Do we even know what version(s) of qemu are affected?    

but you can boot and test with: -drive file=xyz.iso,if=scsi,media=cdrom

In reply to Comment 11
Apparently you can't use Qemu like that, here is a screenshot:
http://autopsy.liveprojects.info/external/extra/qemu-broke.png

qemu -drive testing.iso,if=scsi,media=cdrom does not work as advertised.

Same thing with 
qemu -drive file=testing.iso,if=scsi,media=cdrom
http://autopsy.liveprojects.info/external/extra/qemu-broke1.png

Using this with Qemu DOES work here:
qemu -drive file=testing.iso,if=ide,media=cdrom


http://autopsy.liveprojects.info/external/extra/qemu-works.png

You have to use if=ide not if=scsi apparently.
Still Qemu is broken in regards to the SCSI command.

Is that any different from "-boot d -cdrom test.iso"?

Anyway still doesn't help to boot Fedora 14 Live, AFAICT.

Right, it seems the F14 Live spins won't boot in qemu, of any version because it doesn't implement these calls, which come from cdrom_id and which is in udev
WHICH is needed to get information about the drive.

Even using if=ide on the F14 live images fails after cdrom_id is called in the initramfs's udev sections.

These F14 live spins are what alot of people use in Qemu also do to thier testing, so this needs to be filed upstream if it is in fact a Qemu issue.
http://wiki.qemu.org/Main_Page

Without any further ado, I have decided to go ahead and file this upstream:
https://bugs.launchpad.net/qemu/+bug/612901

(In reply to comment #9)
> A quick workaround would be to have libvirt/virt-manager add code to attach CD
> drives on the scsi bus.

Yeah. 

> I'm doubtful this is related to the read disc info command, as even the scsi
> implementation doesn't emulate that cmd. It could be something totally
> different in qemu code that hasn't been exposed so far.
> 
> Can anyone point me to changes in the livecd creator tools that I might go
> through to identify what could've caused this?

http://git.fedorahosted.org/git/?p=livecd;a=summary
 
> Also, can someone try creating a livecd from older (F13) livecd creator tools
> to verify this is really some change in the livecd creator tools causing this
> regression?

I can try and do this today...

(In reply to comment #9)
> Also, can someone try creating a livecd from older (F13) livecd creator tools
> to verify this is really some change in the livecd creator tools causing this
> regression?

I am pretty sure this is the case: F13 spins boot fine but not F14.
So the changes are in the F14 tree not livecd-tools.

Adding F14Beta blocker.

https://fedoraproject.org/wiki/Fedora_14_Beta_Release_Criteria

12. The release must boot successfully as a virtual guest in a situation where the virtual host is running the same release (using Fedora's current preferred virtualization technology)
13. The release must boot successfully as a virtual guest in a situation where the virtual host is running the previous stable Fedora release (using Fedora's current preferred virtualization technology)

I just tried the F14-TC2 x86_64 cd and that boots fine upto Anaconda.

That rules out guest kernel issues.

What we have remaining then is the livecd-creator tools or some new instructions being used which the kvm emulator gets confused about.

Acc. to comment 19, this could be a syslinux issue (or, again, host kvm emulator issue).

In reply to Comment 21
I believe the problem we're seeing this with is the Live RAWHIDE spins.
From herE: http://alt.fedoraproject.org/pub/alt/nightly-composes/

In reply to comment 21
From what I can tell teh initrd.img doesn't use dracut initramfs and although /lib/udev/cdrom_id is in the initrd it isn't used apparently.

This maybe why the Live images don't work in Qemu but the install media does.
You might look at /sbin/init and /sbin/loader source code to see how it handles things differently than using dracut initramfs and how it uses cdrom_id to find out information about the CDROM drive and discs.

This could actually be due to Bug 617115.

Nope. The latest nightlys have a livecd-tools that has the fix for that bug, it's not that. 

syslinux comes up, the kernel starts booting, then it dies with cannot find rootfs. ;( 

Perhaps we could run thru another round of dracut testing to isolate it more?

I think there are only two solutions here, well 3 if you count the unacceptable one:

1) Don't use Qemu
2) Implement the SCSI command haraldh has described is not implemented in Qemu
3) Break open an initramfs, try to work around uding cdrom_id to find information about the drive discs, or make it use some other implemented command.

When was the last time udev was updated that caused this to happen all of a sudden?

From my F13 updated box, I see this:
What about for F14 udev?

* Tue Apr 27 2010 Harald Hoyer <harald> 151-9
- more cdrom_id bugfixes to prevent autoclosing

* Tue Apr 13 2010 Harald Hoyer <harald> 151-8
- more cdrom_id bugfixes for buggy cdroms and CD burning
  (bug #577659)
https://bugzilla.redhat.com/show_bug.cgi?id=577659

I have yet to see the relevance though of this Qemu bug, and livecds having to do with livecd-tools. Just a really good feeling it has not much to do with livecd-tools whatsoever.

Harold, I'm just curious if there would be reason to work around this issue, until Qemu implements this command by not failing when READ_DISC_INFORMATION doesn'tr return with anything valid.

Currently it breaks in any emulation software which doesn't implements this, and this is of course Qemu so we know it wouldn't fail on real hardware.

Is there any way to be less aggressive about returning this specific command information back to udev? What is it used for?

I think READ_DISC_INFORMATION is supposed to return with a 16 byte value, what does it normally return when there is a disc in the drive, which structures?


Is there any work around to this?

(In reply to comment #27)
> From my F13 updated box, I see this:
> What about for F14 udev?
> 
> * Tue Apr 27 2010 Harald Hoyer <harald> 151-9
> - more cdrom_id bugfixes to prevent autoclosing
> 
> * Tue Apr 13 2010 Harald Hoyer <harald> 151-8
> - more cdrom_id bugfixes for buggy cdroms and CD burning
>   (bug #577659)
> https://bugzilla.redhat.com/show_bug.cgi?id=577659
> 
> I have yet to see the relevance though of this Qemu bug, and livecds having to
> do with livecd-tools. Just a really good feeling it has not much to do with
> livecd-tools whatsoever.    

These fixes are already in F14.. I just backported some fixes to the F13 udev-151 version.

This works fine for me:

# qemu-kvm -drive file=Fedora-13-i686-Live.iso,if=scsi,media=cdrom,boot=on

Is that what virt-manager uses by default in this situation?  Or am I asking the wrong question here?

Created attachment 437185 [details]
desktop-i386-20100805.20.iso boots fine

$ sudo qemu-kvm -m 512M -drive file=~/Download/desktop-i386-20100805.20.iso,if=scsi,media=cdrom,boot=on

$ rpm -qf $(which qemu-kvm)
qemu-system-x86-0.13.0-0.2.20100727gitb81fe95.fc14.x86_64

Hmm, I wonder why that worked...

# /lib/udev/cdrom_id -d /dev/sr0
main: probing: '/dev/sr0'
cd_media_compat: CDROM_DRIVE_STATUS != CDS_DISC_OK
cd_inquiry: INQUIRY: [QEMU    ][QEMU DVD-ROM    ][0.12]
cd_profiles: GET CONFIGURATION: size of features buffer 0x0010
cd_profiles: GET CONFIGURATION: feature 'profiles', with 2 entries
feature_profiles: profile 0x10 dvd_rom
feature_profiles: profile 0x08 cd_rom
cd_profiles: no current profile, assuming no media
ID_CDROM=1
ID_CDROM_CD=1
ID_CDROM_DVD=1
ID_CDROM_MRW=1
ID_CDROM_MRW_W=1

*** Bug 621102 has been marked as a duplicate of this bug. ***

note 621102 dupe: this also has the effect of causing DVD installs to not find the DVD and turn into network installs instead. This is accepted as a beta blocker: "The release must boot successfully as a virtual guest in a situation where the virtual host is running the same release (using Fedora's current preferred virtualization technology)".

udev-160-9.fc14 has been submitted as an update for Fedora 14.
http://admin.fedoraproject.org/updates/udev-160-9.fc14

with udev-160-9.fc14, things should work as expected with "-cdrom". Added a quirk.

(In reply to comment #38)
> with udev-160-9.fc14, things should work as expected with "-cdrom". Added a
> quirk.    

This will not work with multiple sessions and multiple tracks, though.

A correct implementation would really be cool.

am about to do a local live compose to test this.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

this looks good: the test live compose booted. previous live composes didn't.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

OK, in the meantime I've reproduced on F13 hosts using the latest compose (with 
udev-160-8.fc14).

The workaround for booting such livecds in F13 host, using virt-install, is:
virt-install --name <name> -r <ram> --vcpus=<> --os-type=linux
--os-variant=fedora13 --import --disk path=/path/to/f14.iso,bus=scsi,format=iso
--disk path=/path/to/drive.img,sparse=true,size=10,bus=virtio,cache=writeback
-b br1 --vnc --accelerate 

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

udev-160-9.fc14 has been pushed to the Fedora 14 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update udev'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/udev-160-9.fc14

udev-160-9.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.

Verified media package repo selected automatically during F14-Alpha-rc3-i386-DVD.iso virt-install.

Comment 45 means to say that this bug was also causing DVD media repo, to not be able to find the CDROM and ends up doing a network install instead.

Apparently that is what he means, that the QEMU bug has been worked around.

udev-161-1.fc14 has been submitted as an update for Fedora 14.
http://admin.fedoraproject.org/updates/udev-161-1.fc14

udev-161-1.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.