Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1197821 - Direct kernel boot of cloud images fails to find /dev/vda
Summary: Direct kernel boot of cloud images fails to find /dev/vda
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: distribution
Version: 22
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Václav Pavlín
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
Depends On:
Blocks: F22BetaBlocker
TreeView+ depends on / blocked
 
Reported: 2015-03-02 16:54 UTC by Mike Ruckman
Modified: 2015-03-05 02:51 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-03-05 02:51:11 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)

Description Mike Ruckman 2015-03-02 16:54:37 UTC 
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
Comment 1 Fedora Blocker Bugs Application 2015-03-02 17:05:06 UTC 
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)
Comment 2 Petr Schindler 2015-03-02 19:49:46 UTC 
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/
Comment 3 Dennis Gilmore 2015-03-02 20:13:16 UTC 
I am unable to reproduce,  using testCloud the TC7 image boots just fine.
Comment 4 Dusty Mabe 2015-03-02 20:39:15 UTC 
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?
Comment 5 Mike Ruckman 2015-03-05 02:51:11 UTC 
Updating the hosts kernel seems to have solved this issue - I don't see it any more with the TC8 image. Closing.
Note You need to log in before you can comment on or make changes to this bug.