[ceph-users] ceph-deploy error

[Vikas Rana]

Hi there,
While upgrading from jewel to luminous, all packages wereupgraded but while
adding MGR with cluster name CEPHDR, it fails. It works with default
cluster name CEPH

root@vtier-P-node1:~# sudo su - ceph-deploy
ceph-deploy@vtier-P-node1:~$ ceph-deploy --ceph-conf /etc/ceph/cephdr.conf
mgr create vtier-P-node1
[ceph_deploy.conf][DEBUG ] found configuration file at:
/home/ceph-deploy/.cephdeploy.conf
[ceph_deploy.cli][INFO  ] Invoked (2.0.1): /usr/bin/ceph-deploy --ceph-conf
/etc/ceph/cephdr.conf mgr create vtier-P-node1
[ceph_deploy.cli][INFO  ] ceph-deploy options:
[ceph_deploy.cli][INFO  ]  username  : None
[ceph_deploy.cli][INFO  ]  verbose   : False
[ceph_deploy.cli][INFO  ]  mgr   :
[('vtier-P-node1', 'vtier-P-node1')]
[ceph_deploy.cli][INFO  ]  overwrite_conf: False
[ceph_deploy.cli][INFO  ]  subcommand: create
[ceph_deploy.cli][INFO  ]  quiet : False
[ceph_deploy.cli][INFO  ]  cd_conf   :

[ceph_deploy.cli][INFO  ]  cluster   : ceph
[ceph_deploy.cli][INFO  ]  func  : 
[ceph_deploy.cli][INFO  ]  ceph_conf :
/etc/ceph/cephdr.conf
[ceph_deploy.cli][INFO  ]  default_release   : False
[ceph_deploy.mgr][DEBUG ] Deploying mgr, cluster ceph hosts
vtier-P-node1:vtier-P-node1
[ceph_deploy][ERROR ] RuntimeError: bootstrap-mgr keyring not found; run
'gatherkeys'

ceph-deploy@vtier-P-node1:~$ ceph-deploy --ceph-conf /etc/ceph/cephdr.conf
gatherkeys vtier-P-node1
[ceph_deploy.conf][DEBUG ] found configuration file at:
/home/ceph-deploy/.cephdeploy.conf
[ceph_deploy.cli][INFO  ] Invoked (2.0.1): /usr/bin/ceph-deploy --ceph-conf
/etc/ceph/cephdr.conf gatherkeys vtier-P-node1
[ceph_deploy.cli][INFO  ] ceph-deploy options:
[ceph_deploy.cli][INFO  ]  username  : None
[ceph_deploy.cli][INFO  ]  verbose   : False
[ceph_deploy.cli][INFO  ]  overwrite_conf: False
[ceph_deploy.cli][INFO  ]  quiet : False
[ceph_deploy.cli][INFO  ]  cd_conf   :

[ceph_deploy.cli][INFO  ]  cluster   : ceph
[ceph_deploy.cli][INFO  ]  mon   : ['vtier-P-node1']
[ceph_deploy.cli][INFO  ]  func  : 
[ceph_deploy.cli][INFO  ]  ceph_conf :
/etc/ceph/cephdr.conf
[ceph_deploy.cli][INFO  ]  default_release   : False
[ceph_deploy.gatherkeys][INFO  ] Storing keys in temp directory
/tmp/tmpqAmHsz
[vtier-P-node1][DEBUG ] connection detected need for sudo
[vtier-P-node1][DEBUG ] connected to host: vtier-P-node1
[vtier-P-node1][DEBUG ] detect platform information from remote host
[vtier-P-node1][DEBUG ] detect machine type
[vtier-P-node1][DEBUG ] find the location of an executable
[vtier-P-node1][INFO  ] Running command: sudo /sbin/initctl version
[vtier-P-node1][DEBUG ] get remote short hostname
[vtier-P-node1][DEBUG ] fetch remote file
[ceph_deploy.gatherkeys][WARNIN] No mon key found in host: vtier-P-node1
[ceph_deploy.gatherkeys][ERROR ] Failed to connect to host:vtier-P-node1
[ceph_deploy.gatherkeys][INFO  ] Destroy temp directory /tmp/tmpqAmHsz
[ceph_deploy][ERROR ] RuntimeError: Failed to connect any mon

ceph-deploy@vtier-P-node1:~$ ceph -s
  cluster:
id: ef5cea62-e9c8-4f7b-95bb-4aea414a2ebb
health: HEALTH_WARN
no active mgr

  services:
mon: 1 daemons, quorum vtier-P-node1
mgr: no daemons active
osd: 3 osds: 1 up, 1 in

  data:
pools:   0 pools, 0 pgs
objects: 0 objects, 0B
usage:   0B used, 0B / 0B avail
pgs:


Thanks,
-Vikas
___
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com

Re: [ceph-users] Ceph-Deploy error on 15/71 stage

[Eugen Block]

Hi Jones,


Just to make things clear: are you so telling me that it is completely
impossible to have a ceph "volume" in non-dedicated devices, sharing space
with, for instance, the nodes swap, boot or main partition?

And so the only possible way to have a functioning ceph distributed
filesystem working would be by having in each node at least one disk
dedicated for the operational system and another, independent disk
dedicated to the ceph filesystem?


I don't think it's completely impossible, but it would require code  
changes in SES and DeepSea and that seems quite challenging.


But if you don't have to stick with SES/DeepSea and instead build your  
cluster manually, you could create a logical volume on your spare  
partition and deploy OSDs with ceph-volume lvm.


This could be something like this:

---cut here---

# create logical volume "osd4" on volume group "vg0"
ceph-2:~ # lvcreate -n osd4 -L 1G vg0
  Logical volume "osd4" created.


# prepare lvm for bluestore
ceph-2:~ # ceph-volume lvm prepare --bluestore --data vg0/osd4
Running command: /usr/bin/ceph-authtool --gen-print-key
Running command: /usr/bin/ceph --cluster ceph --name  
client.bootstrap-osd --keyring  
/var/lib/ceph/bootstrap-osd/ceph.keyring -i - osd new  
3b9eaa0e-9a4a-49ec-9042-34ad19a59592

Running command: /usr/bin/ceph-authtool --gen-print-key
Running command: /bin/mount -t tmpfs tmpfs /var/lib/ceph/osd/ceph-4
--> Absolute path not found for executable: restorecon
--> Ensure $PATH environment variable contains common executable locations
Running command: /bin/chown -h ceph:ceph /dev/vg0/osd4
Running command: /bin/chown -R ceph:ceph /dev/dm-4
Running command: /bin/ln -s /dev/vg0/osd4 /var/lib/ceph/osd/ceph-4/block
Running command: /usr/bin/ceph --cluster ceph --name  
client.bootstrap-osd --keyring  
/var/lib/ceph/bootstrap-osd/ceph.keyring mon getmap -o  
/var/lib/ceph/osd/ceph-4/activate.monmap

 stderr: got monmap epoch 2
Running command: /usr/bin/ceph-authtool  
/var/lib/ceph/osd/ceph-4/keyring --create-keyring --name osd.4  
--add-key AQD3j49bDzsFIBAAsXQjhbwqFQwt/Vqq9VOnsw==

 stdout: creating /var/lib/ceph/osd/ceph-4/keyring
added entity osd.4 auth auth(auid = 18446744073709551615  
key=AQD3j49bDzsFIBAAsXQjhbwqFQwt/Vqq9VOnsw== with 0 caps)

Running command: /bin/chown -R ceph:ceph /var/lib/ceph/osd/ceph-4/keyring
Running command: /bin/chown -R ceph:ceph /var/lib/ceph/osd/ceph-4/
Running command: /usr/bin/ceph-osd --cluster ceph --osd-objectstore  
bluestore --mkfs -i 4 --monmap  
/var/lib/ceph/osd/ceph-4/activate.monmap --keyfile - --osd-data  
/var/lib/ceph/osd/ceph-4/ --osd-uuid  
3b9eaa0e-9a4a-49ec-9042-34ad19a59592 --setuser ceph --setgroup ceph

--> ceph-volume lvm prepare successful for: vg0/osd4


# activate lvm OSD
ceph-2:~ # ceph-volume lvm activate 4 3b9eaa0e-9a4a-49ec-9042-34ad19a59592
Running command: /usr/bin/ceph-bluestore-tool --cluster=ceph  
prime-osd-dir --dev /dev/vg0/osd4 --path /var/lib/ceph/osd/ceph-4  
--no-mon-config

Running command: /bin/ln -snf /dev/vg0/osd4 /var/lib/ceph/osd/ceph-4/block
Running command: /bin/chown -h ceph:ceph /var/lib/ceph/osd/ceph-4/block
Running command: /bin/chown -R ceph:ceph /dev/dm-4
Running command: /bin/chown -R ceph:ceph /var/lib/ceph/osd/ceph-4
Running command: /bin/systemctl enable  
ceph-volume@lvm-4-3b9eaa0e-9a4a-49ec-9042-34ad19a59592
 stderr: Created symlink  
/etc/systemd/system/multi-user.target.wants/ceph-volume@lvm-4-3b9eaa0e-9a4a-49ec-9042-34ad19a59592.service →  
/usr/lib/systemd/system/ceph-volume@.service.

Running command: /bin/systemctl enable --runtime ceph-osd@4
 stderr: Created symlink  
/run/systemd/system/ceph-osd.target.wants/ceph-osd@4.service →  
/usr/lib/systemd/system/ceph-osd@.service.

Running command: /bin/systemctl start ceph-osd@4
--> ceph-volume lvm activate successful for osd ID: 4
---cut here---

Instead of running "prepare" and "activate" separately you can run  
"ceph-volume lvm create ...", this will execute both steps and launch  
the OSD.


This way you don't need further partitions, but you won't be able to  
use deepsea for automated deployment since SES doesn't support lvm  
based OSDs (yet).


So you should not give up, there is a way :-)

Note: because of a compatibility issue with python3 and ceph-volume  
you should use at least


ceph-2:~ # ceph --version
ceph version 13.2.1-106-g9a1fcb1b6a  
(9a1fcb1b6a6682c3323a38c52898a94e121f6c15) mimic (stable)


Hope this helps!

Regards,
Eugen


Zitat von Jones de Andrade :


Hi Eugen.

Just tried everything again here by removing the /sda4 partitions and
letting it so that either salt-run proposal-populate or salt-run state.orch
ceph.stage.configure could try to find the free space on the partitions to
work with: unsuccessfully again. :(

Just to make things clear: are you so telling me that it is completely
impossible to have a ceph "volume" in non-dedicated devices, sharing space
with, for instance, the nodes swap, boot or main partition?

And so the only possible way to 

Re: [ceph-users] Ceph-Deploy error on 15/71 stage

[Jones de Andrade]

Hi Eugen.

Just tried everything again here by removing the /sda4 partitions and
letting it so that either salt-run proposal-populate or salt-run state.orch
ceph.stage.configure could try to find the free space on the partitions to
work with: unsuccessfully again. :(

Just to make things clear: are you so telling me that it is completely
impossible to have a ceph "volume" in non-dedicated devices, sharing space
with, for instance, the nodes swap, boot or main partition?

And so the only possible way to have a functioning ceph distributed
filesystem working would be by having in each node at least one disk
dedicated for the operational system and another, independent disk
dedicated to the ceph filesystem?

That would be a awful drawback in our plans if real, but if there is no
other way, we will have to just give up. Just, please, answer this two
questions clearly, before we capitulate?  :(

Anyway, thanks a lot, once again,

Jones

On Mon, Sep 3, 2018 at 5:39 AM Eugen Block  wrote:

> Hi Jones,
>
> I still don't think creating an OSD on a partition will work. The
> reason is that SES creates an additional partition per OSD resulting
> in something like this:
>
> vdb   253:16   05G  0 disk
> ├─vdb1253:17   0  100M  0 part /var/lib/ceph/osd/ceph-1
> └─vdb2253:18   0  4,9G  0 part
>
> Even with external block.db and wal.db on additional devices you would
> still need two partitions for the OSD. I'm afraid with your setup this
> can't work.
>
> Regards,
> Eugen
>
___
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com

Re: [ceph-users] Ceph-Deploy error on 15/71 stage

[Eugen Block]

Hi Jones,

I still don't think creating an OSD on a partition will work. The  
reason is that SES creates an additional partition per OSD resulting  
in something like this:


vdb   253:16   05G  0 disk
├─vdb1253:17   0  100M  0 part /var/lib/ceph/osd/ceph-1
└─vdb2253:18   0  4,9G  0 part

Even with external block.db and wal.db on additional devices you would  
still need two partitions for the OSD. I'm afraid with your setup this  
can't work.


Regards,
Eugen


Zitat von Jones de Andrade :


Hi Eugen.

Sorry for the double email, but now it stoped complaining (too much) about
repositories and NTP and moved forward again.

So, I ran on master:

**


























































*# salt-run state.orch ceph.stage.deployfirewall :
disabledapparmor : disabledfsid :
validpublic_network   : validcluster_network  :
validcluster_interface: validmonitors :
validmgrs : validstorage  :
validganesha  : validmaster_role  :
validtime_server  : validfqdn :
valid[ERROR   ] {'out': 'highstate', 'ret': {'bohemia.iq.ufrgs.br
':
{'file_|-/var/lib/ceph/bootstrap-osd/ceph.keyring_|-/var/lib/ceph/bootstrap-osd/ceph.keyring_|-managed':
{'changes': {}, 'pchanges': {}, 'comment': 'File
/var/lib/ceph/bootstrap-osd/ceph.keyring is in the correct state', 'name':
'/var/lib/ceph/bootstrap-osd/ceph.keyring', 'result': True, '__sls__':
'ceph.osd.keyring.default', '__run_num__': 0, 'start_time':
'12:43:51.639582', 'duration': 40.998, '__id__':
'/var/lib/ceph/bootstrap-osd/ceph.keyring'},
'file_|-/etc/ceph/ceph.client.storage.keyring_|-/etc/ceph/ceph.client.storage.keyring_|-managed':
{'changes': {}, 'pchanges': {}, 'comment': 'File
/etc/ceph/ceph.client.storage.keyring is in the correct state', 'name':
'/etc/ceph/ceph.client.storage.keyring', 'result': True, '__sls__':
'ceph.osd.keyring.default', '__run_num__': 1, 'start_time':
'12:43:51.680857', 'duration': 19.265, '__id__':
'/etc/ceph/ceph.client.storage.keyring'}, 'module_|-deploy
OSDs_|-osd.deploy_|-run': {'name': 'osd.deploy', 'changes': {}, 'comment':
'Module function osd.deploy threw an exception. Exception: Mine on
bohemia.iq.ufrgs.br  for cephdisks.list',
'result': False, '__sls__': 'ceph.osd.default', '__run_num__': 2,
'start_time': '12:43:51.701179', 'duration': 38.789, '__id__': 'deploy
OSDs'}}, 'torcello.iq.ufrgs.br ':
{'file_|-/var/lib/ceph/bootstrap-osd/ceph.keyring_|-/var/lib/ceph/bootstrap-osd/ceph.keyring_|-managed':
{'changes': {}, 'pchanges': {}, 'comment': 'File
/var/lib/ceph/bootstrap-osd/ceph.keyring is in the correct state', 'name':
'/var/lib/ceph/bootstrap-osd/ceph.keyring', 'result': True, '__sls__':
'ceph.osd.keyring.default', '__run_num__': 0, 'start_time':
'12:43:51.768119', 'duration': 39.544, '__id__':
'/var/lib/ceph/bootstrap-osd/ceph.keyring'},
'file_|-/etc/ceph/ceph.client.storage.keyring_|-/etc/ceph/ceph.client.storage.keyring_|-managed':
{'changes': {}, 'pchanges': {}, 'comment': 'File
/etc/ceph/ceph.client.storage.keyring is in the correct state', 'name':
'/etc/ceph/ceph.client.storage.keyring', 'result': True, '__sls__':
'ceph.osd.keyring.default', '__run_num__': 1, 'start_time':
'12:43:51.807977', 'duration': 16.645, '__id__':
'/etc/ceph/ceph.client.storage.keyring'}, 'module_|-deploy
OSDs_|-osd.deploy_|-run': {'name': 'osd.deploy', 'changes': {}, 'comment':
'Module function osd.deploy threw an exception. Exception: Mine on
torcello.iq.ufrgs.br  for cephdisks.list',
'result': False, '__sls__': 'ceph.osd.default', '__run_num__': 2,
'start_time': '12:43:51.825744', 'duration': 39.334, '__id__': 'deploy
OSDs'}}, 'patricia.iq.ufrgs.br ':
{'file_|-/var/lib/ceph/bootstrap-osd/ceph.keyring_|-/var/lib/ceph/bootstrap-osd/ceph.keyring_|-managed':
{'changes': {}, 'pchanges': {}, 'comment': 'File
/var/lib/ceph/bootstrap-osd/ceph.keyring is in the correct state', 'name':
'/var/lib/ceph/bootstrap-osd/ceph.keyring', 'result': True, '__sls__':
'ceph.osd.keyring.default', '__run_num__': 0, 'start_time':
'12:43:52.039506', 'duration': 41.975, '__id__':
'/var/lib/ceph/bootstrap-osd/ceph.keyring'},
'file_|-/etc/ceph/ceph.client.storage.keyring_|-/et in
advancec/ceph/ceph.client.storage.keyring_|-managed': {'changes': {},
'pchanges': {}, 'comment': 'File /etc/ceph/ceph.client.storage.keyring is
in the correct state', 'name': '/etc/ceph/ceph.client.storage.keyring',
'result': True, '__sls__': 'ceph.osd.keyring.default', '__run_num__': 1,
'start_time': '12:43:52.081767', 'duration': 17.852, '__id__':
'/etc/ceph/ceph.client.storage.keyring'}, 'module_|-deploy
OSDs_|-osd.deploy_|-run': {'name': 'osd.deploy', 'changes': {}, 'comment':
'Module function osd.deploy threw 

Re: [ceph-users] Ceph-Deploy error on 15/71 stage

[Jones de Andrade]

Hi Eugen.

Entirely my missunderstanding, I thought there would be something at boot
time (what would certainly not make any sense at all). Sorry.

Before stage 3 I ran the commands you suggested on the nodes, and only one
got me the output below:

###
# grep -C5 sda4 /var/log/messages
2018-08-28T08:26:50.635077-03:00 polar kernel: [3.029809] ata2.00:
ATAPI: PLDS DVD+/-RW DU-8A5LH, 6D1M, max UDMA/133
2018-08-28T08:26:50.635080-03:00 polar kernel: [3.030616] ata2.00:
configured for UDMA/133
2018-08-28T08:26:50.635082-03:00 polar kernel: [3.038249] scsi 1:0:0:0:
CD-ROMPLDS DVD+-RW DU-8A5LH 6D1M PQ: 0 ANSI: 5
2018-08-28T08:26:50.635085-03:00 polar kernel: [3.048102] usb 1-6: new
low-speed USB device number 2 using xhci_hcd
2018-08-28T08:26:50.635095-03:00 polar kernel: [3.051408] scsi 1:0:0:0:
Attached scsi generic sg1 type 5
2018-08-28T08:26:50.635098-03:00 polar kernel: [3.079763]  sda: sda1
sda2 sda3 sda4
2018-08-28T08:26:50.635101-03:00 polar kernel: [3.080548] sd 0:0:0:0:
[sda] Attached SCSI disk
2018-08-28T08:26:50.635104-03:00 polar kernel: [3.109021] sr 1:0:0:0:
[sr0] scsi3-mmc drive: 24x/24x writer cd/rw xa/form2 cdda tray
2018-08-28T08:26:50.635106-03:00 polar kernel: [3.109025] cdrom:
Uniform CD-ROM driver Revision: 3.20
2018-08-28T08:26:50.635109-03:00 polar kernel: [3.109246] sr 1:0:0:0:
Attached scsi CD-ROM sr0
2018-08-28T08:26:50.635112-03:00 polar kernel: [3.206490] usb 1-6: New
USB device found, idVendor=413c, idProduct=2113
--
2018-08-28T10:11:10.512604-03:00 polar os-prober: debug: running
/usr/lib/os-probes/mounted/83haiku on mounted /dev/sda1
2018-08-28T10:11:10.516374-03:00 polar 83haiku: debug: /dev/sda1 is not a
BeFS partition: exiting
2018-08-28T10:11:10.517805-03:00 polar os-prober: debug: running
/usr/lib/os-probes/mounted/90linux-distro on mounted /dev/sda1
2018-08-28T10:11:10.523382-03:00 polar os-prober: debug: running
/usr/lib/os-probes/mounted/90solaris on mounted /dev/sda1
2018-08-28T10:11:10.529317-03:00 polar os-prober: debug: /dev/sda2: is
active swap
2018-08-28T10:11:10.539818-03:00 polar os-prober: debug: running
/usr/lib/os-probes/50mounted-tests on /dev/sda4
2018-08-28T10:11:10.669852-03:00 polar systemd-udevd[456]: Network
interface NamePolicy= disabled by default.
2018-08-28T10:11:10.705602-03:00 polar systemd-udevd[456]: Specified group
'plugdev' unknown
2018-08-28T10:11:10.812270-03:00 polar 50mounted-tests: debug: mounted
using GRUB xfs filesystem driver
2018-08-28T10:11:10.817141-03:00 polar 50mounted-tests: debug: running
subtest /usr/lib/os-probes/mounted/05efi
2018-08-28T10:11:10.832257-03:00 polar 05efi: debug: /dev/sda4 is xfs
partition: exiting
2018-08-28T10:11:10.837353-03:00 polar 50mounted-tests: debug: running
subtest /usr/lib/os-probes/mounted/10freedos
2018-08-28T10:11:10.851042-03:00 polar 10freedos: debug: /dev/sda4 is not a
FAT partition: exiting
2018-08-28T10:11:10.854580-03:00 polar 50mounted-tests: debug: running
subtest /usr/lib/os-probes/mounted/10qnx
2018-08-28T10:11:10.863539-03:00 polar 10qnx: debug: /dev/sda4 is not a
QNX4 partition: exiting
2018-08-28T10:11:10.865876-03:00 polar 50mounted-tests: debug: running
subtest /usr/lib/os-probes/mounted/20macosx
2018-08-28T10:11:10.871781-03:00 polar macosx-prober: debug: /dev/sda4 is
not an HFS+ partition: exiting
2018-08-28T10:11:10.873708-03:00 polar 50mounted-tests: debug: running
subtest /usr/lib/os-probes/mounted/20microsoft
2018-08-28T10:11:10.879146-03:00 polar 20microsoft: debug: Skipping legacy
bootloaders on UEFI system
2018-08-28T10:11:10.880798-03:00 polar 50mounted-tests: debug: running
subtest /usr/lib/os-probes/mounted/30utility
2018-08-28T10:11:10.885707-03:00 polar 30utility: debug: /dev/sda4 is not a
FAT partition: exiting
2018-08-28T10:11:10.887422-03:00 polar 50mounted-tests: debug: running
subtest
/usr/lib/os-probes/mounted/40lsb

2018-08-28T10:11:10.892547-03:00 polar 50mounted-tests: debug: running
subtest
/usr/lib/os-probes/mounted/70hurd

2018-08-28T10:11:10.897110-03:00 polar 50mounted-tests: debug: running
subtest
/usr/lib/os-probes/mounted/80minix

2018-08-28T10:11:10.901133-03:00 polar 50mounted-tests: debug: running
subtest
/usr/lib/os-probes/mounted/83haiku

2018-08-28T10:11:10.904998-03:00 polar 83haiku: debug: /dev/sda4 is not a
BeFS partition: exiting
2018-08-28T10:11:10.906289-03:00 polar 50mounted-tests: debug: running
subtest
/usr/lib/os-probes/mounted/90linux-distro

2018-08-28T10:11:10.912016-03:00 polar 50mounted-tests: debug: running
subtest
/usr/lib/os-probes/mounted/90solaris

2018-08-28T10:11:10.915838-03:00 polar 50mounted-tests: debug: running
subtest
/usr/lib/os-probes/mounted/efi

2018-08-28T10:11:11.757030-03:00 polar [RPM][4789]: erase
kernel-default-4.12.14-lp150.12.16.1.x86_64:
success

2018-08-28T10:11:11.757912-03:00 polar [RPM][4789]: Transaction ID 5b8549e8
finished:
0

--
2018-08-28T10:13:08.815753-03:00 polar kernel: [2.885213] ata2.00:
configured for

Re: [ceph-users] Ceph-Deploy error on 15/71 stage

[Eugen Block]

Hi,

I'm not sure if there's a misunderstanding. You need to track the logs  
during the osd deployment step (stage.3), that is where it fails, and  
this is where /var/log/messages could be useful. Since the deployment  
failed you have no systemd-units (ceph-osd@.service) to log  
anything.


Before running stage.3 again try something like

grep -C5 ceph-disk /var/log/messages (or messages-201808*.xz)

or

grep -C5 sda4 /var/log/messages (or messages-201808*.xz)

If that doesn't reveal anything run stage.3 again and watch the logs.

Regards,
Eugen


Zitat von Jones de Andrade :


Hi Eugen.

Ok, edited the file /etc/salt/minion, uncommented the "log_level_logfile"
line and set it to "debug" level.

Turned off the computer, waited a few minutes so that the time frame would
stand out in the /var/log/messages file, and restarted the computer.

Using vi I "greped out" (awful wording) the reboot section. From that, I
also removed most of what it seemed totally unrelated to ceph, salt,
minions, grafana, prometheus, whatever.

I got the lines below. It does not seem to complain about anything that I
can see. :(


2018-08-30T15:41:46.455383-03:00 torcello systemd[1]: systemd 234 running
in system mode. (+PAM -AUDIT +SELINUX -IMA +APPARMOR -SMACK +SYSVINIT +UTMP
+LIBCRYPTSETUP +GCRYPT -GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID -ELFUTILS
+KMOD -IDN2 -IDN default-hierarchy=hybrid)
2018-08-30T15:41:46.456330-03:00 torcello systemd[1]: Detected architecture
x86-64.
2018-08-30T15:41:46.456350-03:00 torcello systemd[1]: nss-lookup.target:
Dependency Before=nss-lookup.target dropped
2018-08-30T15:41:46.456357-03:00 torcello systemd[1]: Started Load Kernel
Modules.
2018-08-30T15:41:46.456369-03:00 torcello systemd[1]: Starting Apply Kernel
Variables...
2018-08-30T15:41:46.457230-03:00 torcello systemd[1]: Started Alertmanager
for prometheus.
2018-08-30T15:41:46.457237-03:00 torcello systemd[1]: Started Monitoring
system and time series database.
2018-08-30T15:41:46.457403-03:00 torcello systemd[1]: Starting NTP
client/server...






*2018-08-30T15:41:46.457425-03:00 torcello systemd[1]: Started Prometheus
exporter for machine metrics.2018-08-30T15:41:46.457706-03:00 torcello
prometheus[695]: level=info ts=2018-08-30T18:41:44.797896888Z
caller=main.go:225 msg="Starting Prometheus" version="(version=2.1.0,
branch=non-git, revision=non-git)"2018-08-30T15:41:46.457712-03:00 torcello
prometheus[695]: level=info ts=2018-08-30T18:41:44.797969232Z
caller=main.go:226 build_context="(go=go1.9.4, user=abuild@lamb69,
date=20180513-03:46:03)"2018-08-30T15:41:46.457719-03:00 torcello
prometheus[695]: level=info ts=2018-08-30T18:41:44.798008802Z
caller=main.go:227 host_details="(Linux 4.12.14-lp150.12.4-default #1 SMP
Tue May 22 05:17:22 UTC 2018 (66b2eda) x86_64 torcello
(none))"2018-08-30T15:41:46.457726-03:00 torcello prometheus[695]:
level=info ts=2018-08-30T18:41:44.798044088Z caller=main.go:228
fd_limits="(soft=1024, hard=4096)"2018-08-30T15:41:46.457738-03:00 torcello
prometheus[695]: level=info ts=2018-08-30T18:41:44.802067189Z
caller=web.go:383 component=web msg="Start listening for connections"
address=0.0.0.0:9090 2018-08-30T15:41:46.457745-03:00
torcello prometheus[695]: level=info ts=2018-08-30T18:41:44.802037354Z
caller=main.go:499 msg="Starting TSDB ..."*
2018-08-30T15:41:46.458145-03:00 torcello smartd[809]: Monitoring 1
ATA/SATA, 0 SCSI/SAS and 0 NVMe devices
2018-08-30T15:41:46.458321-03:00 torcello systemd[1]: Started NTP
client/server.
*2018-08-30T15:41:50.387157-03:00 torcello ceph_exporter[690]: 2018/08/30
15:41:50 Starting ceph exporter on ":9128"*
2018-08-30T15:41:52.658272-03:00 torcello wicked[905]: lo  up
2018-08-30T15:41:52.658738-03:00 torcello wicked[905]: eth0up
2018-08-30T15:41:52.659989-03:00 torcello systemd[1]: Started wicked
managed network interfaces.
2018-08-30T15:41:52.660514-03:00 torcello systemd[1]: Reached target
Network.
2018-08-30T15:41:52.667938-03:00 torcello systemd[1]: Starting OpenSSH
Daemon...
2018-08-30T15:41:52.668292-03:00 torcello systemd[1]: Reached target
Network is Online.




*2018-08-30T15:41:52.669132-03:00 torcello systemd[1]: Started Ceph cluster
monitor daemon.2018-08-30T15:41:52.669328-03:00 torcello systemd[1]:
Reached target ceph target allowing to start/stop all ceph-mon@.service
instances at once.2018-08-30T15:41:52.670346-03:00 torcello systemd[1]:
Started Ceph cluster manager daemon.2018-08-30T15:41:52.670565-03:00
torcello systemd[1]: Reached target ceph target allowing to start/stop all
ceph-mgr@.service instances at once.2018-08-30T15:41:52.670839-03:00
torcello systemd[1]: Reached target ceph target allowing to start/stop all
ceph*@.service instances at once.*
2018-08-30T15:41:52.671246-03:00 torcello systemd[1]: Starting Login and
scanning of iSCSI devices...
*2018-08-30T15:41:52.672402-03:00 torcello systemd[1]: Starting Grafana
instance...*
2018-08-30T15:41:52.678922-03:00 torcello systemd[1]: Started 

Re: [ceph-users] Ceph-Deploy error on 15/71 stage

[Jones de Andrade]

Hi Eugen.

Ok, edited the file /etc/salt/minion, uncommented the "log_level_logfile"
line and set it to "debug" level.

Turned off the computer, waited a few minutes so that the time frame would
stand out in the /var/log/messages file, and restarted the computer.

Using vi I "greped out" (awful wording) the reboot section. From that, I
also removed most of what it seemed totally unrelated to ceph, salt,
minions, grafana, prometheus, whatever.

I got the lines below. It does not seem to complain about anything that I
can see. :(


2018-08-30T15:41:46.455383-03:00 torcello systemd[1]: systemd 234 running
in system mode. (+PAM -AUDIT +SELINUX -IMA +APPARMOR -SMACK +SYSVINIT +UTMP
+LIBCRYPTSETUP +GCRYPT -GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID -ELFUTILS
+KMOD -IDN2 -IDN default-hierarchy=hybrid)
2018-08-30T15:41:46.456330-03:00 torcello systemd[1]: Detected architecture
x86-64.
2018-08-30T15:41:46.456350-03:00 torcello systemd[1]: nss-lookup.target:
Dependency Before=nss-lookup.target dropped
2018-08-30T15:41:46.456357-03:00 torcello systemd[1]: Started Load Kernel
Modules.
2018-08-30T15:41:46.456369-03:00 torcello systemd[1]: Starting Apply Kernel
Variables...
2018-08-30T15:41:46.457230-03:00 torcello systemd[1]: Started Alertmanager
for prometheus.
2018-08-30T15:41:46.457237-03:00 torcello systemd[1]: Started Monitoring
system and time series database.
2018-08-30T15:41:46.457403-03:00 torcello systemd[1]: Starting NTP
client/server...






*2018-08-30T15:41:46.457425-03:00 torcello systemd[1]: Started Prometheus
exporter for machine metrics.2018-08-30T15:41:46.457706-03:00 torcello
prometheus[695]: level=info ts=2018-08-30T18:41:44.797896888Z
caller=main.go:225 msg="Starting Prometheus" version="(version=2.1.0,
branch=non-git, revision=non-git)"2018-08-30T15:41:46.457712-03:00 torcello
prometheus[695]: level=info ts=2018-08-30T18:41:44.797969232Z
caller=main.go:226 build_context="(go=go1.9.4, user=abuild@lamb69,
date=20180513-03:46:03)"2018-08-30T15:41:46.457719-03:00 torcello
prometheus[695]: level=info ts=2018-08-30T18:41:44.798008802Z
caller=main.go:227 host_details="(Linux 4.12.14-lp150.12.4-default #1 SMP
Tue May 22 05:17:22 UTC 2018 (66b2eda) x86_64 torcello
(none))"2018-08-30T15:41:46.457726-03:00 torcello prometheus[695]:
level=info ts=2018-08-30T18:41:44.798044088Z caller=main.go:228
fd_limits="(soft=1024, hard=4096)"2018-08-30T15:41:46.457738-03:00 torcello
prometheus[695]: level=info ts=2018-08-30T18:41:44.802067189Z
caller=web.go:383 component=web msg="Start listening for connections"
address=0.0.0.0:9090 2018-08-30T15:41:46.457745-03:00
torcello prometheus[695]: level=info ts=2018-08-30T18:41:44.802037354Z
caller=main.go:499 msg="Starting TSDB ..."*
2018-08-30T15:41:46.458145-03:00 torcello smartd[809]: Monitoring 1
ATA/SATA, 0 SCSI/SAS and 0 NVMe devices
2018-08-30T15:41:46.458321-03:00 torcello systemd[1]: Started NTP
client/server.
*2018-08-30T15:41:50.387157-03:00 torcello ceph_exporter[690]: 2018/08/30
15:41:50 Starting ceph exporter on ":9128"*
2018-08-30T15:41:52.658272-03:00 torcello wicked[905]: lo  up
2018-08-30T15:41:52.658738-03:00 torcello wicked[905]: eth0up
2018-08-30T15:41:52.659989-03:00 torcello systemd[1]: Started wicked
managed network interfaces.
2018-08-30T15:41:52.660514-03:00 torcello systemd[1]: Reached target
Network.
2018-08-30T15:41:52.667938-03:00 torcello systemd[1]: Starting OpenSSH
Daemon...
2018-08-30T15:41:52.668292-03:00 torcello systemd[1]: Reached target
Network is Online.




*2018-08-30T15:41:52.669132-03:00 torcello systemd[1]: Started Ceph cluster
monitor daemon.2018-08-30T15:41:52.669328-03:00 torcello systemd[1]:
Reached target ceph target allowing to start/stop all ceph-mon@.service
instances at once.2018-08-30T15:41:52.670346-03:00 torcello systemd[1]:
Started Ceph cluster manager daemon.2018-08-30T15:41:52.670565-03:00
torcello systemd[1]: Reached target ceph target allowing to start/stop all
ceph-mgr@.service instances at once.2018-08-30T15:41:52.670839-03:00
torcello systemd[1]: Reached target ceph target allowing to start/stop all
ceph*@.service instances at once.*
2018-08-30T15:41:52.671246-03:00 torcello systemd[1]: Starting Login and
scanning of iSCSI devices...
*2018-08-30T15:41:52.672402-03:00 torcello systemd[1]: Starting Grafana
instance...*
2018-08-30T15:41:52.678922-03:00 torcello systemd[1]: Started Backup of
/etc/sysconfig.
2018-08-30T15:41:52.679109-03:00 torcello systemd[1]: Reached target Timers.
*2018-08-30T15:41:52.679630-03:00 torcello systemd[1]: Started The Salt
API.*
2018-08-30T15:41:52.692944-03:00 torcello systemd[1]: Starting Postfix Mail
Transport Agent...
*2018-08-30T15:41:52.694687-03:00 torcello systemd[1]: Started The Salt
Master Server.*
*2018-08-30T15:41:52.696821-03:00 torcello systemd[1]: Starting The Salt
Minion...*
2018-08-30T15:41:52.772750-03:00 torcello sshd-gen-keys-start[1408]:
Checking for missing server keys in /etc/ssh

Re: [ceph-users] Ceph-Deploy error on 15/71 stage

[Eugen Block]

Hi,


So, it only contains logs concerning the node itself (is it correct? sincer
node01 is also the master, I was expecting it to have logs from the other
too) and, moreover, no ceph-osd* files. Also, I'm looking the logs I have
available, and nothing "shines out" (sorry for my poor english) as a
possible error.


the logging is not configured to be centralised per default, you would  
have to configure that yourself.


Regarding the OSDs, if there are OSD logs created, they're created on  
the OSD nodes, not on the master. But since the OSD deployment fails,  
there probably are no OSD specific logs yet. So you'll have to take a  
look into the syslog (/var/log/messages), that's where the salt-minion  
reports its attempts to create the OSDs. Chances are high that you'll  
find the root cause in here.


If the output is not enough, set the log-level to debug:

osd-1:~ # grep -E "^log_level" /etc/salt/minion
log_level: debug


Regards,
Eugen


Zitat von Jones de Andrade :


Hi Eugen.

Sorry for the delay in answering.

Just looked in the /var/log/ceph/ directory. It only contains the following
files (for example on node01):

###
# ls -lart
total 3864
-rw--- 1 ceph ceph 904 ago 24 13:11 ceph.audit.log-20180829.xz
drwxr-xr-x 1 root root 898 ago 28 10:07 ..
-rw-r--r-- 1 ceph ceph  189464 ago 28 23:59 ceph-mon.node01.log-20180829.xz
-rw--- 1 ceph ceph   24360 ago 28 23:59 ceph.log-20180829.xz
-rw-r--r-- 1 ceph ceph   48584 ago 29 00:00 ceph-mgr.node01.log-20180829.xz
-rw--- 1 ceph ceph   0 ago 29 00:00 ceph.audit.log
drwxrws--T 1 ceph ceph 352 ago 29 00:00 .
-rw-r--r-- 1 ceph ceph 1908122 ago 29 12:46 ceph-mon.node01.log
-rw--- 1 ceph ceph  175229 ago 29 12:48 ceph.log
-rw-r--r-- 1 ceph ceph 1599920 ago 29 12:49 ceph-mgr.node01.log
###

So, it only contains logs concerning the node itself (is it correct? sincer
node01 is also the master, I was expecting it to have logs from the other
too) and, moreover, no ceph-osd* files. Also, I'm looking the logs I have
available, and nothing "shines out" (sorry for my poor english) as a
possible error.

Any suggestion on how to proceed?

Thanks a lot in advance,

Jones


On Mon, Aug 27, 2018 at 5:29 AM Eugen Block  wrote:


Hi Jones,

all ceph logs are in the directory /var/log/ceph/, each daemon has its
own log file, e.g. OSD logs are named ceph-osd.*.

I haven't tried it but I don't think SUSE Enterprise Storage deploys
OSDs on partitioned disks. Is there a way to attach a second disk to
the OSD nodes, maybe via USB or something?

Although this thread is ceph related it is referring to a specific
product, so I would recommend to post your question in the SUSE forum
[1].

Regards,
Eugen

[1] https://forums.suse.com/forumdisplay.php?99-SUSE-Enterprise-Storage

Zitat von Jones de Andrade :

> Hi Eugen.
>
> Thanks for the suggestion. I'll look for the logs (since it's our first
> attempt with ceph, I'll have to discover where they are, but no problem).
>
> One thing called my attention on your response however:
>
> I haven't made myself clear, but one of the failures we encountered were
> that the files now containing:
>
> node02:
>--
>storage:
>--
>osds:
>--
>/dev/sda4:
>--
>format:
>bluestore
>standalone:
>True
>
> Were originally empty, and we filled them by hand following a model found
> elsewhere on the web. It was necessary, so that we could continue, but
the
> model indicated that, for example, it should have the path for /dev/sda
> here, not /dev/sda4. We chosen to include the specific partition
> identification because we won't have dedicated disks here, rather just
the
> very same partition as all disks were partitioned exactly the same.
>
> While that was enough for the procedure to continue at that point, now I
> wonder if it was the right call and, if it indeed was, if it was done
> properly.  As such, I wonder: what you mean by "wipe" the partition here?
> /dev/sda4 is created, but is both empty and unmounted: Should a different
> operation be performed on it, should I remove it first, should I have
> written the files above with only /dev/sda as target?
>
> I know that probably I wouldn't run in this issues with dedicated discks,
> but unfortunately that is absolutely not an option.
>
> Thanks a lot in advance for any comments and/or extra suggestions.
>
> Sincerely yours,
>
> Jones
>
> On Sat, Aug 25, 2018 at 5:46 PM Eugen Block  wrote:
>
>> Hi,
>>
>> take a look into the logs, they should point you in the right direction.
>> Since the deployment stage fails at the OSD level, start with the OSD
>> logs. Something's not right with the disks/partitions, did you wipe
>> the partition from previous attempts?
>>
>> Regards,
>> Eugen
>>
>> Zitat von Jones de Andrade :
>>
>>> (Please forgive my previous email: I was using another message and
>>> completely 

Re: [ceph-users] Ceph-Deploy error on 15/71 stage

[Jones de Andrade]

Hi Eugen.

Sorry for the delay in answering.

Just looked in the /var/log/ceph/ directory. It only contains the following
files (for example on node01):

###
# ls -lart
total 3864
-rw--- 1 ceph ceph 904 ago 24 13:11 ceph.audit.log-20180829.xz
drwxr-xr-x 1 root root 898 ago 28 10:07 ..
-rw-r--r-- 1 ceph ceph  189464 ago 28 23:59 ceph-mon.node01.log-20180829.xz
-rw--- 1 ceph ceph   24360 ago 28 23:59 ceph.log-20180829.xz
-rw-r--r-- 1 ceph ceph   48584 ago 29 00:00 ceph-mgr.node01.log-20180829.xz
-rw--- 1 ceph ceph   0 ago 29 00:00 ceph.audit.log
drwxrws--T 1 ceph ceph 352 ago 29 00:00 .
-rw-r--r-- 1 ceph ceph 1908122 ago 29 12:46 ceph-mon.node01.log
-rw--- 1 ceph ceph  175229 ago 29 12:48 ceph.log
-rw-r--r-- 1 ceph ceph 1599920 ago 29 12:49 ceph-mgr.node01.log
###

So, it only contains logs concerning the node itself (is it correct? sincer
node01 is also the master, I was expecting it to have logs from the other
too) and, moreover, no ceph-osd* files. Also, I'm looking the logs I have
available, and nothing "shines out" (sorry for my poor english) as a
possible error.

Any suggestion on how to proceed?

Thanks a lot in advance,

Jones


On Mon, Aug 27, 2018 at 5:29 AM Eugen Block  wrote:

> Hi Jones,
>
> all ceph logs are in the directory /var/log/ceph/, each daemon has its
> own log file, e.g. OSD logs are named ceph-osd.*.
>
> I haven't tried it but I don't think SUSE Enterprise Storage deploys
> OSDs on partitioned disks. Is there a way to attach a second disk to
> the OSD nodes, maybe via USB or something?
>
> Although this thread is ceph related it is referring to a specific
> product, so I would recommend to post your question in the SUSE forum
> [1].
>
> Regards,
> Eugen
>
> [1] https://forums.suse.com/forumdisplay.php?99-SUSE-Enterprise-Storage
>
> Zitat von Jones de Andrade :
>
> > Hi Eugen.
> >
> > Thanks for the suggestion. I'll look for the logs (since it's our first
> > attempt with ceph, I'll have to discover where they are, but no problem).
> >
> > One thing called my attention on your response however:
> >
> > I haven't made myself clear, but one of the failures we encountered were
> > that the files now containing:
> >
> > node02:
> >--
> >storage:
> >--
> >osds:
> >--
> >/dev/sda4:
> >--
> >format:
> >bluestore
> >standalone:
> >True
> >
> > Were originally empty, and we filled them by hand following a model found
> > elsewhere on the web. It was necessary, so that we could continue, but
> the
> > model indicated that, for example, it should have the path for /dev/sda
> > here, not /dev/sda4. We chosen to include the specific partition
> > identification because we won't have dedicated disks here, rather just
> the
> > very same partition as all disks were partitioned exactly the same.
> >
> > While that was enough for the procedure to continue at that point, now I
> > wonder if it was the right call and, if it indeed was, if it was done
> > properly.  As such, I wonder: what you mean by "wipe" the partition here?
> > /dev/sda4 is created, but is both empty and unmounted: Should a different
> > operation be performed on it, should I remove it first, should I have
> > written the files above with only /dev/sda as target?
> >
> > I know that probably I wouldn't run in this issues with dedicated discks,
> > but unfortunately that is absolutely not an option.
> >
> > Thanks a lot in advance for any comments and/or extra suggestions.
> >
> > Sincerely yours,
> >
> > Jones
> >
> > On Sat, Aug 25, 2018 at 5:46 PM Eugen Block  wrote:
> >
> >> Hi,
> >>
> >> take a look into the logs, they should point you in the right direction.
> >> Since the deployment stage fails at the OSD level, start with the OSD
> >> logs. Something's not right with the disks/partitions, did you wipe
> >> the partition from previous attempts?
> >>
> >> Regards,
> >> Eugen
> >>
> >> Zitat von Jones de Andrade :
> >>
> >>> (Please forgive my previous email: I was using another message and
> >>> completely forget to update the subject)
> >>>
> >>> Hi all.
> >>>
> >>> I'm new to ceph, and after having serious problems in ceph stages 0, 1
> >> and
> >>> 2 that I could solve myself, now it seems that I have hit a wall harder
> >>> than my head. :)
> >>>
> >>> When I run salt-run state.orch ceph.stage.deploy, i monitor I see it
> >> going
> >>> up to here:
> >>>
> >>> ###
> >>> [14/71]   ceph.sysctl on
> >>>   node01... ✓ (0.5s)
> >>>   node02 ✓ (0.7s)
> >>>   node03... ✓ (0.6s)
> >>>   node04. ✓ (0.5s)
> >>>   node05... ✓ (0.6s)
> >>>   node06.. ✓ 

Re: [ceph-users] Ceph-Deploy error on 15/71 stage

[Eugen Block]

Hi Jones,

all ceph logs are in the directory /var/log/ceph/, each daemon has its  
own log file, e.g. OSD logs are named ceph-osd.*.


I haven't tried it but I don't think SUSE Enterprise Storage deploys  
OSDs on partitioned disks. Is there a way to attach a second disk to  
the OSD nodes, maybe via USB or something?


Although this thread is ceph related it is referring to a specific  
product, so I would recommend to post your question in the SUSE forum  
[1].


Regards,
Eugen

[1] https://forums.suse.com/forumdisplay.php?99-SUSE-Enterprise-Storage

Zitat von Jones de Andrade :


Hi Eugen.

Thanks for the suggestion. I'll look for the logs (since it's our first
attempt with ceph, I'll have to discover where they are, but no problem).

One thing called my attention on your response however:

I haven't made myself clear, but one of the failures we encountered were
that the files now containing:

node02:
   --
   storage:
   --
   osds:
   --
   /dev/sda4:
   --
   format:
   bluestore
   standalone:
   True

Were originally empty, and we filled them by hand following a model found
elsewhere on the web. It was necessary, so that we could continue, but the
model indicated that, for example, it should have the path for /dev/sda
here, not /dev/sda4. We chosen to include the specific partition
identification because we won't have dedicated disks here, rather just the
very same partition as all disks were partitioned exactly the same.

While that was enough for the procedure to continue at that point, now I
wonder if it was the right call and, if it indeed was, if it was done
properly.  As such, I wonder: what you mean by "wipe" the partition here?
/dev/sda4 is created, but is both empty and unmounted: Should a different
operation be performed on it, should I remove it first, should I have
written the files above with only /dev/sda as target?

I know that probably I wouldn't run in this issues with dedicated discks,
but unfortunately that is absolutely not an option.

Thanks a lot in advance for any comments and/or extra suggestions.

Sincerely yours,

Jones

On Sat, Aug 25, 2018 at 5:46 PM Eugen Block  wrote:


Hi,

take a look into the logs, they should point you in the right direction.
Since the deployment stage fails at the OSD level, start with the OSD
logs. Something's not right with the disks/partitions, did you wipe
the partition from previous attempts?

Regards,
Eugen

Zitat von Jones de Andrade :


(Please forgive my previous email: I was using another message and
completely forget to update the subject)

Hi all.

I'm new to ceph, and after having serious problems in ceph stages 0, 1

and

2 that I could solve myself, now it seems that I have hit a wall harder
than my head. :)

When I run salt-run state.orch ceph.stage.deploy, i monitor I see it

going

up to here:

###
[14/71]   ceph.sysctl on
  node01... ✓ (0.5s)
  node02 ✓ (0.7s)
  node03... ✓ (0.6s)
  node04. ✓ (0.5s)
  node05... ✓ (0.6s)
  node06.. ✓ (0.5s)

[15/71]   ceph.osd on
  node01.. ❌ (0.7s)
  node02 ❌ (0.7s)
  node03... ❌ (0.7s)
  node04. ❌ (0.6s)
  node05... ❌ (0.6s)
  node06.. ❌ (0.7s)

Ended stage: ceph.stage.deploy succeeded=14/71 failed=1/71 time=624.7s

Failures summary:

ceph.osd (/srv/salt/ceph/osd):
  node02:
deploy OSDs: Module function osd.deploy threw an exception.

Exception:

Mine on node02 for cephdisks.list
  node03:
deploy OSDs: Module function osd.deploy threw an exception.

Exception:

Mine on node03 for cephdisks.list
  node01:
deploy OSDs: Module function osd.deploy threw an exception.

Exception:

Mine on node01 for cephdisks.list
  node04:
deploy OSDs: Module function osd.deploy threw an exception.

Exception:

Mine on node04 for cephdisks.list
  node05:
deploy OSDs: Module function osd.deploy threw an exception.

Exception:

Mine on node05 for cephdisks.list
  node06:
deploy OSDs: Module function osd.deploy threw an exception.

Exception:

Mine on node06 for cephdisks.list
###

Since this is a first attempt in 6 simple test machines, we are going to
put the mon, osds, etc, in all nodes at first. Only the master is left

in a

single machine (node01) by now.

As they are simple machines, they have a single hdd, which is partitioned
as follows (the hda4 partition is unmounted and left for the ceph

system):

Re: [ceph-users] Ceph-Deploy error on 15/71 stage

[Jones de Andrade]

Hi Eugen.

Thanks for the suggestion. I'll look for the logs (since it's our first
attempt with ceph, I'll have to discover where they are, but no problem).

One thing called my attention on your response however:

I haven't made myself clear, but one of the failures we encountered were
that the files now containing:

node02:
--
storage:
--
osds:
--
/dev/sda4:
--
format:
bluestore
standalone:
True

Were originally empty, and we filled them by hand following a model found
elsewhere on the web. It was necessary, so that we could continue, but the
model indicated that, for example, it should have the path for /dev/sda
here, not /dev/sda4. We chosen to include the specific partition
identification because we won't have dedicated disks here, rather just the
very same partition as all disks were partitioned exactly the same.

While that was enough for the procedure to continue at that point, now I
wonder if it was the right call and, if it indeed was, if it was done
properly.  As such, I wonder: what you mean by "wipe" the partition here?
/dev/sda4 is created, but is both empty and unmounted: Should a different
operation be performed on it, should I remove it first, should I have
written the files above with only /dev/sda as target?

I know that probably I wouldn't run in this issues with dedicated discks,
but unfortunately that is absolutely not an option.

Thanks a lot in advance for any comments and/or extra suggestions.

Sincerely yours,

Jones

On Sat, Aug 25, 2018 at 5:46 PM Eugen Block  wrote:

> Hi,
>
> take a look into the logs, they should point you in the right direction.
> Since the deployment stage fails at the OSD level, start with the OSD
> logs. Something's not right with the disks/partitions, did you wipe
> the partition from previous attempts?
>
> Regards,
> Eugen
>
> Zitat von Jones de Andrade :
>
> > (Please forgive my previous email: I was using another message and
> > completely forget to update the subject)
> >
> > Hi all.
> >
> > I'm new to ceph, and after having serious problems in ceph stages 0, 1
> and
> > 2 that I could solve myself, now it seems that I have hit a wall harder
> > than my head. :)
> >
> > When I run salt-run state.orch ceph.stage.deploy, i monitor I see it
> going
> > up to here:
> >
> > ###
> > [14/71]   ceph.sysctl on
> >   node01... ✓ (0.5s)
> >   node02 ✓ (0.7s)
> >   node03... ✓ (0.6s)
> >   node04. ✓ (0.5s)
> >   node05... ✓ (0.6s)
> >   node06.. ✓ (0.5s)
> >
> > [15/71]   ceph.osd on
> >   node01.. ❌ (0.7s)
> >   node02 ❌ (0.7s)
> >   node03... ❌ (0.7s)
> >   node04. ❌ (0.6s)
> >   node05... ❌ (0.6s)
> >   node06.. ❌ (0.7s)
> >
> > Ended stage: ceph.stage.deploy succeeded=14/71 failed=1/71 time=624.7s
> >
> > Failures summary:
> >
> > ceph.osd (/srv/salt/ceph/osd):
> >   node02:
> > deploy OSDs: Module function osd.deploy threw an exception.
> Exception:
> > Mine on node02 for cephdisks.list
> >   node03:
> > deploy OSDs: Module function osd.deploy threw an exception.
> Exception:
> > Mine on node03 for cephdisks.list
> >   node01:
> > deploy OSDs: Module function osd.deploy threw an exception.
> Exception:
> > Mine on node01 for cephdisks.list
> >   node04:
> > deploy OSDs: Module function osd.deploy threw an exception.
> Exception:
> > Mine on node04 for cephdisks.list
> >   node05:
> > deploy OSDs: Module function osd.deploy threw an exception.
> Exception:
> > Mine on node05 for cephdisks.list
> >   node06:
> > deploy OSDs: Module function osd.deploy threw an exception.
> Exception:
> > Mine on node06 for cephdisks.list
> > ###
> >
> > Since this is a first attempt in 6 simple test machines, we are going to
> > put the mon, osds, etc, in all nodes at first. Only the master is left
> in a
> > single machine (node01) by now.
> >
> > As they are simple machines, they have a single hdd, which is partitioned
> > as follows (the hda4 partition is unmounted and left for the ceph
> system):
> >
> > ###
> > # lsblk
> > NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
> > sda  8:00 465,8G  0 disk
> > ├─sda1   8:10   500M  0 part /boot/efi
> > ├─sda2   8:2016G  0 part [SWAP]
> > ├─sda3   8:30  49,3G  0 part /
> > └─sda4   8:40   400G  0 part
> > sr0 11:01   3,7G  0 rom
> >
> > # salt -I 

Re: [ceph-users] Ceph-Deploy error on 15/71 stage

[Eugen Block]

Hi,

take a look into the logs, they should point you in the right direction.
Since the deployment stage fails at the OSD level, start with the OSD  
logs. Something's not right with the disks/partitions, did you wipe  
the partition from previous attempts?


Regards,
Eugen

Zitat von Jones de Andrade :


(Please forgive my previous email: I was using another message and
completely forget to update the subject)

Hi all.

I'm new to ceph, and after having serious problems in ceph stages 0, 1 and
2 that I could solve myself, now it seems that I have hit a wall harder
than my head. :)

When I run salt-run state.orch ceph.stage.deploy, i monitor I see it going
up to here:

###
[14/71]   ceph.sysctl on
  node01... ✓ (0.5s)
  node02 ✓ (0.7s)
  node03... ✓ (0.6s)
  node04. ✓ (0.5s)
  node05... ✓ (0.6s)
  node06.. ✓ (0.5s)

[15/71]   ceph.osd on
  node01.. ❌ (0.7s)
  node02 ❌ (0.7s)
  node03... ❌ (0.7s)
  node04. ❌ (0.6s)
  node05... ❌ (0.6s)
  node06.. ❌ (0.7s)

Ended stage: ceph.stage.deploy succeeded=14/71 failed=1/71 time=624.7s

Failures summary:

ceph.osd (/srv/salt/ceph/osd):
  node02:
deploy OSDs: Module function osd.deploy threw an exception. Exception:
Mine on node02 for cephdisks.list
  node03:
deploy OSDs: Module function osd.deploy threw an exception. Exception:
Mine on node03 for cephdisks.list
  node01:
deploy OSDs: Module function osd.deploy threw an exception. Exception:
Mine on node01 for cephdisks.list
  node04:
deploy OSDs: Module function osd.deploy threw an exception. Exception:
Mine on node04 for cephdisks.list
  node05:
deploy OSDs: Module function osd.deploy threw an exception. Exception:
Mine on node05 for cephdisks.list
  node06:
deploy OSDs: Module function osd.deploy threw an exception. Exception:
Mine on node06 for cephdisks.list
###

Since this is a first attempt in 6 simple test machines, we are going to
put the mon, osds, etc, in all nodes at first. Only the master is left in a
single machine (node01) by now.

As they are simple machines, they have a single hdd, which is partitioned
as follows (the hda4 partition is unmounted and left for the ceph system):

###
# lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda  8:00 465,8G  0 disk
├─sda1   8:10   500M  0 part /boot/efi
├─sda2   8:2016G  0 part [SWAP]
├─sda3   8:30  49,3G  0 part /
└─sda4   8:40   400G  0 part
sr0 11:01   3,7G  0 rom

# salt -I 'roles:storage' cephdisks.list
node01:
node02:
node03:
node04:
node05:
node06:

# salt -I 'roles:storage' pillar.get ceph
node02:
--
storage:
--
osds:
--
/dev/sda4:
--
format:
bluestore
standalone:
True
(and so on for all 6 machines)
##

Finally and just in case, my policy.cfg file reads:

#
#cluster-unassigned/cluster/*.sls
cluster-ceph/cluster/*.sls
profile-default/cluster/*.sls
profile-default/stack/default/ceph/minions/*yml
config/stack/default/global.yml
config/stack/default/ceph/cluster.yml
role-master/cluster/node01.sls
role-admin/cluster/*.sls
role-mon/cluster/*.sls
role-mgr/cluster/*.sls
role-mds/cluster/*.sls
role-ganesha/cluster/*.sls
role-client-nfs/cluster/*.sls
role-client-cephfs/cluster/*.sls
##

Please, could someone help me and shed some light on this issue?

Thanks a lot in advance,

Regasrds,

Jones




___
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com

[ceph-users] Ceph-Deploy error on 15/71 stage

[Jones de Andrade]

(Please forgive my previous email: I was using another message and
completely forget to update the subject)

Hi all.

I'm new to ceph, and after having serious problems in ceph stages 0, 1 and
2 that I could solve myself, now it seems that I have hit a wall harder
than my head. :)

When I run salt-run state.orch ceph.stage.deploy, i monitor I see it going
up to here:

###
[14/71]   ceph.sysctl on
  node01... ✓ (0.5s)
  node02 ✓ (0.7s)
  node03... ✓ (0.6s)
  node04. ✓ (0.5s)
  node05... ✓ (0.6s)
  node06.. ✓ (0.5s)

[15/71]   ceph.osd on
  node01.. ❌ (0.7s)
  node02 ❌ (0.7s)
  node03... ❌ (0.7s)
  node04. ❌ (0.6s)
  node05... ❌ (0.6s)
  node06.. ❌ (0.7s)

Ended stage: ceph.stage.deploy succeeded=14/71 failed=1/71 time=624.7s

Failures summary:

ceph.osd (/srv/salt/ceph/osd):
  node02:
deploy OSDs: Module function osd.deploy threw an exception. Exception:
Mine on node02 for cephdisks.list
  node03:
deploy OSDs: Module function osd.deploy threw an exception. Exception:
Mine on node03 for cephdisks.list
  node01:
deploy OSDs: Module function osd.deploy threw an exception. Exception:
Mine on node01 for cephdisks.list
  node04:
deploy OSDs: Module function osd.deploy threw an exception. Exception:
Mine on node04 for cephdisks.list
  node05:
deploy OSDs: Module function osd.deploy threw an exception. Exception:
Mine on node05 for cephdisks.list
  node06:
deploy OSDs: Module function osd.deploy threw an exception. Exception:
Mine on node06 for cephdisks.list
###

Since this is a first attempt in 6 simple test machines, we are going to
put the mon, osds, etc, in all nodes at first. Only the master is left in a
single machine (node01) by now.

As they are simple machines, they have a single hdd, which is partitioned
as follows (the hda4 partition is unmounted and left for the ceph system):

###
# lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda  8:00 465,8G  0 disk
├─sda1   8:10   500M  0 part /boot/efi
├─sda2   8:2016G  0 part [SWAP]
├─sda3   8:30  49,3G  0 part /
└─sda4   8:40   400G  0 part
sr0 11:01   3,7G  0 rom

# salt -I 'roles:storage' cephdisks.list
node01:
node02:
node03:
node04:
node05:
node06:

# salt -I 'roles:storage' pillar.get ceph
node02:
--
storage:
--
osds:
--
/dev/sda4:
--
format:
bluestore
standalone:
True
(and so on for all 6 machines)
##

Finally and just in case, my policy.cfg file reads:

#
#cluster-unassigned/cluster/*.sls
cluster-ceph/cluster/*.sls
profile-default/cluster/*.sls
profile-default/stack/default/ceph/minions/*yml
config/stack/default/global.yml
config/stack/default/ceph/cluster.yml
role-master/cluster/node01.sls
role-admin/cluster/*.sls
role-mon/cluster/*.sls
role-mgr/cluster/*.sls
role-mds/cluster/*.sls
role-ganesha/cluster/*.sls
role-client-nfs/cluster/*.sls
role-client-cephfs/cluster/*.sls
##

Please, could someone help me and shed some light on this issue?

Thanks a lot in advance,

Regasrds,

Jones
___
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com

Re: [ceph-users] Ceph-deploy error

[Ken Dreyer]

This issue with the conflicts between Firefly and EPEL is tracked at
http://tracker.ceph.com/issues/11104

On Sun, Aug 30, 2015 at 4:11 PM, pavana bhat
 wrote:
> In case someone else runs into the same issue in future:
>
> I came out of this issue by installing epel-release before installing
> ceph-deploy. If the order of installation is ceph-deploy followed by
> epel-release, the issue is being hit.
>
> Thanks,
> Pavana
>
> On Sat, Aug 29, 2015 at 10:02 AM, pavana bhat 
> wrote:
>>
>> Hi,
>>
>> I'm trying to install ceph for the first time following the quick
>> installation guide. I'm getting the below error, can someone please help?
>>
>> ceph-deploy install --release=firefly ceph-vm-mon1
>>
>> [ceph_deploy.conf][DEBUG ] found configuration file at:
>> /home/cloud-user/.cephdeploy.conf
>>
>> [ceph_deploy.cli][INFO  ] Invoked (1.5.28): /usr/bin/ceph-deploy install
>> --release=firefly ceph-vm-mon1
>>
>> [ceph_deploy.cli][INFO  ] ceph-deploy options:
>>
>> [ceph_deploy.cli][INFO  ]  verbose   : False
>>
>> [ceph_deploy.cli][INFO  ]  testing   : None
>>
>> [ceph_deploy.cli][INFO  ]  cd_conf   :
>> 
>>
>> [ceph_deploy.cli][INFO  ]  cluster   : ceph
>>
>> [ceph_deploy.cli][INFO  ]  install_mds   : False
>>
>> [ceph_deploy.cli][INFO  ]  stable: None
>>
>> [ceph_deploy.cli][INFO  ]  default_release   : False
>>
>> [ceph_deploy.cli][INFO  ]  username  : None
>>
>> [ceph_deploy.cli][INFO  ]  adjust_repos  : True
>>
>> [ceph_deploy.cli][INFO  ]  func  : > install at 0x7f34b410e938>
>>
>> [ceph_deploy.cli][INFO  ]  install_all   : False
>>
>> [ceph_deploy.cli][INFO  ]  repo  : False
>>
>> [ceph_deploy.cli][INFO  ]  host  :
>> ['ceph-vm-mon1']
>>
>> [ceph_deploy.cli][INFO  ]  install_rgw   : False
>>
>> [ceph_deploy.cli][INFO  ]  repo_url  : None
>>
>> [ceph_deploy.cli][INFO  ]  ceph_conf : None
>>
>> [ceph_deploy.cli][INFO  ]  install_osd   : False
>>
>> [ceph_deploy.cli][INFO  ]  version_kind  : stable
>>
>> [ceph_deploy.cli][INFO  ]  install_common: False
>>
>> [ceph_deploy.cli][INFO  ]  overwrite_conf: False
>>
>> [ceph_deploy.cli][INFO  ]  quiet : False
>>
>> [ceph_deploy.cli][INFO  ]  dev   : master
>>
>> [ceph_deploy.cli][INFO  ]  local_mirror  : None
>>
>> [ceph_deploy.cli][INFO  ]  release   : firefly
>>
>> [ceph_deploy.cli][INFO  ]  install_mon   : False
>>
>> [ceph_deploy.cli][INFO  ]  gpg_url   : None
>>
>> [ceph_deploy.install][DEBUG ] Installing stable version firefly on cluster
>> ceph hosts ceph-vm-mon1
>>
>> [ceph_deploy.install][DEBUG ] Detecting platform for host ceph-vm-mon1 ...
>>
>> [ceph-vm-mon1][DEBUG ] connection detected need for sudo
>>
>> [ceph-vm-mon1][DEBUG ] connected to host: ceph-vm-mon1
>>
>> [ceph-vm-mon1][DEBUG ] detect platform information from remote host
>>
>> [ceph-vm-mon1][DEBUG ] detect machine type
>>
>> [ceph_deploy.install][INFO  ] Distro info: Red Hat Enterprise Linux Server
>> 7.1 Maipo
>>
>> [ceph-vm-mon1][INFO  ] installing Ceph on ceph-vm-mon1
>>
>> [ceph-vm-mon1][INFO  ] Running command: sudo yum clean all
>>
>> [ceph-vm-mon1][DEBUG ] Loaded plugins: fastestmirror, priorities
>>
>> [ceph-vm-mon1][DEBUG ] Cleaning repos: epel rhel-7-ha-rpms
>> rhel-7-optional-rpms rhel-7-server-rpms
>>
>> [ceph-vm-mon1][DEBUG ]   : rhel-7-supplemental-rpms
>>
>> [ceph-vm-mon1][DEBUG ] Cleaning up everything
>>
>> [ceph-vm-mon1][DEBUG ] Cleaning up list of fastest mirrors
>>
>> [ceph-vm-mon1][INFO  ] Running command: sudo yum -y install epel-release
>>
>> [ceph-vm-mon1][DEBUG ] Loaded plugins: fastestmirror, priorities
>>
>> [ceph-vm-mon1][DEBUG ] Determining fastest mirrors
>>
>> [ceph-vm-mon1][DEBUG ]  * epel: kdeforge2.unl.edu
>>
>> [ceph-vm-mon1][DEBUG ]  * rhel-7-ha-rpms:
>> rhel-repo.eu-biere-1.t-systems.cloud.cisco.com
>>
>> [ceph-vm-mon1][DEBUG ]  * rhel-7-optional-rpms:
>> rhel-repo.eu-biere-1.t-systems.cloud.cisco.com
>>
>> [ceph-vm-mon1][DEBUG ]  * rhel-7-server-rpms:
>> rhel-repo.eu-biere-1.t-systems.cloud.cisco.com
>>
>> [ceph-vm-mon1][DEBUG ]  * rhel-7-supplemental-rpms:
>> rhel-repo.eu-biere-1.t-systems.cloud.cisco.com
>>
>> [ceph-vm-mon1][DEBUG ] Package epel-release-7-5.noarch already installed
>> and latest version
>>
>> [ceph-vm-mon1][DEBUG ] Nothing to do
>>
>> [ceph-vm-mon1][INFO  ] Running command: sudo yum -y install
>> yum-plugin-priorities
>>
>> [ceph-vm-mon1][DEBUG ] Loaded plugins: fastestmirror, priorities
>>
>> [ceph-vm-mon1][DEBUG ] Loading mirror speeds from cached hostfile
>>
>> 

Re: [ceph-users] Ceph-deploy error

[pavana bhat]

In case someone else runs into the same issue in future:

I came out of this issue by installing epel-release before installing
ceph-deploy. If the order of installation is ceph-deploy followed by
epel-release, the issue is being hit.

Thanks,
Pavana

On Sat, Aug 29, 2015 at 10:02 AM, pavana bhat pavanakrishnab...@gmail.com
wrote:

 Hi,

 I'm trying to install ceph for the first time following the quick
 installation guide. I'm getting the below error, can someone please help?

 ceph-deploy install --release=firefly ceph-vm-mon1

 [*ceph_deploy.conf*][*DEBUG* ] found configuration file at:
 /home/cloud-user/.cephdeploy.conf

 [*ceph_deploy.cli*][*INFO*  ] Invoked (1.5.28): /usr/bin/ceph-deploy
 install --release=firefly ceph-vm-mon1

 [*ceph_deploy.cli*][*INFO*  ] ceph-deploy options:

 [*ceph_deploy.cli*][*INFO*  ]  verbose   : False

 [*ceph_deploy.cli*][*INFO*  ]  testing   : None

 [*ceph_deploy.cli*][*INFO*  ]  cd_conf   :
 ceph_deploy.conf.cephdeploy.Conf instance at 0xaab248

 [*ceph_deploy.cli*][*INFO*  ]  cluster   : ceph

 [*ceph_deploy.cli*][*INFO*  ]  install_mds   : False

 [*ceph_deploy.cli*][*INFO*  ]  stable: None

 [*ceph_deploy.cli*][*INFO*  ]  default_release   : False

 [*ceph_deploy.cli*][*INFO*  ]  username  : None

 [*ceph_deploy.cli*][*INFO*  ]  adjust_repos  : True

 [*ceph_deploy.cli*][*INFO*  ]  func  : function
 install at 0x7f34b410e938

 [*ceph_deploy.cli*][*INFO*  ]  install_all   : False

 [*ceph_deploy.cli*][*INFO*  ]  repo  : False

 [*ceph_deploy.cli*][*INFO*  ]  host  :
 ['ceph-vm-mon1']

 [*ceph_deploy.cli*][*INFO*  ]  install_rgw   : False

 [*ceph_deploy.cli*][*INFO*  ]  repo_url  : None

 [*ceph_deploy.cli*][*INFO*  ]  ceph_conf : None

 [*ceph_deploy.cli*][*INFO*  ]  install_osd   : False

 [*ceph_deploy.cli*][*INFO*  ]  version_kind  : stable

 [*ceph_deploy.cli*][*INFO*  ]  install_common: False

 [*ceph_deploy.cli*][*INFO*  ]  overwrite_conf: False

 [*ceph_deploy.cli*][*INFO*  ]  quiet : False

 [*ceph_deploy.cli*][*INFO*  ]  dev   : master

 [*ceph_deploy.cli*][*INFO*  ]  local_mirror  : None

 [*ceph_deploy.cli*][*INFO*  ]  release   : firefly

 [*ceph_deploy.cli*][*INFO*  ]  install_mon   : False

 [*ceph_deploy.cli*][*INFO*  ]  gpg_url   : None

 [*ceph_deploy.install*][*DEBUG* ] Installing stable version firefly on
 cluster ceph hosts ceph-vm-mon1

 [*ceph_deploy.install*][*DEBUG* ] Detecting platform for host
 ceph-vm-mon1 ...

 [*ceph-vm-mon1*][*DEBUG* ] connection detected need for sudo

 [*ceph-vm-mon1*][*DEBUG* ] connected to host: ceph-vm-mon1

 [*ceph-vm-mon1*][*DEBUG* ] detect platform information from remote host

 [*ceph-vm-mon1*][*DEBUG* ] detect machine type

 [*ceph_deploy.install*][*INFO*  ] Distro info: Red Hat Enterprise Linux
 Server 7.1 Maipo

 [*ceph-vm-mon1*][*INFO*  ] installing Ceph on ceph-vm-mon1

 [*ceph-vm-mon1*][*INFO*  ] Running command: sudo yum clean all

 [*ceph-vm-mon1*][*DEBUG* ] Loaded plugins: fastestmirror, priorities

 [*ceph-vm-mon1*][*DEBUG* ] Cleaning repos: epel rhel-7-ha-rpms
 rhel-7-optional-rpms rhel-7-server-rpms

 [*ceph-vm-mon1*][*DEBUG* ]   : rhel-7-supplemental-rpms

 [*ceph-vm-mon1*][*DEBUG* ] Cleaning up everything

 [*ceph-vm-mon1*][*DEBUG* ] Cleaning up list of fastest mirrors

 [*ceph-vm-mon1*][*INFO*  ] Running command: sudo yum -y install
 epel-release

 [*ceph-vm-mon1*][*DEBUG* ] Loaded plugins: fastestmirror, priorities

 [*ceph-vm-mon1*][*DEBUG* ] Determining fastest mirrors

 [*ceph-vm-mon1*][*DEBUG* ]  * epel: kdeforge2.unl.edu

 [*ceph-vm-mon1*][*DEBUG* ]  * rhel-7-ha-rpms:
 rhel-repo.eu-biere-1.t-systems.cloud.cisco.com

 [*ceph-vm-mon1*][*DEBUG* ]  * rhel-7-optional-rpms:
 rhel-repo.eu-biere-1.t-systems.cloud.cisco.com

 [*ceph-vm-mon1*][*DEBUG* ]  * rhel-7-server-rpms:
 rhel-repo.eu-biere-1.t-systems.cloud.cisco.com

 [*ceph-vm-mon1*][*DEBUG* ]  * rhel-7-supplemental-rpms:
 rhel-repo.eu-biere-1.t-systems.cloud.cisco.com

 [*ceph-vm-mon1*][*DEBUG* ] Package epel-release-7-5.noarch already
 installed and latest version

 [*ceph-vm-mon1*][*DEBUG* ] Nothing to do

 [*ceph-vm-mon1*][*INFO*  ] Running command: sudo yum -y install
 yum-plugin-priorities

 [*ceph-vm-mon1*][*DEBUG* ] Loaded plugins: fastestmirror, priorities

 [*ceph-vm-mon1*][*DEBUG* ] Loading mirror speeds from cached hostfile

 [*ceph-vm-mon1*][*DEBUG* ]  * epel: kdeforge2.unl.edu

 [*ceph-vm-mon1*][*DEBUG* ]  * rhel-7-ha-rpms:
 rhel-repo.eu-biere-1.t-systems.cloud.cisco.com

 [*ceph-vm-mon1*][*DEBUG* ]  * rhel-7-optional-rpms:
 

[ceph-users] Ceph-deploy error

[pavana bhat]

Hi,

I'm trying to install ceph for the first time following the quick
installation guide. I'm getting the below error, can someone please help?

ceph-deploy install --release=firefly ceph-vm-mon1

[*ceph_deploy.conf*][*DEBUG* ] found configuration file at:
/home/cloud-user/.cephdeploy.conf

[*ceph_deploy.cli*][*INFO*  ] Invoked (1.5.28): /usr/bin/ceph-deploy
install --release=firefly ceph-vm-mon1

[*ceph_deploy.cli*][*INFO*  ] ceph-deploy options:

[*ceph_deploy.cli*][*INFO*  ]  verbose   : False

[*ceph_deploy.cli*][*INFO*  ]  testing   : None

[*ceph_deploy.cli*][*INFO*  ]  cd_conf   :
ceph_deploy.conf.cephdeploy.Conf instance at 0xaab248

[*ceph_deploy.cli*][*INFO*  ]  cluster   : ceph

[*ceph_deploy.cli*][*INFO*  ]  install_mds   : False

[*ceph_deploy.cli*][*INFO*  ]  stable: None

[*ceph_deploy.cli*][*INFO*  ]  default_release   : False

[*ceph_deploy.cli*][*INFO*  ]  username  : None

[*ceph_deploy.cli*][*INFO*  ]  adjust_repos  : True

[*ceph_deploy.cli*][*INFO*  ]  func  : function
install at 0x7f34b410e938

[*ceph_deploy.cli*][*INFO*  ]  install_all   : False

[*ceph_deploy.cli*][*INFO*  ]  repo  : False

[*ceph_deploy.cli*][*INFO*  ]  host  :
['ceph-vm-mon1']

[*ceph_deploy.cli*][*INFO*  ]  install_rgw   : False

[*ceph_deploy.cli*][*INFO*  ]  repo_url  : None

[*ceph_deploy.cli*][*INFO*  ]  ceph_conf : None

[*ceph_deploy.cli*][*INFO*  ]  install_osd   : False

[*ceph_deploy.cli*][*INFO*  ]  version_kind  : stable

[*ceph_deploy.cli*][*INFO*  ]  install_common: False

[*ceph_deploy.cli*][*INFO*  ]  overwrite_conf: False

[*ceph_deploy.cli*][*INFO*  ]  quiet : False

[*ceph_deploy.cli*][*INFO*  ]  dev   : master

[*ceph_deploy.cli*][*INFO*  ]  local_mirror  : None

[*ceph_deploy.cli*][*INFO*  ]  release   : firefly

[*ceph_deploy.cli*][*INFO*  ]  install_mon   : False

[*ceph_deploy.cli*][*INFO*  ]  gpg_url   : None

[*ceph_deploy.install*][*DEBUG* ] Installing stable version firefly on
cluster ceph hosts ceph-vm-mon1

[*ceph_deploy.install*][*DEBUG* ] Detecting platform for host ceph-vm-mon1
...

[*ceph-vm-mon1*][*DEBUG* ] connection detected need for sudo

[*ceph-vm-mon1*][*DEBUG* ] connected to host: ceph-vm-mon1

[*ceph-vm-mon1*][*DEBUG* ] detect platform information from remote host

[*ceph-vm-mon1*][*DEBUG* ] detect machine type

[*ceph_deploy.install*][*INFO*  ] Distro info: Red Hat Enterprise Linux
Server 7.1 Maipo

[*ceph-vm-mon1*][*INFO*  ] installing Ceph on ceph-vm-mon1

[*ceph-vm-mon1*][*INFO*  ] Running command: sudo yum clean all

[*ceph-vm-mon1*][*DEBUG* ] Loaded plugins: fastestmirror, priorities

[*ceph-vm-mon1*][*DEBUG* ] Cleaning repos: epel rhel-7-ha-rpms
rhel-7-optional-rpms rhel-7-server-rpms

[*ceph-vm-mon1*][*DEBUG* ]   : rhel-7-supplemental-rpms

[*ceph-vm-mon1*][*DEBUG* ] Cleaning up everything

[*ceph-vm-mon1*][*DEBUG* ] Cleaning up list of fastest mirrors

[*ceph-vm-mon1*][*INFO*  ] Running command: sudo yum -y install epel-release

[*ceph-vm-mon1*][*DEBUG* ] Loaded plugins: fastestmirror, priorities

[*ceph-vm-mon1*][*DEBUG* ] Determining fastest mirrors

[*ceph-vm-mon1*][*DEBUG* ]  * epel: kdeforge2.unl.edu

[*ceph-vm-mon1*][*DEBUG* ]  * rhel-7-ha-rpms:
rhel-repo.eu-biere-1.t-systems.cloud.cisco.com

[*ceph-vm-mon1*][*DEBUG* ]  * rhel-7-optional-rpms:
rhel-repo.eu-biere-1.t-systems.cloud.cisco.com

[*ceph-vm-mon1*][*DEBUG* ]  * rhel-7-server-rpms:
rhel-repo.eu-biere-1.t-systems.cloud.cisco.com

[*ceph-vm-mon1*][*DEBUG* ]  * rhel-7-supplemental-rpms:
rhel-repo.eu-biere-1.t-systems.cloud.cisco.com

[*ceph-vm-mon1*][*DEBUG* ] Package epel-release-7-5.noarch already
installed and latest version

[*ceph-vm-mon1*][*DEBUG* ] Nothing to do

[*ceph-vm-mon1*][*INFO*  ] Running command: sudo yum -y install
yum-plugin-priorities

[*ceph-vm-mon1*][*DEBUG* ] Loaded plugins: fastestmirror, priorities

[*ceph-vm-mon1*][*DEBUG* ] Loading mirror speeds from cached hostfile

[*ceph-vm-mon1*][*DEBUG* ]  * epel: kdeforge2.unl.edu

[*ceph-vm-mon1*][*DEBUG* ]  * rhel-7-ha-rpms:
rhel-repo.eu-biere-1.t-systems.cloud.cisco.com

[*ceph-vm-mon1*][*DEBUG* ]  * rhel-7-optional-rpms:
rhel-repo.eu-biere-1.t-systems.cloud.cisco.com

[*ceph-vm-mon1*][*DEBUG* ]  * rhel-7-server-rpms:
rhel-repo.eu-biere-1.t-systems.cloud.cisco.com

[*ceph-vm-mon1*][*DEBUG* ]  * rhel-7-supplemental-rpms:
rhel-repo.eu-biere-1.t-systems.cloud.cisco.com

[*ceph-vm-mon1*][*DEBUG* ] Package
yum-plugin-priorities-1.1.31-29.el7.noarch already installed and latest
version

[*ceph-vm-mon1*][*DEBUG* ] Nothing to do

Re: [ceph-users] ceph-deploy error

[Alfredo Deza]

Oh yes, we don't have ARM packages for wheezy.



On Mon, Aug 11, 2014 at 7:12 PM, joshua Kay scjo...@gmail.com wrote:
 Hi,



 I am running into an error when I am attempting to use ceph-deploy install
 when creating my cluster. I am attempting to run ceph on Debian 7.0 wheezy
 with an ARM processor. When I attempt to run ceph-deploy install I get the
 following errors:



 [ceph1][WARNIN] E: Unable to locate package ceph

 [ceph1][WARNIN] E: Unable to locate package ceph-mds

 [ceph1][WARNIN] E: Unable to locate package ceph-common

 [ceph1][WARNIN] E: Unable to locate package ceph-fs-common

 [ceph1][ERROR ] RuntimeError: command returned non-zero exit status: 100

 [ceph_deploy][ERROR ] RuntimeError: Failed to execute command: env
 DEBIAN_FRONTEND=noninteractive DEBIAN_PRIORITY=critical apt-get -q -o
 Dpkg::Options::=--force-confnew --no-install-recommends --assume-yes install
 -- ceph ceph-mds ceph-common ceph-fs-common gdisk



 I am assuming I do not have all the packages required for debian wheezy, but
 I have tried to set up a repository and manually insert the packages from
 this documentation: http://ceph.com/docs/master/install/get-packages/



 Does anyone know the issue or the proper way to set up a repository for a
 Debian wheezy system?



 Thanks


 ___
 ceph-users mailing list
 ceph-users@lists.ceph.com
 http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com

___
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com