Ceph : Issueshttps://tracker.ceph.com/https://tracker.ceph.com/favicon.ico2023-06-06T10:51:16ZCeph
Redmine Ceph - Bug #61598 (New): gcc-14: FTBFS "error: call to non-'constexpr' function 'virtual unsigned...https://tracker.ceph.com/issues/615982023-06-06T10:51:16ZTim Serongtserong@suse.com
<p>gcc 14 has introduced a change which results in ceph build failures:</p>
<pre>
[ 270s] /home/abuild/rpmbuild/BUILD/ceph-18.0.0-4135-g87cd54281c8/src/osd/osd_types.h: In lambda function:
[ 270s] /home/abuild/rpmbuild/BUILD/ceph-18.0.0-4135-g87cd54281c8/src/common/dout.h:184:73: error: call to non-'constexpr' function 'virtual unsigned int DoutPrefixProvider::get_subsys() const'
[ 270s] 184 | dout_impl(pdpp->get_cct(), ceph::dout::need_dynamic(pdpp->get_subsys()), v) \
[ 270s] | ~~~~~~~~~~~~~~~~^~
[ 270s] /home/abuild/rpmbuild/BUILD/ceph-18.0.0-4135-g87cd54281c8/src/common/dout.h:155:58: note: in definition of macro 'dout_impl'
[ 270s] 155 | return (cctX->_conf->subsys.template should_gather<sub, v>()); \
[ 270s] | ^~~
[ 270s] /home/abuild/rpmbuild/BUILD/ceph-18.0.0-4135-g87cd54281c8/src/osd/osd_types.h:3618:3: note: in expansion of macro 'ldpp_dout'
[ 270s] 3618 | ldpp_dout(dpp, 10) << "build_prior all_probe " << all_probe << dendl;
[ 270s] | ^~~~~~~~~
[ 270s] /home/abuild/rpmbuild/BUILD/ceph-18.0.0-4135-g87cd54281c8/src/common/dout.h:51:20: note: 'virtual unsigned int DoutPrefixProvider::get_subsys() const' declared here
[ 270s] 51 | virtual unsigned get_subsys() const = 0;
[ 270s] | ^~~~~~~~~~
</pre>
<p>The gcc change is described at <a class="external" href="https://gcc.gnu.org/pipermail/gcc-patches/2023-May/617196.html">https://gcc.gnu.org/pipermail/gcc-patches/2023-May/617196.html</a>.</p>
<p>The ceph FTBFS was mentioned in a followup post at <a class="external" href="https://gcc.gnu.org/pipermail/gcc-patches/2023-May/618384.html">https://gcc.gnu.org/pipermail/gcc-patches/2023-May/618384.html</a>, and apparently this failure is now expected, as <code> DoutPrefixProvider::get_subsys()</code> isn't declared <code>constexpr</code> but really should be.</p>
<p>I tried to fix this experimentally by simply declaring <code>constexpr get_subsys()</code>, e.g.:</p>
<pre>
diff --git a/src/common/dout.h b/src/common/dout.h
index a1375fbb910..6e91750708a 100644
--- a/src/common/dout.h
+++ b/src/common/dout.h
@@ -61,7 +61,7 @@ class NoDoutPrefix : public DoutPrefixProvider {
std::ostream& gen_prefix(std::ostream& out) const override { return out; }
CephContext *get_cct() const override { return cct; }
- unsigned get_subsys() const override { return subsys; }
+ constexpr unsigned get_subsys() const override { return subsys; }
};
// a prefix provider with static (const char*) prefix
@@ -88,7 +88,7 @@ class DoutPrefixPipe : public DoutPrefixProvider {
return out;
}
CephContext *get_cct() const override { return dpp.get_cct(); }
- unsigned get_subsys() const override { return dpp.get_subsys(); }
+ constexpr unsigned get_subsys() const override { return dpp.get_subsys(); }
virtual void add_prefix(std::ostream& out) const = 0;
};
</pre>
<p>...but that has some problems:</p>
<p>1) Instead of an outright build failure, I get <code>warning: virtual functions cannot be 'constexpr' before C++20 [-Winvalid-constexpr]</code>. I imaging this is undesirable.<br />2) Even if 1 <em>is</em> desirable, there's plenty of other subclasses of <code>DoutPrefixProvider</code> which would all <em>also</em> need to have their <code>get_subsys()</code> methods declared <code>conxtexpr</code> for the build to complete.</p>
<p>TBH the whole <code>dout</code> thing is black magic to me, so I could really use some assistance with how best to fix this.</p> Ceph - Bug #57860 (Pending Backport): disable system_pmdk on s390x for SUSE distroshttps://tracker.ceph.com/issues/578602022-10-13T04:28:31ZTim Serongtserong@suse.com
<p>Same as <a class="external" href="https://tracker.ceph.com/issues/56491">https://tracker.ceph.com/issues/56491</a> which addressed RHEL and Fedora not shipping libpmem on s390x, but for SUSE.</p> Ceph - Bug #56466 (Resolved): pacific: boost 1.73.0 is incompatible with python 3.10https://tracker.ceph.com/issues/564662022-07-05T05:54:10ZTim Serongtserong@suse.com
<p>Ceph pacific includes boost 1.73.0, which uses the <code>_Py_fopen()</code> function, which is no longer available in python 3.10. This means it's not possible to build ceph pacific RPMs against python 3.10. Builds will fail with:</p>
<pre>[ 182s] libs/python/src/exec.cpp: In function 'boost::python::api::object boost::python::exec_file(const char*, api::object, api::object)':
[ 182s] libs/python/src/exec.cpp:109:14: error: '_Py_fopen' was not declared in this scope; did you mean '_Py_wfopen'?
[ 182s] 109 | FILE *fs = _Py_fopen(f, "r");
[ 182s] | ^~~~~~~~~
[ 182s] | _Py_wfopen
</pre>
<p>This is not a problem with quincy or newer, as those use boost 1.75.0, which includes a patch to switches to using fopen() for python versions >= 3.1.</p> Ceph - Bug #55237 (Resolved): rpm: openSUSE build fails - needs explicit gcc version, also can't ...https://tracker.ceph.com/issues/552372022-04-08T06:23:06ZTim Serongtserong@suse.com
<p>Two issues here which are strictly speaking unrelated, but I thought it'd be less annoying to just fix the openSUSE build with one bug.</p>
<p>Issue 1: openSUSE Leap 15.3 and 15.4 use gcc 7 by default, which is not new enough to build ceph. Both distros do provide gcc 11, but we have to explicitly request that version if we want to use it.</p>
<p>Issue 2: Parquet, which in turn requires Arrow, can't currently be built for openSUSE. The problem here is that we don't have those dependencies packaged as RPMs, and when trying to build Arrow out of the submodule in the ceph source tree, one of its dependencies (xsimd) tries to download source from the internet, which doesn't work in the openSUSE Build Service (build workers have no internet access).</p> Ceph - Bug #55087 (Resolved): rpm: openSUSE needs libthrift-devel, not thrift-develhttps://tracker.ceph.com/issues/550872022-03-28T09:42:57ZTim Serongtserong@suse.com
<p>In <a class="external" href="https://github.com/ceph/ceph/pull/38783">https://github.com/ceph/ceph/pull/38783</a>, <a class="external" href="https://github.com/ceph/ceph/pull/38783/commits/80e82686eba">https://github.com/ceph/ceph/pull/38783/commits/80e82686eba</a> added "thrift-devel >= 0.13.0" as a BuildRequires. On SUSE distros, this package is named libthrift-devel, so we need an <code>%if 0%{?suse_version}</code> block around that one.</p> Ceph - Bug #55079 (Pending Backport): rpm: remove contents of build directory at end of %install ...https://tracker.ceph.com/issues/550792022-03-28T04:02:45ZTim Serongtserong@suse.com
<p>I've been doing some measurements of disk usage during SUSE RPM builds (of Pacific, but this should roughly apply for newer Cephs too). In our particular build environment, which builds everything in VMs, we see something like this:</p>
<pre>
Filesystem Size Used Avail Use% Mounted on
df start of build: /dev/vda 53G 14G 40G 25% /
df end of build: /dev/vda 53G 31G 23G 58% /
df end of install: /dev/vda 53G 39G 15G 74% /
df before clamscan: /dev/vda 53G 41G 13G 78% /
df after clamscan: /dev/vda 53G 50G 3.9G 93% /
</pre>
<p>So after compiling everything, we've consumed about 17GB (that's all the binaries and object files and whatnot that end up in the "build" directory in the source tree). Then, after %install (which installs everything in the build root, ready to be turned into actual RPMs), we've used another 8GB. The next part - the clamscan bit - is one of the rpmlint checks SUSE runs, which takes another 9G when it extracts all the built RPMs (including debuginfo RPMs), in order to scan them.</p>
<p>In summary, our build worker VMs currently need a bit over 50G disk to build Ceph.</p>
<p>If I add <code>`rm -rf build`</code> to the very end of the <span>install section, to get rid of the 17GB of built binaries, we go into clamscan with 24G free, rather than 41G free, and when clamscan finishes we're using 32G. This means the peak build disk usage with that change is about 39G, so we reduce our build worker's disk space requirements by about 11G (or 20</span>%).</p> Ceph - Bug #53060 (Closed): Unable to load libceph_snappy.so due to undefined symbol _ZTIN6snappy...https://tracker.ceph.com/issues/530602021-10-27T09:21:47ZTim Serongtserong@suse.com
<p>If you try to run Ceph with snappy 1.1.9 installed, <code>ceph status</code> will show HEALTH_WARN, and tell you that your OSDs "have broken BlueStore compression". <code>ceph health detail</code> will tell you that each of your OSDs is "unable to load:snappy". The OSD logs will show something like this:</p>
<pre>
Oct 27 08:55:33 node1 ceph-osd[561817]: load failed dlopen(): "/usr/lib64/ceph/compressor/libceph_snappy.so: undefined symbol: _ZTIN6snappy6SourceE" or "/usr/lib64/ceph/libceph_snappy.so: cannot open shared object file: No such file or directory"
Oct 27 08:55:33 node1 ceph-osd[561817]: create cannot load compressor of type snappy
</pre>
<p>This is because RTTI was disabled in snappy 1.1.9, so the typeinfo for the <code>snappy::Source</code> class - which Ceph's SnappyCompressor creates a subclass of - isn't included in libsnappy.so. Ceph still <em>builds</em> just fine, because the compressors are built as shared libraries. The problem only manifests when our snappy plugin is dlopen()ed at runtime, and then the linker kicks in and can't find that missing symbol.</p>
<p>This would ideally be fixed by getting RTTI re-enabled in snappy, so I've gone ahead and opened <a class="external" href="https://github.com/google/snappy/pull/144">https://github.com/google/snappy/pull/144</a></p> RADOS - Bug #52553 (Resolved): pybind: rados.RadosStateError raised when closed watch object goes...https://tracker.ceph.com/issues/525532021-09-09T07:06:25ZTim Serongtserong@suse.com
<p>This one is easiest to demonstrate by example. Here's some code:</p>
<pre>
#!/usr/bin/env python3
import rados
def notify(notify_id, notifier_id, watch_id, data):
pass
if __name__ == "__main__":
cluster = rados.Rados(conffile="/etc/ceph/ceph.conf")
cluster.connect()
ioctx = cluster.open_ioctx("aquarium")
watch = ioctx.watch("kvstore", notify)
watch.close()
cluster.shutdown()
</pre>
<p>If I run that, I see the following error output:</p>
<pre>Traceback (most recent call last):
File "rados.pyx", line 477, in rados.Rados.require_state
rados.RadosStateError: RADOS rados state (You cannot perform that operation on a Rados object in state shutdown.)
Exception ignored in: 'rados.Watch.__dealloc__'
Traceback (most recent call last):
File "rados.pyx", line 477, in rados.Rados.require_state
rados.RadosStateError: RADOS rados state (You cannot perform that operation on a Rados object in state shutdown.)
</pre>
<p>What's happening here, is that even though I called <code>watch.close()</code>, later, once the watch goes out of scope, its <code>__dealloc__()</code> method tries to close the watch <em>again</em>, after first calling <code>self.ioctx.rados.require_state("connected")</code>, which results in that exception.</p>
<p>The fix is easy:</p>
<pre>
diff --git a/src/pybind/rados/rados.pyx b/src/pybind/rados/rados.pyx
index 4a5db349516..8772942e7ca 100644
--- a/src/pybind/rados/rados.pyx
+++ b/src/pybind/rados/rados.pyx
@@ -2025,6 +2025,8 @@ cdef class Watch(object):
return False
def __dealloc__(self):
+ if self.id == 0:
+ return
self.ioctx.rados.require_state("connected")
self.close()
</pre>
<p>The one thing I can't work out how to do, is write a test for this case, because as the exception is in <code>__dealloc__</code>, it gets printed to stderr, but is otherwise ignored, so I can't seem to catch it anywhere in src/test/pybind/test_rados.py</p> Orchestrator - Bug #45393 (Resolved): Containerized osd config must be updated when adding/removi...https://tracker.ceph.com/issues/453932020-05-06T06:41:14ZTim Serongtserong@suse.com
<p>Try this:</p>
<p>- bootstrap a cluster (1 mon, 1 mgr)<br />- add a bunch of osds (<code>ceph orch apply osd --all-available-devices</code>)<br />- add some more mons and mgrs (<code>ceph orch apply mon 3 ; ceph orch apply mgr 3</code>)</p>
<p>At this point, ceph.conf as seen by the osds (/var/lib/ceph/$FSID/osd.$ID/config) still only lists the first mon. If you restart any osds, and that first mon is down for some reason, the osd's can't join the cluster, because they don't know the other mons exist. They'll just sit there logging "monclient(hunting): authenticate timed out after 300" every five minutes until that first mon comes back.</p>
<p>I can think of two potential ways to address this:</p>
<p>1) Have <code>cephadm mon apply</code> go out and update every single osd config file with the new list of mons. This would of course not work completely if some osd hosts were down at the time. Also it might take a while...<br />2) Have the osds update their own config file automatically based on current monmaps.</p>
<p>This probably also needs to go into troubleshooting docs (check mon_host in each containerized osd's individual config file)</p> RADOS - Backport #38850 (Resolved): upgrade: 1 nautilus mon + 1 luminous mon can't automatically ...https://tracker.ceph.com/issues/388502019-03-22T10:19:17ZTim Serongtserong@suse.com
<p>Seen while upgrading Luminous (12.2.10) to Nautilus (14.2.0). Three mon hosts, four osd hosts. The process was:</p>
<p>- Shutdown mon1 (quorum in now mon2+mon3, both Luminous)<br />- Upgrade mon1 to Nautilus<br />- Start mon1 again. mon1 joins cluster, `ceph health` reports all three mons OK<br />- Shutdown mon2 (leaving mon1 = Nautilus and mon3 = Luminous)<br />- `ceph health` is now broken (eventually times out)<br />- mon1 logs repeat:</p>
<pre>2019-03-22 09:50:21.634 7f31906d1700 1 mon.mon1@0(electing) e1 peer v1:172.16.1.13:6789/0 release < min_mon_release, or missing features 0</pre>
<p>- mon3 logs repeat:</p>
<pre>2019-03-22 09:51:59.644672 7fa9f589a700 -1 mon.mon3@2(probing) e1 handle_probe missing features, have 4611087853745930235, required 0, missing 0</pre>
<p>This means that the cluster is effectively down until you're able to complete the upgrade of mon2.</p>
<p>Curiously, on mon1 (Nautilus):</p>
<pre># ceph daemon mon.$(hostname) mon_status|grep min_mon_release
"min_mon_release": 12,
"min_mon_release_name": "luminous",
</pre>
<p>So why is it comlaining about release < min_mon_release?</p>
<p>Even more interesting, I can run this on the Luminous mon:</p>
<pre># ceph daemon mon.$(hostname) quorum enter
started responding to quorum, initiated new election</pre>
<p>...and <strong>bam</strong> a few seconds later, we're in business again:</p>
<pre># ceph status
cluster:
id: 44e4a575-5c31-3c61-88c5-001ea49e8aaa
health: HEALTH_WARN
1/3 mons down, quorum mon1,mon3
services:
mon: 3 daemons, quorum mon1,mon3, out of quorum: mon2
mgr: mon3(active), standbys: mon1
osd: 30 osds: 30 up, 30 in
data:
pools: 1 pools, 512 pgs
objects: 0 objects, 0B
usage: 30.3GiB used, 567GiB / 597GiB avail
pgs: 512 active+clean
</pre>
<p>Not that "quorum enter" doesn't help if run from the Nautilus mon, it only works when run from the Luminous mon.</p> Ceph - Bug #37503 (Resolved): Audit log: mgr module passwords set on CLI written as plaintext in ...https://tracker.ceph.com/issues/375032018-12-03T10:57:04ZTim Serongtserong@suse.com
<p>A number of mgr modules need passwords set for one reason or another, either to authenticate with external systems (deepsea, influx, diskprediction), or to define credentials for users of those modules (dashboard, restful).</p>
<p>In all cases, these passwords are set from the command line, either via module-specific commands (<code>`ceph dashboard ac-user-create`</code>, <code>`deepsea config-set salt_api_password`</code>, etc.) or via <code>`ceph config set`</code> with some particular key (e.g.: mgr/influx/passsword)</p>
<p>All module-specific commands go through <code>DaemonServer::_handle_command()</code>, which then logs the command via <code>audit_clog->debug()</code> (or <code>audit_clog->info()</code> in case of access denied). This all ends up written to <code>/var/log/ceph/ceph-mgr.$ID.log</code>, which is world-readable, e.g.:</p>
<pre>
2018-12-03 10:45:28.864 7f67e7f8f700 0 log_channel(audit) log [DBG] : from='client.343880 172.16.1.254:39896/3560370796' entity='client.admin' cmd=[{"prefix": "deepsea config-set", "key": "salt_api_password", "value": "foo", "target": ["mgr", ""]}]: dispatch
</pre>
<p>Additionally, anything that results in a "config set" lands in the mon log, e.g.:</p>
<pre>
2018-12-03 10:45:28.881552 [INF] from='mgr.295252 172.16.1.21:56636/175641' entity='mgr.data1' cmd='[{"prefix":"config set","who":"mgr","name":"mgr/deepsea/salt_api_password","value":"foo"}]': finished
</pre>
<p>This also appears in the Audit log in the Dashboard.</p>
<p>Some things that land in the mon log probably don't matter; for any module that hashes passwords before saving them, only the hashed password should land in the mon log. But there's still the problem of the CLI commands in the mgr log, and in any case, modules that need to authenticate with external services will need to store plaintext passwords.</p>
<p>ISTM we need to either never log these things, or somehow keep the command logging, but filter the passwords out, so it renders the value as "*****" instead of the actual password.</p>
<p>I'm not sure how best to approach this, given the way command logging is structured. At the point commands are logged, the commands themselves are just strings. Admittedly, they're strings of JSON, but they're effectively opaque at that point - we'd have to parse the JSON, then look for things that might be passwords, blank them out, and turn the whole lot back into a string. Yuck.</p> Ceph - Bug #35906 (Resolved): ceph-disk: is_mounted() returns None for mounted OSDs with Python 3https://tracker.ceph.com/issues/359062018-09-10T11:10:49ZTim Serongtserong@suse.com
<p>`ceph-disk list --format=json` on python 3 gives null for the mount member, even for mounted OSDs, e.g.:</p>
<pre>
# ceph-disk list --format=json|json_pp
...
{
"path" : "/dev/vdg",
"partitions" : [
{
"whoami" : "23",
"is_partition" : true,
"path" : "/dev/vdg1",
"ceph_fsid" : "00296336-7bf2-43f1-a48c-24c7212bf478",
"dmcrypt" : {},
"uuid" : "b447f027-f116-47d0-9cd1-ca2348e8e3db",
"block_uuid" : "dfaf6613-f958-497a-9dfb-ad343e897639",
"block_dev" : "/dev/vdg2",
"type" : "data",
*"mount" : null,*
"ptype" : "4fbd7e29-9d25-41b8-afd0-062c0ceff05d",
"magic" : "ceph osd volume v026",
"cluster" : "ceph",
"state" : "prepared",
"fs_type" : "xfs"
},
{
"type" : "block",
"is_partition" : true,
"path" : "/dev/vdg2",
"ptype" : "cafecafe-9b03-4f30-b4c6-b4b80ceff106",
"block_for" : "/dev/vdg1",
"dmcrypt" : {},
"uuid" : "dfaf6613-f958-497a-9dfb-ad343e897639"
}
]
}
...
</pre> mgr - Bug #19629 (Resolved): mgr: set_config from python module crashes mgr (assertion failure du...https://tracker.ceph.com/issues/196292017-04-14T05:40:39ZTim Serongtserong@suse.com
<p>Tried `ceph tell mgr enable_auth false` (enable_auth being implemented by the rest module). The ceph CLI became unresponsive (never returned to the shell). Meanwhile, mgr crashed with:<br /><pre>
-8> 2017-04-14 15:34:45.938295 7f00c778a700 4 mgr[rest] handle_command: {
"prefix": "enable_auth",
"val": "false"
}
-7> 2017-04-14 15:34:45.938336 7f00c778a700 1 lockdep using id 41
-6> 2017-04-14 15:34:45.938369 7f00c778a700 10 monclient: _send_command 5 [{"prefix":"config-key put","key":"mgr.rest.enable_auth","val":"false"}]
-5> 2017-04-14 15:34:45.938376 7f00c778a700 10 monclient: _send_mon_message to mon.b at 127.0.0.1:40447/0
-4> 2017-04-14 15:34:45.938381 7f00c778a700 1 -- 127.0.0.1:0/3288703021 --> 127.0.0.1:40447/0 -- mon_command({"prefix":"config-key put","key":"mgr.rest.enable_auth","val":"false"} v 0) v1 -- 0x55ea04db41c0 con 0
-3> 2017-04-14 15:34:45.938756 7f00caf91700 1 -- 127.0.0.1:0/3288703021 <== mon.1 127.0.0.1:40447/0 25 ==== mon_command_ack([{"prefix":"config-key put","key":"mgr.rest.enable_auth","val":"false"}]=-13 access denied v0) v1 ==== 117+0+0 (2523711155 0 0) 0x55ea04db41c0 con 0x55ea02d59800
-2> 2017-04-14 15:34:45.938773 7f00caf91700 10 monclient: handle_mon_command_ack 5 [{"prefix":"config-key put","key":"mgr.rest.enable_auth","val":"false"}]
-1> 2017-04-14 15:34:45.938778 7f00caf91700 10 monclient: _finish_command 5 = -13 access denied
0> 2017-04-14 15:34:45.940929 7f00c778a700 -1 /home/tserong/src/github/SUSE/ceph/src/mgr/PyModules.cc: In function 'void PyModules::set_config(const string&, const string&, const string&)' thread 7f00c778a700 time 2017-04-14 15:34:45.938831
/home/tserong/src/github/SUSE/ceph/src/mgr/PyModules.cc: 546: FAILED assert(set_cmd.r == 0)
</pre></p>
<p>Why is the mon giving mgr "access denied" when it tries to set a config key?</p>
<p>We should consider getting rid of that assert too...</p> Ceph - Bug #18163 (Resolved): platform.linux_distribution() is deprecated; stop using ithttps://tracker.ceph.com/issues/181632016-12-07T04:10:56ZTim Serongtserong@suse.com
<p>platform.linux_distribution() is deprecated, so we should stop using it. Notably it uses /etc/SuSE-release on SUSE systems, and the latest SUSE versions don't ship this file; instead they ship /etc/os-release, which platform.linux_distribution() doesn't know about, so it returns ('','','').</p>
<p>AFAICT, platform.linux_distribution() is currently used by ceph-detect-init, which in turn is used by ceph-disk. If ceph-detect-init can't determine the distro because it sees ('','',''), this results in ceph-disk always tagging the init system as sysvinit.</p>
<p>There are also platform.linux_distribution() invocations in qa/workunits/ceph-disk/ceph-disk-no-lockbox and src/ceph-disk/ceph_disk/main.py, but they look like dead code to me.</p>
<p>See also bug <a class="issue tracker-1 status-3 priority-4 priority-default closed" title="Bug: platform.linux_distribution() is deprecated; stop using it (Resolved)" href="https://tracker.ceph.com/issues/18141">#18141</a></p> Ceph - Bug #14864 (Resolved): ceph-detect-init requires python-setuptools at runtimehttps://tracker.ceph.com/issues/148642016-02-25T14:58:49ZTim Serongtserong@suse.com
<p>Testing a reasonably recent ceph-10.0.2 on openSUSE Leap 42.1, my OSDs weren't mounting. I tracked this back to /usr/lib/systemd/system/ceph-disk@.service which invokes `flock /var/lock/ceph-disk /usr/sbin/ceph-disk --verbose --log-stdout trigger --sync %f`. This in turn results in:</p>
<pre>
ceph-disk: main_trigger: Namespace(dev='/dev/sdb1', func=<function main_trigger at 0x7fa6ebf6b050>, log_stdout=True, prepend_to_path='/usr/bin', prog='ceph-disk', statedir='/var/lib/ceph', sync=True, sysconfdir='/etc/ceph', verbose=True)
ceph-disk: Running command: /sbin/init --version
/sbin/init: unrecognized option '--version'
ceph-disk: get_dm_uuid /dev/sdb1 uuid path is /sys/dev/block/8:17/dm/uuid
ceph-disk: Running command: /usr/sbin/sgdisk -i 1 /dev/sdb
ceph-disk: get_dm_uuid /dev/sdb1 uuid path is /sys/dev/block/8:17/dm/uuid
ceph-disk: Running command: /usr/sbin/sgdisk -i 1 /dev/sdb
ceph-disk: trigger /dev/sdb1 parttype 4fbd7e29-9d25-41b8-afd0-062c0ceff05d uuid 93b72ed5-7d84-4b0b-a227-330fcd22513e
ceph-disk: Running command: /usr/sbin/ceph-disk activate /dev/sdb1
Traceback (most recent call last):
File "/usr/bin/ceph-detect-init", line 5, in <module>
from pkg_resources import load_entry_point
ImportError: No module named pkg_resources
ERROR:ceph-disk:Failed to activate
Traceback (most recent call last):
File "/usr/sbin/ceph-disk", line 4036, in <module>
main(sys.argv[1:])
File "/usr/sbin/ceph-disk", line 3992, in main
main_catch(args.func, args)
File "/usr/sbin/ceph-disk", line 4014, in main_catch
func(args)
File "/usr/sbin/ceph-disk", line 2530, in main_activate
reactivate=args.reactivate,
File "/usr/sbin/ceph-disk", line 2296, in mount_activate
(osd_id, cluster) = activate(path, activate_key_template, init)
File "/usr/sbin/ceph-disk", line 2477, in activate
init = init_get()
File "/usr/sbin/ceph-disk", line 799, in init_get
'--default', 'sysvinit',
File "/usr/sbin/ceph-disk", line 902, in _check_output
raise error
subprocess.CalledProcessError: Command '/usr/bin/ceph-detect-init' returned non-zero exit status 1
</pre>
<p>The important part is:</p>
<pre>
Traceback (most recent call last):
File "/usr/bin/ceph-detect-init", line 5, in <module>
from pkg_resources import load_entry_point
ImportError: No module named pkg_resources
</pre>
<p>This is fixable by installing python-setuptools, suggesting that package needs to be added to the RPM Requires and, I assume, the Debian Depends.</p>