[mythtv-users] database recovery, no backup [solved except FE segfaults]

[Ross Boylan]

I think I have solved the original problem by (simplifying from some false
starts), although now I'm getting segfaults on the 0.25 front end:

Removed 0.25 myth, leaving database.
Install myth 0.24.2 including the mythvideo package.
Edit the schema version in the DB to be 1264 (it was 1266) (myth 0.24.2
backend refuses to run otherwise).
Start backend.
Start frontend to invoke mythvideo database upgrade code.  Permit the
upgrade to run.
At this  point I have a non-crazy 0.24.2 database.

Remove myth 0.24.2
Install 0.25.
Database upgrades.
Backend will run.

All is not completely well: the frontend segfaults before opening any
windows.  I suspect there is a version mismatch with some of the libraries
like Qt.  I have not kept the VM current since these problems developed a
couple months ago (on the "if you're in a ditch, stop digging" principle).

I also though I had seen some posts about problems caused by upgrading
mysql from 5.1 to 5.5, which is what Debian wants to do.  The depencies do
not let me upgrade qt without messing with mysql and/or myth (in the case
of myth, that is "messing" in the sense of "removing").

Oddly, if the frontend starts on a different account (root) it is able to
popup the window asking for the database connection parameters (somewhat
inconsistent with my theory about Qt version problems, assuming the window
uses Qt).  After I enter those, the front-end segfaults.

Further comments below.
On Thu, Aug 16, 2012 at 9:34 AM, Michael T. Dean <mtdean at thirdcontact.com>wrote:

> On 08/09/2012 07:16 PM, Ross Boylan wrote:
>
>> On Sat, 2012-07-21 at 10:12 -0400, Michael T. Dean wrote:
>>
>>> On 07/20/2012 11:46 AM, Ross Boylan wrote:
>>>
>>>> During an upgrade from .24 to .25 (using Marillat's Debian repository)
>>>> my database got borked and the system won't start.  The standard advice
>>>> is to restore from backup, but I don't have one.
>>>>
>>>> I have all the recordings, and I assume that data is likely still in the
>>>> database.  I tried a little debugging, but haven't located the schema
>>>> migration code.
>>>>
>>>> Any advice about the best way to proceed?
>>>>
>>> Before MythTV upgrades the database, it will try its best to create a
>>> database backup (unless you explicitly tell it not to with a setting).
>>> It will place the backup in one of the directories in your DB Backups
>>> Storage Group.  If you haven't specified a directory list for DB
>>> Backups, it will place the backup in one of the directories in your
>>> Default Storage Group.  If it can't find any of the directories it
>>> should use, it will place the backup in your /tmp directory.
>>>
>>> Look carefully through your MythTV Storage Group directories for a
>>> backup:  ls /path/to/directory/*.sql*
>>>
>>> Assuming you find it, do a full restore, then attempt a DB upgrade using
>>> mythtv-setup. If it fails, please provide the log output from that
>>> mythtv-setup run (i.e. start the program using:  mythtv-setup --logpath
>>> /path/to/some/directory and it will create a log file in the specified
>>> director).
>>>
>> Thank you for the pointers.  Unfortunately, there don't seem to be any
>>
>> such files in my chroot (there are a couple of /tmp/*.sql*, but they are
>> from the original install of 0.24.2). I used 'find' for all filesystems
>> mounted in the chroot to be sure.
>>
>
>
> From your other thread ( http://www.gossamer-threads.**
> com/lists/mythtv/users/525478#**525478<http://www.gossamer-threads.com/lists/mythtv/users/525478#525478>), the reason you don't have an automatically-created database backup is:
>
>
> 2012-05-13 21:31:48.041371 C [342/342] CoreContext dbutil.cpp:217
> (BackupDB) - Database backups disabled. Skipping backup.
>
> i.e. you explicitly disabled them with the mythtv-setup setting:
>

Yes.  I belatedly realized that when I got things running. One of my
reasons for doing so might suggest something that could be clarified: I may
have thought the backup would backup all my video files, not just the mysql
database.  I realize that's not so.

More at the bottom.

>
> Disable automatic database backup
> If enabled, MythTV will not backup the database before upgrades. You
> should therefore have your own database backup strategy in place.
>
> IMHO, you should really consider re-enabling the automatic,
> for-your-own-protection database backups so even if you don't manually
> create a backup, you have options when things go wrong.
>
Yes,

>
> I'll try to get a chance, soon, to look into the DB upgrade process for
> users without MythVideo schema, but last I tested, it worked fine.  I'm
> thinking if there was a problem, it was external to MythTV (i.e. something
> killed and restarted mythbackend during the upgrade because it wasn't
> responding or whatever...), but I will run a test, again, of a 0.24-0.25
> upgrade of a DB schema without MythVideo schema.
>
>
> Mike
>

Thanks for your help.  I'm not sure any checking is warranted; the only
explanation I can see of how things got this way required two odd things:
first, the file system filled in the middle of an install, leaving the
mythvideo tables in a very old state (since the code creates the tables by
making a very old version and then upgrading it).  Second, after I made
space I did not reinstall the mythvideo package (partly to save space), and
so it never had a chance to complete updating the tables.

If anyone has ideas about the segfault, or information on mysql 5.5
compatibility,  that would be great.

Ross
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20120816/8b77daab/attachment.html>