On Wed, Jul 2, 2014 at 6:18 AM, Sylvain Munaut <s.munaut at whatever-company.com> wrote: > Hi, > > > I'm having a couple of issues during this update. On the test cluster > it went fine, but when running it on production I have a few issues. > (I guess there is some subtle difference I missed, I updated the test > one back when emperor came out). > > For reference, I'm on ubuntu precise, I use self-built packages > (because I'm hitting bugs that are not fixed in the latest official > ones, but there is no change whatsoever to the debian/ directory > except the changelog and they're built with the dpkg-buildpackage). I > did a 'apt-get dist-upgrade' to upgrade everything despite the new > requirements. > > > * The first one is essentially the same as > http://permalink.gmane.org/gmane.comp.file-systems.ceph.devel/19632 > > dpkg: error processing > /var/cache/apt/archives/ceph-common_0.80.1-1we3_amd64.deb (--unpack): > trying to overwrite '/etc/ceph/rbdmap', which is also in package ceph > 0.80.1-1we3 > > apt complained about /etc/ceph/rbdmap being in two package and refused > to go further. I ended up using -o Dpkg::Options::="--force-overwrite" > to force it to go on (because it just left some weird inconsistent > state and I needed to clean up the mess), but this seems wrong. > > > * The second one is that apparently it ran a "rm /etc/ceph" somehow > ... on my setup this is not a directory, but a symlink to the real > place the config is stored (the root partition is considered > 'expendable', so machine specific config is elsewhere). It also tried > to erase the /var/log/ceph but failed: I can't help you with packaging issues, but i can tell you that the rbdmap executable got moved to a different package at some point, but I believe the official ones handle it properly. And I'm just guessing here (like I said, can't help with packaging), but I think the deleted /etc/ceph is a result of the force-overwrite option you used. > > --- > Replacing files in old package ceph-common ... > dpkg: warning: unable to delete old directory '/var/log/ceph': > Directory not empty > --- > > > * And finally the upgraded monitor can't join the existing quorum. > Nowhere in the firefly update notes does it say that the new mon can't > join an old quorum. When this was the case back in dumpling, there was > a very explicit explanation but here it just doesn't join and spits > out "pipe fault" in the logs continuously. > > Now it might be "normal", but being the production cluster, I can't > risk and upgrading more than half the mons if I'm not sure this is > indeed normal and not a symptom that the install/update failed and > that the mon is not actually working. That's not normal. A first guess is that you didn't give the new monitor the same keyring as the old ones, but I couldn't say for sure without more info. Turn up logging and post it somewhere? -Greg Software Engineer #42 @ http://inktank.com | http://ceph.com > > > > Cheers, > > Sylvain > _______________________________________________ > ceph-users mailing list > ceph-users at lists.ceph.com > http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
 |