You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@whirr.apache.org by "Zach Bailey (JIRA)" <ji...@apache.org> on 2010/09/21 18:56:36 UTC
[jira] Issue Comment Edited: (WHIRR-96) EBS cluster doesn't work
with CDH3 on Lucid
[ https://issues.apache.org/jira/browse/WHIRR-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12913076#action_12913076 ]
Zach Bailey edited comment on WHIRR-96 at 9/21/10 12:56 PM:
------------------------------------------------------------
Followed the instructions on the page above to the letter besides using a different cluster name. When starting the cluster, the instances start correctly and the volumes are attached fine:
{{Waiting for 1 instances in role nn,snn,jt to start
.....................................nn,snn,jt instances started
Waiting for 2 instances in role dn,tt to start
.......................................dn,tt instances started
Waiting 10 seconds before attaching storage
Attaching storage to i-eb5a6581
Attaching vol-9a3e17f3 to i-eb5a6581
Attaching vol-9c3e17f5 to i-eb5a6581
Attaching storage to i-df5a65b5
Attaching vol-923e17fb to i-df5a65b5
Attaching vol-943e17fd to i-df5a65b5
Attaching storage to i-dd5a65b7
Attaching vol-963e17ff to i-dd5a65b7
Attaching vol-68311801 to i-dd5a65b7
nn vol-9a3e17f3 250 snap-76cafa1d us-east-1a in-use 2010-09-21T14:24:20.000Z None
nn vol-9c3e17f5 250 snap-76cafa1d us-east-1a in-use 2010-09-21T14:24:20.000Z None
dn vol-923e17fb 250 snap-76cafa1d us-east-1a in-use 2010-09-21T14:24:39.000Z None
dn vol-943e17fd 250 snap-76cafa1d us-east-1a in-use 2010-09-21T14:24:42.000Z None
dn vol-963e17ff 250 snap-76cafa1d us-east-1a in-use 2010-09-21T14:24:45.000Z None
dn vol-68311801 250 snap-76cafa1d us-east-1a in-use 2010-09-21T14:24:46.000Z None}}
However, the next part where the scripts wait for the jobtracker to start time out:
{{Waiting for jobtracker to start
.....................................................................................................................................................................................................................................................................................................Timeout while waiting for Hadoop to start. Please check logs on cluster.}}
Checking /var/log/messages on the cluster NN yield the following error spamming the logs approx every 10 seconds:
{{Sep 21 16:35:59 domU-12-31-39-06-18-D1 ec2: #############################################################
Sep 21 16:37:21 domU-12-31-39-06-18-D1 kernel: [ 88.139988] GFS2: path_lookup on /dev/sdk returned error -2
Sep 21 16:37:31 domU-12-31-39-06-18-D1 kernel: [ 98.145469] GFS2: path_lookup on /dev/sdk returned error -2
Sep 21 16:37:41 domU-12-31-39-06-18-D1 kernel: [ 108.151421] GFS2: path_lookup on /dev/sdk returned error -2
Sep 21 16:37:51 domU-12-31-39-06-18-D1 kernel: [ 118.178490] GFS2: gfs2 mount does not exist
Sep 21 16:38:02 domU-12-31-39-06-18-D1 kernel: [ 128.205265] GFS2: gfs2 mount does not exist
Sep 21 16:38:12 domU-12-31-39-06-18-D1 kernel: [ 138.228104] GFS2: gfs2 mount does not exist
Sep 21 16:38:22 domU-12-31-39-06-18-D1 kernel: [ 148.252729] GFS2: gfs2 mount does not exist
Sep 21 16:38:32 domU-12-31-39-06-18-D1 kernel: [ 158.277586] GFS2: gfs2 mount does not exist
Sep 21 16:38:42 domU-12-31-39-06-18-D1 kernel: [ 168.311393] GFS2: gfs2 mount does not exist
Sep 21 16:38:52 domU-12-31-39-06-18-D1 kernel: [ 178.329587] GFS2: gfs2 mount does not exist
Sep 21 16:39:02 domU-12-31-39-06-18-D1 kernel: [ 188.349149] GFS2: gfs2 mount does not exist
Sep 21 16:39:12 domU-12-31-39-06-18-D1 kernel: [ 198.369786] GFS2: gfs2 mount does not exist
Sep 21 16:39:22 domU-12-31-39-06-18-D1 kernel: [ 208.389564] GFS2: gfs2 mount does not exist
Sep 21 16:39:32 domU-12-31-39-06-18-D1 kernel: [ 218.409901] GFS2: gfs2 mount does not exist}}
was (Author: znbailey):
Followed the instructions on the page above to the letter besides using a different cluster name. When starting the cluster, the instances start correctly and the volumes are attached fine:
{{
Waiting for 1 instances in role nn,snn,jt to start
.....................................nn,snn,jt instances started
Waiting for 2 instances in role dn,tt to start
.......................................dn,tt instances started
Waiting 10 seconds before attaching storage
Attaching storage to i-eb5a6581
Attaching vol-9a3e17f3 to i-eb5a6581
Attaching vol-9c3e17f5 to i-eb5a6581
Attaching storage to i-df5a65b5
Attaching vol-923e17fb to i-df5a65b5
Attaching vol-943e17fd to i-df5a65b5
Attaching storage to i-dd5a65b7
Attaching vol-963e17ff to i-dd5a65b7
Attaching vol-68311801 to i-dd5a65b7
nn vol-9a3e17f3 250 snap-76cafa1d us-east-1a in-use 2010-09-21T14:24:20.000Z None
nn vol-9c3e17f5 250 snap-76cafa1d us-east-1a in-use 2010-09-21T14:24:20.000Z None
dn vol-923e17fb 250 snap-76cafa1d us-east-1a in-use 2010-09-21T14:24:39.000Z None
dn vol-943e17fd 250 snap-76cafa1d us-east-1a in-use 2010-09-21T14:24:42.000Z None
dn vol-963e17ff 250 snap-76cafa1d us-east-1a in-use 2010-09-21T14:24:45.000Z None
dn vol-68311801 250 snap-76cafa1d us-east-1a in-use 2010-09-21T14:24:46.000Z None
}}
However, the next part where the scripts wait for the jobtracker to start time out:
{{
Waiting for jobtracker to start
.....................................................................................................................................................................................................................................................................................................Timeout while waiting for Hadoop to start. Please check logs on cluster.
}}
Checking /var/log/messages on the cluster NN yield the following error spamming the logs approx every 10 seconds:
{{
ep 21 16:35:59 domU-12-31-39-06-18-D1 ec2: #############################################################
Sep 21 16:37:21 domU-12-31-39-06-18-D1 kernel: [ 88.139988] GFS2: path_lookup on /dev/sdk returned error -2
Sep 21 16:37:31 domU-12-31-39-06-18-D1 kernel: [ 98.145469] GFS2: path_lookup on /dev/sdk returned error -2
Sep 21 16:37:41 domU-12-31-39-06-18-D1 kernel: [ 108.151421] GFS2: path_lookup on /dev/sdk returned error -2
Sep 21 16:37:51 domU-12-31-39-06-18-D1 kernel: [ 118.178490] GFS2: gfs2 mount does not exist
Sep 21 16:38:02 domU-12-31-39-06-18-D1 kernel: [ 128.205265] GFS2: gfs2 mount does not exist
Sep 21 16:38:12 domU-12-31-39-06-18-D1 kernel: [ 138.228104] GFS2: gfs2 mount does not exist
Sep 21 16:38:22 domU-12-31-39-06-18-D1 kernel: [ 148.252729] GFS2: gfs2 mount does not exist
Sep 21 16:38:32 domU-12-31-39-06-18-D1 kernel: [ 158.277586] GFS2: gfs2 mount does not exist
Sep 21 16:38:42 domU-12-31-39-06-18-D1 kernel: [ 168.311393] GFS2: gfs2 mount does not exist
Sep 21 16:38:52 domU-12-31-39-06-18-D1 kernel: [ 178.329587] GFS2: gfs2 mount does not exist
Sep 21 16:39:02 domU-12-31-39-06-18-D1 kernel: [ 188.349149] GFS2: gfs2 mount does not exist
Sep 21 16:39:12 domU-12-31-39-06-18-D1 kernel: [ 198.369786] GFS2: gfs2 mount does not exist
Sep 21 16:39:22 domU-12-31-39-06-18-D1 kernel: [ 208.389564] GFS2: gfs2 mount does not exist
Sep 21 16:39:32 domU-12-31-39-06-18-D1 kernel: [ 218.409901] GFS2: gfs2 mount does not exist
}}
> EBS cluster doesn't work with CDH3 on Lucid
> -------------------------------------------
>
> Key: WHIRR-96
> URL: https://issues.apache.org/jira/browse/WHIRR-96
> Project: Whirr
> Issue Type: Bug
> Components: contrib/python
> Reporter: Tom White
>
> Following the instructions with https://docs.cloudera.com/display/DOC/Using+Persistent+Clusters and ami-2d4aa444 gives "Timeout while waiting for Hadoop to start. Please check logs on cluster."
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.