Bug 875430 - After installing unable to boot Fedora 18 with virtio-scsi after successfully installing using virtio-scsi driver (have to use virtio-blk to boot)
Summary: After installing unable to boot Fedora 18 with virtio-scsi after successfully...
Alias: None
Product: Fedora
Classification: Fedora
Component: qemu
Version: 18
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Fedora Virtualization Maintainers
QA Contact: Fedora Extras Quality Assurance
Whiteboard: AcceptedNTH
Depends On:
Blocks: F18-accepted, F18FinalFreezeExcept
TreeView+ depends on / blocked
Reported: 2012-11-11 06:10 UTC by Shawn Starr
Modified: 2013-09-09 18:33 UTC (History)
22 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2013-09-09 18:33:48 UTC
Type: Bug

Attachments (Terms of Use)
default TC8 anaconda partitioning (46.82 KB, image/png)
2012-11-11 06:49 UTC, Shawn Starr
no flags Details
Packaging log (45.71 KB, text/plain)
2012-11-11 07:04 UTC, Shawn Starr
no flags Details
Program log (50.99 KB, text/plain)
2012-11-11 07:05 UTC, Shawn Starr
no flags Details
Storage log (136.50 KB, text/plain)
2012-11-11 07:05 UTC, Shawn Starr
no flags Details
anaconda logs (30.15 KB, text/bz2)
2013-02-01 03:02 UTC, Siavash
no flags Details

Description Shawn Starr 2012-11-11 06:10:32 UTC
Description of problem:

System fails to boot after successful install of Fedora TC8 (netinst.iso method)

Version-Release number of selected component (if applicable):
TC8 Anaconda

How reproducible: Tried once, didn't try 2nd time yet

Steps to Reproduce:
1. Set disk size to 5GB
2. Start an install, select GNOME Desktop for the default package group/set
3. Let Anaconda use automatic partitionin
4. Anaconda will format disk, then fail due with transaction error, shut VM down
5. Start VM up again with same 5GB partition already formatted/set
6. Start an install, select basic/minimal package group
7. Anaconda will want to reclaim disk space, choose "DELETE" for each of the partitions
8. Anaconda will then format and begin installation
9. Install is successful, "Fedora is now successfully installed on your system and ready for you to use! Go ahead and reboot to start using it!"
10. Reboot VM, no bootable disk found (no grub installed??)
Actual results:
Fails to boot after successful install

Expected results:
Boots Fedora 18

Comment 1 Shawn Starr 2012-11-11 06:49:43 UTC
Created attachment 642610 [details]
default TC8 anaconda partitioning

Comment 2 Shawn Starr 2012-11-11 06:50:40 UTC
See attachment for the original partitioning Anaconda TC8 chose.

Change the Action to DELETE on both partitions and then install base/minimal package group.

Comment 3 Shawn Starr 2012-11-11 07:04:27 UTC
Reproduced a 2nd time

Attached logs

Comment 4 Shawn Starr 2012-11-11 07:04:46 UTC
Created attachment 642611 [details]
Packaging log

Comment 5 Shawn Starr 2012-11-11 07:05:06 UTC
Created attachment 642612 [details]
Program log

Comment 6 Shawn Starr 2012-11-11 07:05:34 UTC
Created attachment 642613 [details]
Storage log

Comment 7 Shawn Starr 2012-11-11 07:22:59 UTC
So it seems its nothing to do with partitioning, doing a basic/minimal install fails to boot system

Comment 8 Andre Robatino 2012-11-11 11:03:34 UTC
Minimal TC8 install works for me in VirtualBox with a 30 GB disk. Haven't tried default (Gnome) yet.

Comment 9 Shawn Starr 2012-11-13 05:36:59 UTC
NOTE: This is in KVM

I note, clicking the reboot button, doesn't reboot VM, its stuck shutting down (blackness). After force-resetting the VM, it won't boot the disk.

Comment 10 Steve Tyler 2012-11-16 05:43:44 UTC
Here is a detailed reproducer with a 5 GB disc image, 1024 MB memory, and the F18-Beta-TC8 DVD.

Test 1:
Create a 5 GB empty disc image:
$ qemu-img create f18-test-4.img 5G

Start the DVD installer:
$ qemu-kvm -m 1024 -hda f18-test-4.img -cdrom ~/xfr/fedora/F18/F18-Beta/TC8/Fedora-18-Beta-TC8-x86_64-DVD.iso -usb -vga qxl -boot menu=on -usbdevice mouse

Begin a Gnome desktop install with default partitioning.

The install fails with the error: "Could not run transaction." The progress bar message says: "Preparing transaction from installation source".

Click Exit Installer. Click Quit -- do not send a report to BZ.

Test 2:
Restart the installer and reuse the disc image from Test 1, but delete all filesystems with the Reclaim Disk Space dialog. Select a minimal install.

Here, the install completes and logging into the installed system succeeds.

1. The amount of memory needs to be reported when testing disk space requirements, because the amount of swap space automatically allocated depends on the amount of memory. See the function, swapSuggestion():


2. Installs from the net install CD are not reliably reproducible, because different package versions may be present in the repos for different test runs. The DVD is a better choice for testing disk space requirements, because the package versions are the same for each test run.

Comment 11 Shawn Starr 2012-11-16 05:57:20 UTC
This is using netinst CD, I am not able to install TC8 or the current  20121112_f18b-smoke18 build with just the basic install ie minimal selected only.

Just use KVM (virt-manager) and do a netinst.iso install, it will fail to boot but install successfully.

Comment 12 Steve Tyler 2012-11-16 06:53:35 UTC
With the netinst CD, a minimal install and reboot succeed:

$ qemu-img create f18-test-4.img 5G
$ qemu-kvm -m 1024 -hda f18-test-4.img -cdrom ~/xfr/fedora/F18/F18-Beta/TC8/Fedora-18-Beta-TC8-x86_64-netinst.iso -usb -vga qxl -boot menu=on -usbdevice mouse

Have you tried zeroing the disc image?
How much memory have you allocated to your VM?

Comment 13 Ken Dreyer 2012-11-27 05:29:52 UTC
I'm also seeing this same issue with the latest anaconda. I'm PXE booting, and I do a minimal install in KVM on an F17 hypervisor. The installer completes, but I can't boot the VM.

The VM has 4GB of RAM, and I've tried 10GB and 8GB disks. I've also tried brand new disk images. I've tried with both virtio and sata disk types.

Comment 14 Ken Dreyer 2012-11-27 06:11:06 UTC
I've also tried using an IDE disk type, and just going with the default package set (Gnome). The VM fails to boot in either case.

Comment 15 Steve Tyler 2012-11-27 06:42:33 UTC
The developers will want to see the anaconda logs from the install target. They should be in: /var/log/anaconda/*log.

Comment 16 Ken Dreyer 2012-11-27 07:30:47 UTC
I am able to reproduce this on physical hardware (a PXE install on my Dell Latitude D630). The installation appears to finish successfully, but when the box reboots, it just sits at a black screen with a blinking cursor. I tried again and selected the defaults for partitioning (LVM), with the same result.

Meanwhile here's my attempt to pull the logs out of my VM:

# virt-copy-out -d fedora18 /var/log/anaconda .
guestfish: no operating system was found on this disk

I poked around with the guestfish tool:

/dev/vda: unknown

><fs> mount-ro /dev/vda /
libguestfs: error: mount_ro: /dev/vda on / (options: 'ro'): mount: wrong fs type, bad option, bad superblock on /dev/vda,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail or so

Comment 17 Steve Tyler 2012-11-27 08:02:48 UTC
Thanks for your follow-up report.

><fs> mount-ro /dev/vda /

Maybe that should be /dev/vda1, which would probably be the "/boot" file system.

The log files will be on the "/" logical volume: /dev/mapper/fedora-root.

It might be simpler to boot the installer disk image in rescue mode, and let it to mount everything under /mnt/sysimage. Rescue mode is listed under Troubleshooting in the installer menu.

Comment 18 Ken Dreyer 2012-11-27 08:14:50 UTC
I was wrong - Anaconda had frozen on that last install test, so it didn't actually write out anything! After I realized my mistake, I did another install, and I was able to copy the logs out.

I see my problem now: when I don't have a "bootloader" parameter in my Kickstart file, Anaconda will skip writing a bootloader, even if I select a boot device in the UI. Ouch.

I'll continue the discussion on a more relevant bug, #871143. Looking at Shawn's logs, his problem must be slightly different than mine, because his storage log indicates that Anaconda did write the bootloader.

Comment 19 Brian Lane 2012-11-27 17:19:32 UTC
Shawn, before trying to reboot can you jump to tty1 and use the shell window (ctrl-B 2) and grep the mbr for GRUB:

dd if=/dev/sda bs=512 count=1 | grep GRUB

If it matches it should say 'Binary file (standard input) matches'

Also, please attach /boot/grub2/grub.cfg and the output of blkid just to make sure the config looks correct.

Comment 20 Shawn Starr 2012-11-29 08:49:06 UTC
im trying that right now... i can reproduce this in a kickstarted auto install also.

MBR shows: grep is finding GRUB in output

Note: I am using SCSI (virtio-scsi) for disks so /dev/sda

I assume you mean /mnt/sysimage/boot/grub2 which has a grub.cfg and is correct, shows the kernel 3.6.6-3.fc18 from the Beta 18 DVD today.

fdisk shows two partitions, /dev/sda1 as bootable where /dev/sda1 is /boot.

about to reboot and see...

I click reboot... 'Boot failed: could not read hard disk'

now its going to PXE reinstall again...

Comment 21 Shawn Starr 2012-11-29 08:51:29 UTC

rootpw letmein
#ftp --server=
nfs --server= --dir=/var/lib/libvirt/images
lang en_US.UTF-8
#network --device eth0 --bootproto static
# --bootproto dhcp
selinux --disabled

firewall --disabled
authconfig --enableshadow --enablemd5
timezone --utc America/Toronto
clearpart --all --drives=sda
part /boot --fstype ext4 --size=300 --asprimary
part / --fstype ext4 --grow --size=1024 --asprimary
bootloader --location=mbr --driveorder=sda --timeout=5

%packages --excludedocs

%post --log=/root/dump.log

gpxe config:

default vesamenu.c32
#prompt 1
timeout 30

display boot.msg

label linux
  menu label ^Network Install System
  menu default
  kernel vmlinuz-x86_64
  append initrd=initramfs-x86_64.img ks= inst.repo=nfsiso: xdriver=vesa nomodeset ip=

I can get the grub2 config after, shutting kvm down completely it still can't read the disk.

Comment 22 Shawn Starr 2012-11-29 14:25:02 UTC
So when I switch the disk to virtio and NOT virtio-scsi KVM now finds and boots the disk?


Comment 23 Shawn Starr 2012-11-29 14:26:42 UTC
So when I switch the disk to virtio (blk/IDE) and NOT virtio-scsi KVM now finds and boots the disk?


Comment 24 Shawn Starr 2012-11-29 14:29:33 UTC
Maybe how grub is writing the entries is breaking something? it installs ok with virtio-scsi used but fails to boot if left on virtio-scsi (disk not detected)

Switching to regular IDE virtio-blk will allow the disk to boot.

Comment 25 Brian Lane 2012-11-29 17:14:35 UTC
if you aren't getting to grub then this isn't an anaconda or grub problem. Something is up with your virt setup.

Comment 26 Adam Williamson 2012-12-19 20:42:17 UTC
Discussed at 2012-12-19 NTH review meeting: http://meetbot.fedoraproject.org/fedora-bugzappers/2012-12-19/f18final-blocker-review-6.2012-12-19-17.02.log.txt . This appears to be a bug with installing to a particular (non-default) KVM storage driver: not serious enough to be a blocker but, if we understand correctly, accepted as NTH as it likely can't be fixed with a post-release update and obviously it'd be good to support all the drivers we provide. A small tested fix would be considered.

Comment 27 Siavash 2013-02-01 03:02:02 UTC
Created attachment 691337 [details]
anaconda logs

it also contains testbed.xml, which is my vm configuration.

Comment 28 Siavash 2013-02-01 03:09:38 UTC
I reproduce the same problem here, i've installed my vm with virtio IO, the installation went fine, and system was able to boot to grub, but the system fails to boot i get :
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
if i change the driver to IDE the problem still persists.

Comment 29 Paolo Bonzini 2013-02-18 13:42:51 UTC
> I reproduce the same problem here, i've installed my vm with virtio IO

This bug is about virtio-scsi.  I cannot find a virtio-scsi disk in your configuration.

> qemu-1.1.2-r3

What is the distro of your host?  I cannot find this build of QEMU for Fedora.


Comment 30 Siavash 2013-02-18 14:16:21 UTC
(In reply to comment #29)
> > I reproduce the same problem here, i've installed my vm with virtio IO
> This bug is about virtio-scsi.  I cannot find a virtio-scsi disk in your
> configuration.
Paolo, You are right , it's not a scsi problem, my storage was virtio at the time and no matter what i changed it to , it did not work
> > qemu-1.1.2-r3
> What is the distro of your host?  I cannot find this build of QEMU for
> Fedora.
my distro is not fedora, it's Gentoo.
i guess it was not the right bug to post on , sorry for wasting your time.
i fixed the problem by changing my installation media, to fedora DVD.
now it works.
Thank you.
> https://koji.fedoraproject.org/koji/packageinfo?packageID=3685

Comment 31 Shawn Starr 2013-02-26 15:37:52 UTC
Please don't close this.

And let's get this back on track. I cannot use virtio-scsi with virt-manager/libvirt it will not boot the VM after it installs.

Comment 32 Shawn Starr 2013-02-26 15:45:34 UTC
@Siavash this bug is exclusively Fedora 18 (likely Rawhide also), please keep Gentoo bugs out of this.

Comment 33 Steve Tyler 2013-02-26 17:47:04 UTC
Could you post the qemu command-line?
$ ps -ef | grep qemu

Comment 34 Steve Tyler 2013-02-26 19:57:35 UTC
I cannot reproduce this problem using the F17 qemu[1] scsi or virtio interfaces.

Starting with an empty 12 GB disk image, a default, minimal install of F18 Final succeeds and boots with either:

$ qemu-img create f18-test-4.img 12G
$ qemu-kvm -m 2048 -drive file=f18-test-4.img,if=scsi -cdrom ~/xfr/fedora/F18/Fedora-18-x86_64-DVD.iso -vga qxl -boot menu=on -usbdevice mouse

$ qemu-img create f18-test-4.img 12G
$ qemu-kvm -m 2048 -drive file=f18-test-4.img,if=virtio -cdrom ~/xfr/fedora/F18/Fedora-18-x86_64-DVD.iso -vga qxl -boot menu=on -usbdevice mouse

[1] qemu-kvm-1.0.1-3.fc17.x86_64

Comment 35 Shawn Starr 2013-02-26 20:01:25 UTC
Please try Fedora 18 and use block device 'virtio-scsi' I am using virt-manager and need to confirm the qemu commandline its running

Comment 36 Steve Tyler 2013-02-26 22:40:54 UTC
I cannot reproduce this problem using the F18 qemu[1] scsi or virtio interfaces and the same procedure as in Comment 34.

NB: virt-manager and qemu use different names for some options:
$ man qemu

[1] qemu-kvm-1.2.2-6.fc18.x86_64

Comment 37 Shawn Starr 2013-03-20 16:27:07 UTC
I will be testing this today and will update bug

Comment 38 Shawn Starr 2013-08-09 17:38:27 UTC
This appears to be unsupported now in our qemu build as virt-manager/libvirt now throws an error if virtio-scsi is used in configuration.

Will check this tonight in Linux VM instance to confirm VM won't power on with virtio-scsi used.

Comment 39 Cole Robinson 2013-09-09 13:49:24 UTC
Shawn, any news?

Comment 40 Shawn Starr 2013-09-09 18:33:13 UTC
I confirm this works in Fedora 19 libvirt/virt-manager combo using following XML:

OVERWRITTEN AND LOST. Changes to this xml configuration should be made using:
  virsh edit Fedora_QA
or other application using the libvirt API.

<domain type='kvm'>
  <memory unit='KiB'>3932160</memory>
  <currentMemory unit='KiB'>3932160</currentMemory>
  <vcpu placement='static'>1</vcpu>
    <type arch='x86_64' machine='pc-i440fx-1.4'>hvm</type>
    <boot dev='hd'/>
    <bootmenu enable='yes'/>
  <clock offset='utc'/>
    <disk type='file' device='disk'>
      <driver name='qemu' type='raw' cache='none'/>
      <source file='/var/lib/libvirt/images/Fedora_QA.img'/>
      <target dev='sda' bus='scsi'/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <target dev='hdc' bus='ide'/>
      <address type='drive' controller='0' bus='1' target='0' unit='0'/>
    <controller type='usb' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/>
    <controller type='ide' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
    <controller type='virtio-serial' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    <controller type='pci' index='0' model='pci-root'/>
    <controller type='scsi' index='0' model='virtio-scsi'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
    <interface type='bridge'>
      <mac address='52:54:00:ec:ec:b7'/>
      <source bridge='bridge0'/>
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    <serial type='pty'>
      <target port='0'/>
    <console type='pty'>
      <target type='serial' port='0'/>
    <channel type='spicevmc'>
      <target type='virtio' name='com.redhat.spice.0'/>
      <address type='virtio-serial' controller='0' bus='0' port='1'/>
    <input type='tablet' bus='usb'/>
    <input type='mouse' bus='ps2'/>
    <graphics type='spice' autoport='yes' listen=''>
      <listen type='address' address=''/>
      <model type='qxl' ram='65536' vram='65536' heads='1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    <memballoon model='virtio'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>

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