Retitled BZ for clarity.

dracut-024-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/dracut-024-1.fc18

Package dracut-024-1.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing dracut-024-1.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-16223/dracut-024-1.fc18
then log in and leave karma (feedback).

Is the update available in a new ISO? Thanks.

(In reply to comment #4)
> Is the update available in a new ISO? Thanks.

not yet.. it's still in "testing" ... test and give KARMA

Unfortunately, I can't really test this without an installer ISO. The way I'd test it is described in comment #0, ie. boot the ISO in a VM, attached as virtio-scsi CD-ROM, with OVMF boot firmware.

I took now my preexistent F18 Alpha XFCE guest (which I had installed with virtio-blk) and changed the boot disk's model to virtio-scsi. After fixing the device path to "shim.efi" in the OVMF setup, the OS booted flawlessly. IOW I cannot reproduce the bug in a preexistent guest:

The dracut version the guest has installed is: dracut-023-21.git20120823.fc18. The file "/usr/lib/dracut/modules.d/90qemu/module-setup.sh" does list "virtio_scsi". The Alpha installer ISO is still attached via virtio-scsi, and "/dev/disk/by-label/Fedora-18-Alpha-x86_64-Live-XFCE" points to /dev/sr0.

Extracting "isolinux/initrd0.img" on the F18 Alpha XFCE image with gzip + cpio, the *virtio* files I find are in "usr/lib/modules/3.6.0-0.rc2.git2.1.fc18.x86_64/kernel",

drivers/block/virtio_blk.ko
drivers/net/virtio_net.ko
net/9p/9pnet_virtio.ko

That is, both the dracut program and the dracut image *installed from* the F18 Alpha XFCE ISO correctly include / have included virtio_scsi.

However the dracut program *preparing* "isolinux/initrd0.img" for the F18 Alpha XFCE ISO did not include virtio_scsi. And I can test that only with a new ISO.

Thanks!
Laszlo

Retitling bug for more clarity.

Upstream dracut commit 48ca4876 does look good -- it seems to ensure that "isolinux/initrd0.img" contain virtio_scsi, even if the ISO is built on real hardware, not inside a VM.

I could only test this myself by building an F18 Live/install ISO from within a *bare-metal* F18 installation. That's not possible unfortunately; I'll wait for the next centrally-built ISO. Thanks!

Reassigning to livecd-tools. livecd-tools tries to be smarter regarding the kernel modules than dracut.

/usr/lib/python2.7/site-packages/imgcreate/live.py specifies its own set of kernel modules via "drivers+=''" which forces dracut to use only those kernel drivers instead of the default ones.

Indeed! Another round of bug 672936 (upstream livecd commit 228f10f5) seems justified. Thanks!

Seems like a good idea. I'll also add virtio_net. Any other virtio_* modules we should put in? I'm not sure what virtio_mmio and virtio_balloon are for.

virtio_mmio is a generic "access driver" for the specific devices, it is an alternative for virtio_pci.

virtio_balloon is used for transferring RAM between host and guest, ie. resizing the guests "current allocation" betwen (0, max allocation]. Max allocation is configured at guest startup.

I wouldn't add them unless someone explicitly requests them.

virtio_net is a good idea though.

They shouldn't hurt to have available should they? I went ahead and added all the virtio* modules, including virtio-rng just for completeness.

dracut-024-5.git20121019.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/dracut-024-5.git20121019.fc18

Package dracut-024-5.git20121019.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing dracut-024-5.git20121019.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-16448/dracut-024-5.git20121019.fc18
then log in and leave karma (feedback).

Attempted to test with:

- x86_64 RHEL-6.3 host, with
  - qemu-kvm-0.12.1.2-2.313.el6.x86_64
  - python-virtinst-0.600.0-8.el6.noarch
  - libvirt-0.9.10-21.el6_3.5.x86_64
- /root/OVMF.fd built from edk2 SVN rev 13935 (see attachment)
- guest installer: Fedora-18-Nightly-20121112.11-x86_64-Live-xfce.iso
  <http://koji.fedoraproject.org/koji/taskinfo?taskID=4680300>
- install xmlstarlet from EPEL-6
- /root/bin/rhel-qemu-wrapper attached (for capturing OVMF debug output)

Create guest with virtio-scsi target disk for installation:

  NAME=fw-ovmf.g-f18xfce2012111211.e-rhel63
  EMULATOR=/root/bin/rhel-qemu-wrapper
  LOADER=/root/OVMF.fd
  IMG_DIR=/var/lib/libvirt/images
  TARGET_DISK=$IMG_DIR/$NAME.img
  INSTALL_ISO=$IMG_DIR/Fedora-18-Nightly-20121112.11-x86_64-Live-xfce.iso

  chmod -c -- u=rwx,g=rx,o= /root /root/bin "$EMULATOR"
  chmod -c -- u=rw,g=r,o= "$LOADER"
  chown -c -- root:qemu /root /root/bin "$EMULATOR" "$LOADER"
  chcon -v --reference=/usr/share/qemu-kvm/bios.bin -- "$LOADER"
  chcon -v --reference=/usr/libexec/qemu-kvm -- "$EMULATOR"
  restorecon -FvvR -- "$IMG_DIR"

  virt-install                                                             \
      --connect=qemu:///system                                             \
      --name="$NAME"                                                       \
      --ram=4096                                                           \
      --arch=x86_64                                                        \
      --machine=rhel6.3.0                                                  \
      --vcpus=4                                                            \
      --boot=cdrom,hd                                                      \
      --disk=path="$TARGET_DISK",size=10,bus=scsi,format=qcow2             \
      --disk=path="$INSTALL_ISO",device=cdrom,bus=scsi,perms=ro,format=raw \
      --os-type=linux                                                      \
      --os-variant=fedora16                                                \
      --print-step=1                                                       \
  | xmlstarlet ed                                                          \
      -u /domain/devices/emulator                         -v "$EMULATOR"   \
      -s /domain/os                 -t elem -n loader     -v "$LOADER"     \
      -s /domain/devices            -t elem -n controller -v ''            \
      -s /domain/devices/controller -t attr -n type       -v scsi          \
      -s /domain/devices/controller -t attr -n model      -v virtio-scsi   \
      >template.xml

  virsh define template.xml

  rm template.xml

Start guest from virt-manager.

--------

Unfortunately, the installation fails the same way as described in comment 0. The virtio-scsi module is absent from /proc/modules, checked from the emergency shell.

Again, I loop-mounted "Fedora-18-Nightly-20121112.11-x86_64-Live-xfce.iso", and

$ gzip -dc isolinux/initrd0.img | pax | grep -i virtio
usr/lib/modules/3.6.6-3.fc18.x86_64/kernel/drivers/net/virtio_net.ko
usr/lib/modules/3.6.6-3.fc18.x86_64/kernel/drivers/block/virtio_blk.ko

Either the fix in comment 13 did not work, or whatever built the nightly 20121112.11 installer iso was not updated.

... Oh. The most recent build of livecd-tools is livecd-tools-18.12-2.fc18 <http://koji.fedoraproject.org/koji/buildinfo?buildID=362424>, from Oct 25, and it doesn't seem to include the fix for this bug.

Created attachment 644378 [details]
OVMF.fd (compressed) for comment 17

Created attachment 644379 [details]
rhel-qemu-wrapper script for comment 17

Neither koji nor admin.fedoraproject.org seems to know about "livecd-tools-18.13-1". I think the ON_QA status is not correct -- actually MODIFIED seems to be wrong as well, since the fix seems unavailable in any package.

Moving back to ASSIGNED. Apologies Brian if this is not the right thing to do.

I see, dracut referenced this so it got switched to ON_QA. I haven't built the new livecd-tools yet. Probably do that tomorrow.

livecd-tools-18.13-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/livecd-tools-18.13-1.fc18

Package livecd-tools-18.13-1.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing livecd-tools-18.13-1.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-19802/livecd-tools-18.13-1.fc18
then log in and leave karma (feedback).

(In reply to comment #23)
> Package livecd-tools-18.13-1.fc18:
> * should fix your issue,
> * was pushed to the Fedora 18 testing repository,
> * should be available at your local mirror within two days.
> Update it with:
> # su -c 'yum update --enablerepo=updates-testing livecd-tools-18.13-1.fc18'
> as soon as you are able to.
> Please go to the following url:
> https://admin.fedoraproject.org/updates/FEDORA-2012-19802/livecd-tools-18.13-
> 1.fc18
> then log in and leave karma (feedback).

The 20121209.13 nightly live <http://koji.fedoraproject.org/koji/taskinfo?taskID=4771292> has not been composed with this version. I guess I'll have to wait two weeks for the update to be pushed to stable and then retry a nightly.

Proposing as a nice-to-have bug for Fedora 18 Final, according to <https://fedoraproject.org/wiki/QA:SOP_nth_bug_process#Nice-to-have_bug_principles>:

It is certainly not a blocker bug, but it does block the livecd from reaching a graphical environment when booting it from a virtio-scsi CD-ROM. The fix should be small and easily testable.

livecd-tools-18.14-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/livecd-tools-18.14-1.fc18

livecd-tools-18.14-1.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

I'm confirming the fix. The 20121217.16 XFCE nightly live compose installs from a virtio-scsi CD-ROM to a virtio-scsi disk.

Thank you for fixing this BZ.