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

Bug 1292598

Summary: chroot: failed to run command '/bin/bash': No such file or directory
Product: Red Hat OpenStack Reporter: Nicolas Hicher <nhicher>
Component: rhosp-directorAssignee: Lucas Alvares Gomes <lmartins>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Shai Revivo <srevivo>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.0 (Kilo)CC: hbrock, jwaterwo, lmartins, mburns, nhicher, rhel-osp-director-maint
Target Milestone: ---Flags: nhicher: needinfo-
Target Release: 10.0 (Newton)   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-05-19 10:24:19 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
screenshot and templates none

Description Nicolas Hicher 2015-12-17 21:34:54 UTC
Created attachment 1106876 [details]
screenshot and templates

Description of problem:

When I tried to deploy the last 7.2 puddle (2015-11-25.2), I have a very strange error. Sometime a deployment fail with this error:

chroot: failed to run command '/bin/bash': No such file or directory

If I relaunch the deployment, I have the same issue, but with another node, sometime 2 nodes.

(I added screenshots with the error)

Version-Release number of selected component (if applicable):

7.2 puddle (2015-11-25.2)

How reproducible:

Everytime

Steps to Reproduce:
Deploy openstack in 7 vms


Actual results:
Deployment fails

Expected results:
Hosts are up and running

Additional info:

There is this error on /var/log/ironic/ironic-api.log, not sure it's related:

2015-12-17 16:13:49.889 1161 ERROR wsme.api [-] Server-side error: "Invalid control character '\n' at: line 1 column 149 (char 148)". Detail:
Traceback (most recent call last):

  File "/usr/lib/python2.7/site-packages/wsmeext/pecan.py", line 73, in callfunction
    pecan.request.body, pecan.request.content_type

  File "/usr/lib/python2.7/site-packages/wsme/rest/args.py", line 279, in get_args
    from_body = args_from_body(funcdef, body, mimetype)

  File "/usr/lib/python2.7/site-packages/wsme/rest/args.py", line 226, in args_from_body
    body, datatypes, bodyarg=funcdef.body_type is not None

  File "/usr/lib/python2.7/site-packages/wsme/rest/json.py", line 219, in parse
    jdata = json.loads(s)

  File "/usr/lib64/python2.7/site-packages/simplejson/__init__.py", line 501, in loads
    return _default_decoder.decode(s)

  File "/usr/lib64/python2.7/site-packages/simplejson/decoder.py", line 370, in decode
    obj, end = self.raw_decode(s)

  File "/usr/lib64/python2.7/site-packages/simplejson/decoder.py", line 393, in raw_decode
    return self.scan_once(s, idx=_w(s, idx).end())

JSONDecodeError: Invalid control character '\n' at: line 1 column 149 (char 148)

Comment 2 Nicolas Hicher 2016-01-12 20:06:42 UTC
Hello,

I have this error with the last 7.2 to, a more precise debug message:

///lib/dracut/hooks/pre-mount/50-init.sh@210(install_bootloader) partprobe /dev/sda                                                                            
dracut-pre-mount Error: Error informing the kernel about modifications to partition /dev/sda1 - Device or resource busy.  This means Linux won't know about any changes you made to /dev/sda1 until you reboot -- so you shouldn't mount it or use it in any way before rebooting.

I tried to delete the hdd, recreate it (it's a virtual env) but without success.

Do you have any advice to fix this issue ?

Thanks.

Nico

Comment 6 Hugh Brock 2016-03-21 11:40:05 UTC
Lucas, did we not fix this already?

Comment 7 Lucas Alvares Gomes 2016-03-24 16:16:10 UTC
(In reply to Hugh Brock from comment #6)
> Lucas, did we not fix this already?

I believe so, the fact that the logs points to the bash ramdisk I believe this was tested on OSP7 ?

It's now been targeting OSP8 so we probably need to retest this.

...

Hi Nicolas,

Can you please confirm if this have been fixed on OSP8?

Comment 8 Mike Burns 2016-04-07 21:00:12 UTC
This bug did not make the OSP 8.0 release.  It is being deferred to OSP 10.