Bug 496298

Summary: F11 Beta :: under KVM anaconda detect cdrom media because udev doesn't probe for filesystem type
Product: [Fedora] Fedora Reporter: Mark McLoughlin <markmc>
Component: udevAssignee: Harald Hoyer <harald>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: dlehman, duck, harald, katzj, mike.hinz, notting, pjones, rmaximo, rpjday, vanmeeuwen+fedora, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: NeedsRetesting
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-05-18 10:36:42 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 480593    
Attachments:
Description Flags
2009-04-17-baremetal-anaconda-dvd-install.log
none
2009-04-17-kvm-anaconda-dvd-install.log
none
anaconda log from Fedora 11 beta - installed on Fedora 11 beta VM - KVM based
none
storage log from Fedora 11 beta installed in a VM on a Fedora 11 physical machine - KVM based
none
As requested - output of udevadm on a VM that exhibited the issue none

Description Mark McLoughlin 2009-04-17 12:43:40 EDT
Created attachment 340044 [details]
2009-04-17-baremetal-anaconda-dvd-install.log

Install a KVM guest with:

  $> virt-install -n f11-beta-dvd -r 1024 \
        --vcpus=2 --os-variant=fedora11 -v --accelerate \
        -c /var/lib/libvirt/images/iso/Fedora-11-Beta-x86_64-DVD.iso \
        --disk pool=default,size=8 -w network:default --debug

(I also added "vnc console=ttyS0" to the command line args)

When you get to the repository selection screen, there is only the rawhide repo available, the installation repo isn't available.

(Note - stage2 is being loaded from the DVD)

Installed on a physical machine to compare, and sure enough both the installation repo and the rawhide repo is available.

Attaching both logs.

Main difference I see is on the physical machine you see:

16:11:58 DEBUG   : OpticalDevice._setFormat: sr0 ; current: None ; type: None ;
16:11:58 DEBUG   : isys.py:mount()- going to mount /dev/sr0 on /tmp/getsize-B7stcv with options ro
16:11:58 DEBUG   : OpticalDevice._setFormat: sr0 ; current: None ; type: iso9660 ;
...
17:15:08 INFO    : moving (1) to step reposetup
17:15:08 DEBUG   : isys.py:mount()- going to mount /dev/sr0 on /mnt/source with options ro
17:15:09 INFO    : found installation media on sr0
17:15:10 INFO    : set mediaid of repo InstallationRepo to: 1238017014.113790
17:15:13 INFO    : no groups missing
17:15:13 INFO    : moving (1) to step tasksel

whereas under KVM:

14:21:09 DEBUG   : OpticalDevice._setFormat: sr0 ; current: None ; type: None ;
...
15:22:00 INFO    : moving (1) to step reposetup
15:22:34 INFO    : no groups missing
15:22:34 INFO    : moving (1) to step tasksel
Comment 1 Mark McLoughlin 2009-04-17 12:44:42 EDT
Created attachment 340045 [details]
2009-04-17-kvm-anaconda-dvd-install.log
Comment 2 Mike Hinz 2009-04-17 14:33:48 EDT
Created attachment 340062 [details]
anaconda log from Fedora 11 beta - installed on Fedora 11 beta VM - KVM based
Comment 3 Mike Hinz 2009-04-17 14:35:32 EDT
Created attachment 340064 [details]
storage log from Fedora 11 beta installed in a VM on a Fedora 11 physical machine - KVM based
Comment 4 Mike Hinz 2009-04-17 14:38:31 EDT
I can verify exactly same behaviour as Mark M describes.  When attempting to install Fedora 11 beta on a VM on a Fedora 11 based VM (KVM), the installer uses the network for installation versus the available DVD.  This same scenario works correctly on actual physical hardware.
Comment 5 David Lehman 2009-04-21 13:35:30 EDT
Can one of you please capture the output of 'udevadm info --query=all --name=sr0' from one of the machines at or around the time of the failure and attach it to this bug report?
Comment 6 Mike Hinz 2009-04-21 14:59:04 EDT
Created attachment 340609 [details]
As requested - output of udevadm on a VM that exhibited the issue

I've taken this from a VM created a few days ago, but that's had very little activity on it since.  Hopefully this gives you the info you need.
Comment 7 Mike Hinz 2009-04-21 15:01:16 EDT
Please let me know if the attachment that I just posted is sufficient.  If not, I can build another VM and immediately do this command after its creation.  FYI.
Comment 8 David Lehman 2009-04-21 15:04:12 EDT
I need the command to be run from the shell on tty2 during installation, with the DVD media in the drawer. It seems that either udev or anaconda is unable to detect the install media on the DVD.
Comment 9 Robert P. J. Day 2009-04-21 15:17:17 EDT
Not to drag this off-topic, but are you implying that you can't reproduce this at Red Hat?  I find it hard to believe that only a few of us have been having this problem, while it works fine for everyone else.
Comment 10 David Lehman 2009-04-21 16:00:45 EDT
I'm not trying to imply anything. Since you already have a reproducer set up I'd just assume have you collect some information instead of having me spend however many hours it would take to set up kvm, download and burn a dvd, &c. In the meantime I can work on other bugs for which I already have a reproducer set up.
Comment 11 Mark McLoughlin 2009-04-22 06:32:26 EDT
thanks for the prod in the right direction Dave.

$> udevadm info --query=all --name=sr0
P: /devices/pci0000:00/0000:00:01.1/host1/target1:0:0/1:0:0:0/block/sr0
N: sr0
S: block/11:0
S: scd0
S: disk/by-path/pci-0000:00:01.1-scsi-1:0:0:0
E: UDEV_LOG=3
E: DEVPATH=/devices/pci0000:00/0000:00:01.1/host1/target1:0:0/1:0:0:0/block/sr0
E: MAJOR=11
E: MINOR=0
E: DEVTYPE=disk
E: DEVNAME=/dev/sr0
E: ID_CDROM=1
E: ID_CDROM_MRW=1
E: ID_CDROM_MRW_W=1
E: ID_CDROM_MEDIA_DVD=1
E: ID_CDROM_MEDIA_STATE=blank
E: ID_CDROM_MEDIA_SESSION_NEXT=16384
E: ID_CDROM_MEDIA_SESSION_COUNT=2816
E: ID_CDROM_MEDIA_TRACK_COUNT_DATA=1
E: ID_VENDOR=QEMU
E: ID_VENDOR_ENC=QEMU\x20\x20\x20\x20
E: ID_MODEL=QEMU_DVD-ROM
E: ID_MODEL_ENC=QEMU\x20DVD-ROM\x20\x20\x20\x20
E: ID_REVISION=0.10
E: ID_TYPE=cd
E: ID_BUS=scsi
E: ID_PATH=pci-0000:00:01.1-scsi-1:0:0:0
E: ANACBIN=/usr/sbin
E: DEVLINKS=/dev/block/11:0 /dev/scd0 /dev/disk/by-path/pci-0000:00:01.1-scsi-1:0:0:0

This differs quite a bit from baremetal:

  - No ID_FS_TYPE=iso9660

  - ID_CDROM_MEDIA_STATE=blank rather than ID_CDROM_MEDIA_STATE=complete

  - No ID_CDROM_MEDIA_TRACK_COUNT

Now, interestingly:

$> /lib/udev/vol_id /dev/sr0
ID_FS_USAGE=filesystem
ID_FS_TYPE=iso9660
ID_FS_VERSION=
ID_FS_UUID=
ID_FS_UUID_ENC=
ID_FS_LABEL=Fedora_11-Beta_x86_64_DVD
ID_FS_LABEL_ENC=Fedora\x2011-Beta\x20x86_64\x20DVD

So, the problem appears to be that vol_id isn't being run because of this rule:

# probe filesystem metadata of optical drives which have a media inserted
KERNEL=="sr*", ENV{ID_CDROM_MEDIA_TRACK_COUNT}=="?*", IMPORT{program}="vol_id --export --skip-raid --offset=$env{ID_CDROM_MEDIA_SESSION_LAST_OFFSET} $tempnode"

i.e. vol_id isn't being run because there is no ID_CDROM_MEDIA_TRACK_COUNT

Now, the root cause of all this is that qemu doesn't implement GPCMD_READ_DISC_INFO, so perhaps we should implement that. However, we'd still be broken on older qemu/KVM, Xen and others.

Should anaconda run vol_id for cdrom devices in its own rules? Or should the default udev rules should be modified?

I tried adding:

  KERNEL=="sr*", IMPORT{program}="vol_id --export $tempnode"

to 70-anaconda.rules and it fixed the problem
Comment 12 Jeremy Katz 2009-04-22 16:10:13 EDT
(In reply to comment #11)
> thanks for the prod in the right direction Dave.
[snip]
> i.e. vol_id isn't being run because there is no ID_CDROM_MEDIA_TRACK_COUNT
> 
> Now, the root cause of all this is that qemu doesn't implement
> GPCMD_READ_DISC_INFO, so perhaps we should implement that. However, we'd still
> be broken on older qemu/KVM, Xen and others.
> 
> Should anaconda run vol_id for cdrom devices in its own rules? Or should the
> default udev rules should be modified?

The default answer is that the default udev rules should be modified if we can at all help it.  Anything in anaconda is just going to be a short-term hack that isn't expected to last.  Reassigning to udev accordingly
Comment 13 Harald Hoyer 2009-04-23 09:18:21 EDT
which version of udev is this?
Comment 14 Harald Hoyer 2009-04-23 09:21:00 EDT
IIRC, there were problems with other devices, so the rule was refined.
Comment 15 Mark McLoughlin 2009-04-23 09:52:49 EDT
udev-139-2.fc11

This commit fixes the problem:

  http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=f907449eee

Running with that commit under qemu, I get:

$> ./cdrom_id --debug /dev/sr0
main: probing: '/dev/sr0'
cd_inquiry: INQUIRY: [QEMU    ][QEMU DVD-ROM    ][0.10]
cd_profiles: GET CONFIGURATION: number of profiles 20
cd_profiles: current profile 0x10
cd_media_toc: READ TOC: len: 20
cd_media_toc: track=1 info=0x4(data) start_block=0
cd_media_toc: last track 1 starts at block 0
cd_media_info: disk type 0c
ID_CDROM=1
ID_CDROM_MRW=1
ID_CDROM_MRW_W=1
ID_CDROM_MEDIA=1
ID_CDROM_MEDIA_DVD=1
ID_CDROM_MEDIA_STATE=appendable
ID_CDROM_MEDIA_TRACK_COUNT_DATA=1
Comment 17 Harald Hoyer 2009-04-24 09:42:31 EDT
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/1629>
Comment 18 Chris Lumens 2009-05-06 11:53:17 EDT
Well there are two problems that are still preventing this from working.  First, anaconda's not setting up the format correctly in the new storage code.  However in order for anaconda to be able to do that, we need ID_FS_TYPE in the udev info being returned for sr0.  I'll work on the anaconda end if you can work on the udev end.
Comment 19 Harald Hoyer 2009-05-07 04:06:29 EDT
KERNEL=="sr*", ENV{ID_CDROM_MEDIA}=="?*", IMPORT{program}="vol_id --export --skip-raid --offset=$env{ID_CDROM_MEDIA_SESSION_LAST_OFFSET} $tempnode"

from /lib/udev/rules.d/60-persistent-storage.rules should return ID_FS_TYPE

what else do you need?
Comment 20 Chris Lumens 2009-05-12 16:58:06 EDT
Looking at anaconda's storage.log today, I see that sr0 has ID_FS_TYPE=iso9660 and that we detect things based on that correctly.  I'm not sure what all has changed here but it looks like it should be working now.  We'll need to give it a try with the next tree containing DVD media just to be hsure.
Comment 21 Bill Nottingham 2009-05-15 15:15:30 EDT
Setting NeedsRetesting, setting to MODIFIED.
Comment 22 Jeremy Katz 2009-05-18 10:36:42 EDT
Tested with boot.iso and we were able to mount and use it fine, so this looks good now
Comment 23 Mark McLoughlin 2009-05-26 10:19:01 EDT
Just tested with rc0.1 and it seems to work fine now