On Thu, Apr 5, 2018 at 6:56 PM, Fred Drueck <fdru...@uic.edu> wrote: > Hello other OpenAFS users, > > I've recently setup a new file server to try and facilitate upgrading our > OpenAFS servers to a newer version of debian (the current stable distro: > stretch). > > The server and db server setup seems to have gone smoothly, but I've got > problems with moving the AFS volumes. > > If I try to do a vos move from the old fileserver to the new one, the move > will fail with: > > Failed to move data for the volume 536881885 > > VOLSER: Problems encountered in doing the dump ! > > However, if I work on the old file server, or another openafs client > system (in fact, I've got another debian stretch system using the exact > same version the debian openafs-client package) I can move the volume to > the new server. > > And I can verify by looking at the /vicepc directory that the file is > there, the vldb says it's there but if I try to move the file back to the > older server working on the new server it will fail with a message that the > volume is not found, something like: > > The volume 536881885 is not on the specified site. > The current site is : server newserver.math.uic.edu partition /vicepc > > OK ... but that's exactly the arguments I passed to vos as the -fromserver > and -toserver > > And, if I switch over to another openafs-client or the old AFS file server > I can issue the vos command to move the volume back just fine. > > Anybody have any ideas what's going wrong? > > -Fred >
Looking through the logs, the only thing I saw that looked maybe relevant was: Thu Apr 5 19:02:45 2018 VReadVolumeDiskHeader: Couldn't open header for volume 536881887 (errno 2). but if that's such a problem then why can the other AFS clients happily manipulate the volume? It's puzzling. -Fred
