This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 1292598 - chroot: failed to run command '/bin/bash': No such file or directory [NEEDINFO]
chroot: failed to run command '/bin/bash': No such file or directory
Status: CLOSED INSUFFICIENT_DATA
Product: Red Hat OpenStack
Classification: Red Hat
Component: rhosp-director (Show other bugs)
7.0 (Kilo)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: 10.0 (Newton)
Assigned To: Lucas Alvares Gomes
Shai Revivo
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-12-17 16:34 EST by Nicolas Hicher
Modified: 2016-05-19 06:24 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-05-19 06:24:19 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
lmartins: needinfo? (nhicher)


Attachments (Terms of Use)
screenshot and templates (110.00 KB, application/x-tar)
2015-12-17 16:34 EST, Nicolas Hicher
no flags Details

  None (edit)
Description Nicolas Hicher 2015-12-17 16:34:54 EST
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 15:06:42 EST
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 07:40:05 EDT
Lucas, did we not fix this already?
Comment 7 Lucas Alvares Gomes 2016-03-24 12:16:10 EDT
(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 17:00:12 EDT
This bug did not make the OSP 8.0 release.  It is being deferred to OSP 10.

Note You need to log in before you can comment on or make changes to this bug.