Well, I think I got it. Thanks to everyone who was able to provide the
input both here on the list and in the #svn IRC channel .
As a final summary of what was happening.... ends up that the libdb4.4 I
had on the system had a bug that broke subversion back in 2007. So
upgrading everything to 4.4 exposed this fact. If anyone is curious, I
found out about the bug at
http://www.mail-archive.com/ubuntu-bugs@lists.ubuntu.com/msg458623.html.
Upgrading
it a few point releases higher... and bam... the dump is working and will
finally let me kill off this old server and move to fsfs.
Thanks again for all the help and letting me get back my weekend!
Regards,
Dana
On Fri, Aug 16, 2013 at 5:12 PM, Dana Epp <dana_at_vulscan.com> wrote:
> Well, we are making some progress. All binaries are linked to libdb-4.4. I
> ended up having to move subversion to v1.4 for this.
>
> When I try a dump I now get:
>
> svnadmin: Berkeley DB error for filesystem '/var/svn/db' while committing
> Berkeley DB transaction:
> DB_RUNRECOVERY: Fatal error, run database recovery
> svnadmin: bdb: not a restored transaction
> svnadmin: bdb: PANIC: Invalid argument
>
> So I run db4.4_recover and it says it succeeds. I try a using svnadmin to
> dump and it fails like before. I try to do a svnadmin recover and the same
> thing.
>
> Any ideas on what to do next? I am unsure what "not a restored
> transaction" means in this context.
>
> Regards,
> Dana
>
>
>
>
> On Fri, Aug 16, 2013 at 4:36 PM, Dana Epp <dana_at_vulscan.com> wrote:
>
>> Ya, that was what I meant. 4.4. I imagine if svnadmin is at 4.4, this
>> should all work. I took a snapshot of the VM and am now walking through
>> upgrades until I find a subversion package with libdb4.4. The guys at
>> snapshot.debian.org are my hero... without that side I would be dead in
>> the water.
>>
>> Fingers crossed.
>>
>> Dana
>>
>>
>> On Fri, Aug 16, 2013 at 4:25 PM, Bert Huijben <bert_at_qqmail.nl> wrote:
>>
>>> If all commits were through that mod_dav_svn, you should get an svnadmin
>>> that is linked to the same BDB as that mod_dav_svn.****
>>>
>>> ** **
>>>
>>> It is not unlikely that there is somewhere a second install of
>>> Subversion on you machine. (Maybe in some home directory?). Trying to
>>> locate that one might be easier than building one yourself.****
>>>
>>> ** **
>>>
>>> Having the same BDB version is more important than having the exact
>>> Subversion version. (Although I would recommend backing up whatever you
>>> have now, to make sure you don’t break it by trying to recover).****
>>>
>>> ** **
>>>
>>> I know many Windows tools use BDB 4.4.20, so that might be an easy way
>>> to get access to such tools. But I don’t know if the BDB database format is
>>> fully compatible between platforms. (fsfs is fully compatible, but that
>>> doesn’t help you now)****
>>>
>>> ** **
>>>
>>> Bert****
>>>
>>> ** **
>>>
>>> *From:* Dana Epp [mailto:dana_at_vulscan.com]
>>> *Sent:* zaterdag 17 augustus 2013 01:14
>>> *To:* Chris Shelton
>>> *Cc:* users
>>> *Subject:* Re: Have an old SVN 1.1 DB corruption issue and need some
>>> help****
>>>
>>> ** **
>>>
>>> Ya, I will definitely load the repo into fsfs on the new system.****
>>>
>>> ****
>>>
>>> I tried the recovery to no avail yesterday.****
>>>
>>> ****
>>>
>>> I just completed a restore of the VM to a state before all this started
>>> and here is what I now see.****
>>>
>>> ****
>>>
>>> Trying to run an svnadmin dump gives me:****
>>>
>>> ****
>>>
>>> svn: bdb: Program version 4.2 doesn't match environment version****
>>>
>>> When I look at the versions using ldd, here is what I see:****
>>>
>>> ****
>>>
>>> mod_dav_svn (which is what everyone is using to check in) is linked to
>>> libdb4.4****
>>>
>>> ****
>>>
>>> svnadmin is linked to libdb4.2****
>>>
>>> ****
>>>
>>> svn is linked to libdb4.2****
>>>
>>> ****
>>>
>>> So is my solution to fix this to upgrade svnadmin to a version linked to
>>> libdb4.2?****
>>>
>>> ****
>>>
>>> Regards,****
>>>
>>> Dana****
>>>
>>> ****
>>>
>>> ****
>>>
>>> ****
>>>
>>> ****
>>>
>>> ** **
>>>
>>> On Fri, Aug 16, 2013 at 12:40 PM, Chris Shelton <
>>> cshelton_at_shelton-family.net> wrote:****
>>>
>>> Dana,****
>>>
>>> ** **
>>>
>>> This page of the subversion book sounds like it might be helpful in your
>>> situation:****
>>>
>>> http://subversion.apache.org/faq.html#wedged-repos****
>>>
>>> ** **
>>>
>>> I am sure that switching to a FSFS repository data store with your new
>>> system is advisable.****
>>>
>>> ** **
>>>
>>> chris****
>>>
>>> ** **
>>>
>>> On Fri, Aug 16, 2013 at 1:37 PM, Dana Epp <dana_at_vulscan.com> wrote:****
>>>
>>> I have inherited a REALLY old SVN server that was mismanaged for
>>> years. They were using WebDAV successfully for so long they never noticed
>>> any issues under the hood, but the BDB is corrupt and cannot run an
>>> svnadmin dump on it to move it to a new server that I built that has all
>>> the latest SVN bits.****
>>>
>>> ****
>>>
>>> The old system is running SVN 1.1.1 with BDB 4.2.52.****
>>>
>>> ****
>>>
>>> At this point after following several different pieces of guidance
>>> online the system starts a dump, and ends up after several "Dumped revision
>>> #" pukes out hundreds of the following lines:****
>>>
>>> ****
>>>
>>> svn: bdb: DB_ENV->log_flush: LSN of 56874/862249 past current end-of-log
>>> of 1/2786
>>> svn: bdb: Database environment corrupt; the wrong log files may have
>>> been removed or incompatible database files imported from another
>>> environment****
>>>
>>> ****
>>>
>>> Does anyone know where I should go from here? Does anyone know of anyone
>>> consulting on these sort of repairs? I did a full export of the whole repro
>>> using WebDAV before I started this, so I have HEAD, but I don't want to
>>> lose the history if I don't have to.
>>>
>>> --
>>> Regards,
>>> Dana ****
>>>
>>> ** **
>>>
>>>
>>>
>>>
>>> --
>>> Regards,
>>> Dana Epp
>>> Microsoft Security MVP ****
>>>
>>
>>
>>
>> --
>> Regards,
>> Dana Epp
>> Microsoft Security MVP
>>
>
>
>
> --
> Regards,
> Dana Epp
> Microsoft Security MVP
>
--
Regards,
Dana Epp
Microsoft Security MVP
Received on 2013-08-17 02:32:02 CEST