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
Created attachment 340045 [details] 2009-04-17-kvm-anaconda-dvd-install.log
Created attachment 340062 [details] anaconda log from Fedora 11 beta - installed on Fedora 11 beta VM - KVM based
Created attachment 340064 [details] storage log from Fedora 11 beta installed in a VM on a Fedora 11 physical machine - KVM based
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.
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?
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.
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.
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.
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.
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.
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
(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
which version of udev is this?
IIRC, there were problems with other devices, so the rule was refined.
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
https://koji.fedoraproject.org/koji/buildinfo?buildID=99462
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/1629>
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.
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?
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.
Setting NeedsRetesting, setting to MODIFIED.
Tested with boot.iso and we were able to mount and use it fine, so this looks good now
Just tested with rc0.1 and it seems to work fine now