lavabit / robox

The tools needed to robotically create/configure/provision a large number of operating systems, for a variety of hypervisors, using packer.
618 stars 140 forks source link

generic/fedora31 box fails when running with libvirt on fedora31 #115

Closed chaudron closed 4 years ago

chaudron commented 4 years ago

I tried to install a simple fedora31 box on a fedora 31 machine and it's failing (even tried a brand new install). It seems to work fine on RHEL8 which is the only alternative I had available (or on OSX with the virtual box provider).

Version information:

$ rpm -q vagrant vagrant-libvirt libvirt qemu-kvm
vagrant-2.2.6-1.fc31.noarch
vagrant-libvirt-0.0.45-3.fc31.noarch
libvirt-5.6.0-5.fc31.x86_64
qemu-kvm-4.1.1-1.fc31.x86_64
$ vagrant version; vagrant plugin list
Installed Version: 2.2.6

Vagrant was unable to check for the latest version of Vagrant.
Please check manually at https://www.vagrantup.com
vagrant-libvirt (0.0.45, system)
vagrant-reload (0.0.1, global)
vagrant-sshfs (1.3.3, global)

Replication step, install latest fedora 31 with updates:

$ mkdir test

$ cd test

$ vagrant init generic/fedora31
A `Vagrantfile` has been placed in this directory. You are now
ready to `vagrant up` your first virtual environment! Please read
the comments in the Vagrantfile as well as documentation on
`vagrantup.com` for more information on using Vagrant.

$ vagrant up
Bringing machine 'default' up with 'libvirt' provider...
==> default: Checking if box 'generic/fedora31' version '2.0.6' is up to date...
==> default: Creating image (snapshot of base box volume).
==> default: Creating domain with the following settings...
==> default:  -- Name:              test_default
==> default:  -- Domain type:       kvm
==> default:  -- Cpus:              2
==> default:  -- Feature:           acpi
==> default:  -- Feature:           apic
==> default:  -- Feature:           pae
==> default:  -- Memory:            2048M
==> default:  -- Management MAC:    
==> default:  -- Loader:            
==> default:  -- Nvram:             
==> default:  -- Base box:          generic/fedora31
==> default:  -- Storage pool:      default
==> default:  -- Image:             /home/echaudro/.local/share/libvirt/images/test_default.img (32G)
==> default:  -- Volume Cache:      default
==> default:  -- Kernel:            
==> default:  -- Initrd:            
==> default:  -- Graphics Type:     vnc
==> default:  -- Graphics Port:     -1
==> default:  -- Graphics IP:       127.0.0.1
==> default:  -- Graphics Password: Not defined
==> default:  -- Video Type:        cirrus
==> default:  -- Video VRAM:        256
==> default:  -- Sound Type:    
==> default:  -- Keymap:            en-us
==> default:  -- TPM Path:          
==> default:  -- INPUT:             type=mouse, bus=ps2
==> default: Creating shared folders metadata...
==> default: Starting domain.
==> default: Waiting for domain to get an IP address...

It's waiting for the IP forever, on the console for the VM I can see it's waiting for start job to complete (see attachment).

console

timschumi commented 4 years ago

This sounds a lot like an issue I had with more recent Gentoo boxes. In my case, it ended up being a missing module to support SCSI.

Could you open your VM configuration through something like virt-manager and try different bus types (i.e. SATA, maybe even VirtIO)?

chaudron commented 4 years ago

Interesting! changing it to SATA completed the boot process.

timschumi commented 4 years ago

This seems to be an issue on multiple boxes.

I've been building all the boxes that are using a SCSI/libvirt combo over the last 24 hours, I'll go through them and figure out which of those have boot issues (and fix them if possible). I assume the most common cause is that the specific SCSI driver is located as a module on the disk, which obviously can't be loaded afterwards.

EDIT: Why this suddenly broke now I have no idea.

timschumi commented 4 years ago

I opened #125 to track this accross multiple boxes.

ladar commented 4 years ago

We'll use the more generic issue in #125 to fix this...