Description of problem: Booting a cloud image locally (direct kernel boot) fails, dropping into a dracut shell. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Download kernel and initramfs (virt-builder --get-kernel <image path>) 2. Start a new vm and use the freshly downloaded kernel to boot 3. Attach a formatted seed.img with metadata 4. pass kernel args to set cloud-init to look for the seed img (root=/dev/vda1 ro ds=nocloud-net) Actual results: Begins to boot, hangs then drops into the dracut shell claiming it can't find /dev/vda1 Expected results: Image boots up, applying instructions from the seed.img Additional info: If you remove the direct kernel boot after the dracut shell, the image will boot up fine and have actually applied the information provided in the seed.img (namely hostname and username/password - haven't tested other bits yet). And /dev/vda1 is there. Instructions on how to do this can be found here: https://rwmj.wordpress.com/2013/12/10/creating-a-cloud-init-config-disk-for-non-cloud-boots/ Or you can use testCloud: http://github.com/Rorosha/testCloud
Proposed as a Blocker for 22-beta by Fedora user roshi using the blocker tracking app because: I think this bug violates at *least* the spirit, if not the letter, of several beta criteria: - All release-blocking images must boot in their supported configurations. - It must be possible to install by booting the installation kernel directly (including via PXE) and correctly specifying a remote source for the installer itself. (cloud-init is the cloud version of installation, as it's where all your instance set up happens, so I would argue they are the same thing) - The cloud-init package must be functional for release blocking cloud images. (no-cloud metadata sources is a method supported within cloud-init across distros, so it should work for Fedora as well)
Discussed at today's blocker review meeting [1]. This bug was accepted as Beta Blocker - This bug is a conditional violation of several Beta criteria and breaks the supported cloud-init feature set. http://meetbot.fedoraproject.org/fedora-blocker-review/2015-03-02/
I am unable to reproduce, using testCloud the TC7 image boots just fine.
This may be an issue of the hard drive being emulated using the scsi driver rather than the virtio driver. On my initial attempt to recreate I did not provide a bus=virtio arg to virt-install and the disk got emulated as a scsi device (/dev/sda). After providing bus=virtio the image booted fine. Here is my virt-install command line for successful boot: sudo virt-install --import --name test --ram 2048 --vcpus 2 --disk /guests/F22-20150227-TC7.snap,bus=virtio --network bridge=virbr0 --boot kernel=/guests/vmlinuz-4.0.0-0.rc1.git0.1.fc22.x86_64,initrd=/guests/initramfs-4.0.0-0.rc1.git0.1.fc22.x86_64.img,kernel_args="root=/dev/vda1 ro" As an alternative you may also be able to fish out the UUID of the filesystem and use that instead which is what grub.conf inside of the image uses: root=UUID=31691aa1-c626-4b62-b55c-572e0deb56ca Can you check to see if either of these solve your issue?
Updating the hosts kernel seems to have solved this issue - I don't see it any more with the TC8 image. Closing.