Bug 1197821

Summary:	Direct kernel boot of cloud images fails to find /dev/vda
Product:	[Fedora] Fedora	Reporter:	Mike Ruckman <mruckman>
Component:	distribution	Assignee:	Václav Pavlín <vpavlin>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	22	CC:	dennis, dustymabe, mruckman, notting, pschindl, robatino
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	AcceptedBlocker
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-03-05 02:51:11 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1043125

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.