Bug 496298 - F11 Beta :: under KVM anaconda detect cdrom media because udev doesn't probe for filesystem type
F11 Beta :: under KVM anaconda detect cdrom media because udev doesn't probe ...
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: udev (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Harald Hoyer
Fedora Extras Quality Assurance
NeedsRetesting
:
Depends On:
Blocks: F11VirtBlocker
  Show dependency treegraph
 
Reported: 2009-04-17 12:43 EDT by Mark McLoughlin
Modified: 2009-05-26 10:19 EDT (History)
11 users (show)

See Also:
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:
Cloudforms Team: ---


Attachments (Terms of Use)
2009-04-17-baremetal-anaconda-dvd-install.log (46.29 KB, text/plain)
2009-04-17 12:43 EDT, Mark McLoughlin
no flags Details
2009-04-17-kvm-anaconda-dvd-install.log (31.93 KB, text/plain)
2009-04-17 12:44 EDT, Mark McLoughlin
no flags Details
anaconda log from Fedora 11 beta - installed on Fedora 11 beta VM - KVM based (31.87 KB, text/plain)
2009-04-17 14:33 EDT, Mike Hinz
no flags Details
storage log from Fedora 11 beta installed in a VM on a Fedora 11 physical machine - KVM based (50.45 KB, text/plain)
2009-04-17 14:35 EDT, Mike Hinz
no flags Details
As requested - output of udevadm on a VM that exhibited the issue (708 bytes, text/plain)
2009-04-21 14:59 EDT, Mike Hinz
no flags Details

  None (edit)
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

Note You need to log in before you can comment on or make changes to this bug.