Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1139869

Summary: OS provisioning fails for em1 network device
Product: Red Hat OpenStack Reporter: Balaji <bjayavel>
Component: rhel-osp-installerAssignee: Marek Hulan <mhulan>
Status: CLOSED DUPLICATE QA Contact: Omri Hochman <ohochman>
Severity: medium Docs Contact:
Priority: high    
Version: 5.0 (RHEL 7)CC: aberezin, bjayavel, lzap, mburns, mhulan, morazi, randy_perryman, rhos-maint, sseago, yeylon
Target Milestone: z1Keywords: Triaged, ZStream
Target Release: Installer   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-09-17 11:22:31 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:
Attachments:
Description Flags
Error on the target console during boot
none
updated screenshot of console with error none

Description Balaji 2014-09-09 21:02:14 UTC
Description of problem:
Bare metal provisioning fails on hardware where the network device name is em1/em2/em3 as against eth0/eth1/eth2 etc

Version-Release number of selected component (if applicable):
Rhel-osp-installer 1:0.3.4

How reproducible:
Can be reproduced on a Dell blade bare metal host

Steps to Reproduce:
1.Install the new installer, discover the target host and deploy.

Actual results:
OS installation on the provisioning node fails with the message
dracut-initqueue : Warning: Could not boot
dracut-initqueue : Warning: /dev/root does not exist

Expected results:
Network device em1 should be converted to eno1 by systemd-udevd. Instead it tries to convert eth0 to eno1. Hence network is not available.

Additional info:

Comment 3 Mike Burns 2014-09-12 14:21:11 UTC
I suspect that this is due to biosdevname being enabled on the discovery image and not the rest of the time.  

Can you try this:

edit the /var/lib/tftpboot/pxelinux.cfg/default file
add biosdevname=0 to the Append line
save the file
rediscover hosts

and let me know if that fixes your issue?

I've created a PR for this change upstream since it's a good change regardless.

https://github.com/theforeman/foreman-installer-staypuft/pull/88

Comment 4 Balaji 2014-09-12 17:06:06 UTC
I set the value to biosdevname=0 in the /var/lib/tftpboot/pxelinux.cfg/default file, but the discovery fails.

Comment 5 Balaji 2014-09-12 19:28:44 UTC
Created attachment 937087 [details]
Error on the target console during boot

Error on the console while provisioning.

Comment 6 Mike Burns 2014-09-12 19:34:27 UTC
biosdevname did not help in the end once we got around the failed discovery boot.

Marek, Lukas, any ideas?

Comment 7 Lukas Zapletal 2014-09-15 07:11:36 UTC
Hey, as you can see from the screenshot, Foreman application returns 500 when trying to render the kickstart template. Can you paste Foreman logs here? This looks like some error in Foreman rather than Discovery.

Comment 8 Marek Hulan 2014-09-15 07:29:05 UTC
This will need some debugging of the provisioning template. I bet it will be in networking configuration part. Would it be possible to provide a foreman instance where we could test it? Just seeing foreman log might not help in this case.

Comment 9 Balaji 2014-09-15 13:20:55 UTC
Created attachment 937618 [details]
updated screenshot of console with error

Comment 10 Balaji 2014-09-15 13:22:45 UTC
The kickstart error was a different issue and has been resolved. But the problem is persistent as shown in the updated screenshot.

Comment 11 Marek Hulan 2014-09-15 13:32:36 UTC
Can you check you installation images in /var/lib/tftpboot/boot for rhel7? Ideally paste their size and checksums.

Comment 12 Lukas Zapletal 2014-09-16 07:16:21 UTC
Also make sure the server has more than 1 GB of RAM. We do not support less then gig!

Comment 13 Balaji 2014-09-16 12:28:02 UTC
The installer has 3GB and the target host has 48GB. Hence no concerns in that aspect.

Comment 14 Scott Seago 2014-09-17 11:10:39 UTC
This might be a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=1141955

Comment 15 Scott Seago 2014-09-17 11:22:31 UTC

*** This bug has been marked as a duplicate of bug 1141955 ***