Created attachment 642610 [details]
default TC8 anaconda partitioning

See attachment for the original partitioning Anaconda TC8 chose.

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

Reproduced a 2nd time

Attached logs

Created attachment 642611 [details]
Packaging log

Created attachment 642612 [details]
Program log

Created attachment 642613 [details]
Storage log

So it seems its nothing to do with partitioning, doing a basic/minimal install fails to boot system

Minimal TC8 install works for me in VirtualBox with a 30 GB disk. Haven't tried default (Gnome) yet.

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.

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.

Notes:
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():

http://git.fedorahosted.org/cgit/anaconda.git/tree/pyanaconda/storage/devicelibs/swap.py

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.

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.

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?

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.

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.

The developers will want to see the anaconda logs from the install target. They should be in: /var/log/anaconda/*log.

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:

><fs>list-filesystems
/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

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.

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.

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.

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...

kickstart:

rootpw letmein
install
#ftp --server=192.168.10.1
nfs --server=192.168.10.1 --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
zerombr
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
@Standard
#kernel
#grub2
-sendmail
#wget
#
%end

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

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=ftp://192.168.10.1/ks.cfg inst.repo=nfsiso:192.168.10.1:/var/lib/libvirt/images/Fedora-18-Beta-x86_64-DVD.iso xdriver=vesa nomodeset ip=192.168.10.4:192.168.10.1:192.168.10.1:255.255.255.0:test-vm:eth0:off

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

So when I switch the disk to virtio and NOT virtio-scsi KVM now finds and boots the disk?

hmm?

So when I switch the disk to virtio (blk/IDE) and NOT virtio-scsi KVM now finds and boots the disk?

hmm?

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.

if you aren't getting to grub then this isn't an anaconda or grub problem. Something is up with your virt setup.

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.

Created attachment 691337 [details]
anaconda logs

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

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.
qemu-1.1.2-r3
libvirt-1.0.0
virt-manager-0.9.4
virtinst-0.600.3

> 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.

https://koji.fedoraproject.org/koji/packageinfo?packageID=3685

(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

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.

@Siavash this bug is exclusively Fedora 18 (likely Rawhide also), please keep Gentoo bugs out of this.

Could you post the qemu command-line?
$ ps -ef | grep qemu

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

Please try Fedora 18 and use block device 'virtio-scsi' I am using virt-manager and need to confirm the qemu commandline its running

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

I will be testing this today and will update bug

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.

Shawn, any news?

I confirm this works in Fedora 19 libvirt/virt-manager combo using following XML:

<!--
WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE
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'>
  <name>Fedora_QA</name>
  <uuid>d5c13b9b-8ad5-1c43-3aac-d0e1b36be6eb</uuid>
  <memory unit='KiB'>3932160</memory>
  <currentMemory unit='KiB'>3932160</currentMemory>
  <vcpu placement='static'>1</vcpu>
  <os>
    <type arch='x86_64' machine='pc-i440fx-1.4'>hvm</type>
    <boot dev='hd'/>
    <bootmenu enable='yes'/>
  </os>
  <features>
    <acpi/>
    <apic/>
    <pae/>
  </features>
  <clock offset='utc'/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>restart</on_crash>
  <devices>
    <emulator>/usr/bin/qemu-kvm</emulator>
    <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>
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <target dev='hdc' bus='ide'/>
      <readonly/>
      <address type='drive' controller='0' bus='1' target='0' unit='0'/>
    </disk>
    <controller type='usb' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/>
    </controller>
    <controller type='ide' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
    </controller>
    <controller type='virtio-serial' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    </controller>
    <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'/>
    </controller>
    <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'/>
    </interface>
    <serial type='pty'>
      <target port='0'/>
    </serial>
    <console type='pty'>
      <target type='serial' port='0'/>
    </console>
    <channel type='spicevmc'>
      <target type='virtio' name='com.redhat.spice.0'/>
      <address type='virtio-serial' controller='0' bus='0' port='1'/>
    </channel>
    <input type='tablet' bus='usb'/>
    <input type='mouse' bus='ps2'/>
    <graphics type='spice' autoport='yes' listen='0.0.0.0'>
      <listen type='address' address='0.0.0.0'/>
    </graphics>
    <video>
      <model type='qxl' ram='65536' vram='65536' heads='1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </video>
    <memballoon model='virtio'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
    </memballoon>
  </devices>
</domain>