RossBoylan at stanfordalumni
Aug 21, 2012, 3:22 PM
Post #3 of 4
(261 views)
Permalink
|
|
Re: database recovery, no backup [all solved]
[In reply to]
|
|
When I upgraded all the packages in my chroot the FE stopped segfaulting
and everything seems to work (with MySql 5.5). Likely the problem was
that mythvideo was compiled against more recent libraries than I had
installed.
Thanks to Michael for his suggestions and information. A little more on
that below.
On Thu, 2012-08-16 at 15:26 -0400, Michael T. Dean wrote:
> On 08/16/2012 03:08 PM, Ross Boylan wrote:
> > 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").
>
> All MySQL 5.5 issues should now be fixed in current MythTV. I don't
> remember when we fixed them, but I know current 0.25-fixes works fine
> with MySQL 5.5. (I /think/ 0.24-fixes should, too, meaning even a
> "broken" 0.25, such as the 0.25 release tarball, should work.)
>
> > 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.
>
> The usual culprit for segfaults on startup after a version upgrade is
> having old versions of the MythTV libraries--and often, specifically,
> plugins--still on the system. For example, if you have the MythVideo
> plugin file in /usr/lib/mythtv/plugins/ , it will almost definitely
> cause mythfrontend to segfault on startup. Since there is no MythVideo
> in 0.25 (it was rolled into core), the plugin wouldn't be replaced by
> 0.25 packages, and it seems sometimes it gets left in place. The same
> goes for other outdated plugins, such as MythFlix or MythMovies or ...
I checked, but there didn't seem to be any of these. Removing a
package, e.g., mythvideo, should remove everything but its
configuration/data files, and in this case it seems to have worked.
>
> In the case of corrupted MythTV schema and/or data, a partial database
> restore is often the best approach. While it sounds like you may have
> other non-database problems (usually database issues won't result in
> segfaults), if you don't trust the provenance of your database/schema,
> you may want to consider creating a full backup of the 0.25 database,
> then doing
> http://www.mythtv.org/wiki/Database_Backup_and_Restore#Partial_restore_of_a_backup
> . Note, though, that it will require completely re-configuring
> everything after the partial restore.
>
> > Further comments below.
> > On Thu, Aug 16, 2012 at 9:34 AM, Michael T. Dean wrote:
> >> 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.
> > 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.
>
> Ah, yeah, if the file system filled up during the upgrade, that could
> definitely cause problems with the upgrade and leave the schema in a bad
> state. Thanks for the follow-up.
Likely anything that caused the backend to crash during an upgrade could
have produced the problems I saw. But it does require crash + removing
the mythvideo package to end up with the video related tables screwed
up.
Since there is no separate mythvideo as of 0.25, the opportunites for
even this weird problem should have diminished :)
Ross
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users
|
