Bug 864012 - add virtio_scsi module to "isolinux/initrd0.img" on the Fedora 18 Live (or installer) ISO
Summary: add virtio_scsi module to "isolinux/initrd0.img" on the Fedora 18 Live (or in...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: livecd-tools
Version: 18
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Brian Lane
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: F18-accepted, F18FinalFreezeExcept
TreeView+ depends on / blocked
 
Reported: 2012-10-08 11:04 UTC by Laszlo Ersek
Modified: 2012-12-20 10:36 UTC (History)
11 users (show)

Fixed In Version: livecd-tools-18.13-1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-12-18 06:56:33 UTC
Type: Bug


Attachments (Terms of Use)
OVMF.fd (compressed) for comment 17 (751.79 KB, application/x-gzip)
2012-11-13 20:41 UTC, Laszlo Ersek
no flags Details
rhel-qemu-wrapper script for comment 17 (310 bytes, text/plain)
2012-11-13 20:44 UTC, Laszlo Ersek
no flags Details

Description Laszlo Ersek 2012-10-08 11:04:50 UTC
**** Description of problem:
Dracut fails with the following message and drops me to the emergency shell:

  dracut-initqueue[195]: Warning: could not boot
  dracut-initqueue[195]: Warning:
                         /dev/disk/by-label/Fedora-18-Alpha-x86_64-Live-XFCE
                         does not exist
  dracut-initqueue[195]: Warning: /dev/mapper/live-rw does not exist

Version-Release number of selected component (if applicable):
- Host kernel: 2.6.32-279.9.1.el6.x86_64
  - qemu-kvm: qemu-kvm-0.12.1.2-2.310.el6.reset_pmba.x86_64
  - boot firmware: OVMF svn rev 13778 + my virtio-scsi patch
- guest: Fedora 18 Alpha XFCE Live image

How reproducible:
100%

Steps to Reproduce:
1. had a working virtual machine with OVMF boot firmware
2. configured the above installer ISO for the virtual machine as SCSI CD-ROM
3. changed the boot order in virt-manager so that the CD-ROM would come first
4. edited the domain XML with virsh and added the

     model='virtio-scsi'

attribute to the

  /controller[type='scsi' and index='0]

element

5. booted the VM
  
**** Actual results:
See in problem description

Expected results:
Live system should boot

**** Additional info:
This problem may be somewhat similar to bug 855849 or <https://fedoraproject.org/wiki/Common_F18_bugs#uefi-dvd-fail>, but I think it has a different root. Namely, in the emergency shell, "grep virtio /proc/modules" returns virtio_blk and virtio_net, but not virtio_scsi. Therefore I think the virtio_scsi module should be added to the dracut ram disk.

Comment 1 Laszlo Ersek 2012-10-15 10:26:10 UTC
Retitled BZ for clarity.

Comment 2 Fedora Update System 2012-10-16 15:17:02 UTC
dracut-024-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/dracut-024-1.fc18

Comment 3 Fedora Update System 2012-10-16 17:42:48 UTC
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).

Comment 4 Laszlo Ersek 2012-10-16 19:40:07 UTC
Is the update available in a new ISO? Thanks.

Comment 5 Harald Hoyer 2012-10-17 12:51:24 UTC
(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

Comment 6 Laszlo Ersek 2012-10-17 13:55:58 UTC
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

Comment 7 Laszlo Ersek 2012-10-17 14:03:29 UTC
Retitling bug for more clarity.

Comment 8 Laszlo Ersek 2012-10-17 14:12:58 UTC
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!

Comment 9 Harald Hoyer 2012-10-18 09:24:27 UTC
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.

Comment 10 Laszlo Ersek 2012-10-18 12:19:49 UTC
Indeed! Another round of bug 672936 (upstream livecd commit 228f10f5) seems justified. Thanks!

Comment 11 Brian Lane 2012-10-18 20:39:22 UTC
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.

Comment 12 Laszlo Ersek 2012-10-18 20:54:01 UTC
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.

Comment 13 Brian Lane 2012-10-18 21:20:26 UTC
They shouldn't hurt to have available should they? I went ahead and added all the virtio* modules, including virtio-rng just for completeness.

Comment 15 Fedora Update System 2012-10-19 10:08:38 UTC
dracut-024-5.git20121019.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/dracut-024-5.git20121019.fc18

Comment 16 Fedora Update System 2012-10-19 15:42:59 UTC
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).

Comment 17 Laszlo Ersek 2012-11-13 20:37:43 UTC
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.

Comment 18 Laszlo Ersek 2012-11-13 20:41:47 UTC
Created attachment 644378 [details]
OVMF.fd (compressed) for comment 17

Comment 19 Laszlo Ersek 2012-11-13 20:44:27 UTC
Created attachment 644379 [details]
rhel-qemu-wrapper script for comment 17

Comment 20 Laszlo Ersek 2012-11-13 20:48:48 UTC
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.

Comment 21 Brian Lane 2012-11-14 00:26:41 UTC
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.

Comment 22 Fedora Update System 2012-12-04 23:44:13 UTC
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

Comment 23 Fedora Update System 2012-12-05 23:10:45 UTC
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).

Comment 24 Laszlo Ersek 2012-12-10 11:59:01 UTC
(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.

Comment 25 Laszlo Ersek 2012-12-11 12:22:22 UTC
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.

Comment 26 Fedora Update System 2012-12-15 00:49:29 UTC
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

Comment 27 Fedora Update System 2012-12-18 06:56:36 UTC
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.

Comment 28 Laszlo Ersek 2012-12-20 10:36:54 UTC
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.


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