Bug #9742
closed`rbd map lun` fails with: (2) No such file or directory on kernel 3.14.14 w/ udev-216 & ceph 0.80.5
0%
Description
when trying to map a standard rbd image as a block device, the command fails with (2) No such file or directory.
I can run other rbd commands without issue, including `rbd info lun01`.
This is a ceph cluster deployed using the manual instructions on ceph.com site on a gentoo distro. As far as I can tell, it appears that this might be a udev issue, as a call to /run/udev/queue is issued, and that path doesn't exist.
here's the dmesg | tail output after running the rbd map command:
[Fri Oct 10 16:22:47 2014] libceph: error -2 building auth method x request
[Fri Oct 10 16:22:47 2014] libceph: client4768 fsid 609823e1-1e38-4c1e-98fd-e5bfd90c2021
the ceph -s output:
n01 ceph # ceph -s
cluster 609823e1-1e38-4c1e-98fd-e5bfd90c2021
health HEALTH_OK
monmap e3: 4 mons at {0=192.168.9.61:6789/0,1=192.168.9.62:6789/0,2=192.168.9.63:6789/0,3=192.168.9.64:6789/0}, election epoch 8, quorum 0,1,2,3 0,1,2,3
mdsmap e20: 1/1/1 up {0=0=up:active}
osdmap e78: 8 osds: 8 up, 8 in
pgmap v5272: 1392 pgs, 5 pools, 2017 bytes data, 22 objects
32942 MB used, 108 TB / 108 TB avail
1392 active+clean
gw01 ~ # ceph auth list
installed auth entries:
mds.0
key: AQD6pzJUCIiKJhAArkrJ7DgvHL6Nu7HwzYEc0Q==
caps: [mds] allow
caps: [mon] allow rwx
caps: [osd] allow *
osd.0
key: AQAWpzFUyCW8IxAA1J6PTpwuGv3Ex0Jikg3pWA==
caps: [mon] allow profile osd
caps: [osd] allow *
osd.1
key: AQDzpjFUAM9dChAA7+U4dhdNj/9NM1a5Pz5hIQ==
caps: [mon] allow profile osd
caps: [osd] allow *
osd.2
key: AQA2njJUmBO8ARAA+Yj9mJFvLILP75oEV91MBA==
caps: [mon] allow profile osd
caps: [osd] allow *
osd.3
key: AQCGnjJUoJMMJBAA87D5vv/FWkQbHncepQ8udw==
caps: [mon] allow profile osd
caps: [osd] allow *
osd.4
key: AQCvsjFUAP5AERAASNk/nixpioEuFgAHAAeOWQ==
caps: [mon] allow profile osd
caps: [osd] allow *
osd.5
key: AQDHsjFUwEORLhAAVJ/L+Y8X3PEYwngW2z2qTQ==
caps: [mon] allow profile osd
caps: [osd] allow *
osd.6
key: AQDvpTJUqKHjCRAATShIUz81Z6awwdaGZUDC+g==
caps: [mon] allow profile osd
caps: [osd] allow *
osd.7
key: AQCypTJUgATHGBAAECHiQLCKtDG12JPuuiyO4g==
caps: [mon] allow profile osd
caps: [osd] allow *
client.admin
key: AQCTaB9UgJBtMRAA3hN/JL8oSdykvK7VbQc0Gw==
caps: [mds] allow
caps: [mon] allow *
caps: [osd] allow *
client.gw01
key: AQC8cDVUQGqPLxAA0rwPE1YkC1s9UJWEtx7/QA==
caps: [mon] allow rw
caps: [osd] allow rwx
Files
Updated by Sage Weil over 9 years ago
is this running inside a container? this looks lik ea problem with the authentication keys and there is a known issue there with network namespaces
Updated by Adeel N over 9 years ago
no, this is running on bare metal. should i try re-generating auth keys for everything?
Updated by Ilya Dryomov over 9 years ago
- Status changed from New to 12
- Assignee set to Ilya Dryomov
I'm guessing CRYPTO_CBC kernel config option is not enabled - -ENOENT is most likely because crypto core can't find an algorithm we want to use. It was an omission in libceph Kconfig, fixed in newer kernels. Adeel, can you grep your kernel config for CRYPTO_CBC?