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:<br><br>Removed 0.25 myth, leaving database.<br>Install myth 0.24.2 including the mythvideo package.<br>
Edit the schema version in the DB to be 1264 (it was 1266) (myth 0.24.2 backend refuses to run otherwise).<br>Start backend.<br>Start frontend to invoke mythvideo database upgrade code. Permit the upgrade to run.<br>At this point I have a non-crazy 0.24.2 database.<br>
<br>Remove myth 0.24.2<br>Install 0.25.<br>Database upgrades.<br>Backend will run.<br><br>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).<br>
<br>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").<br>
<br>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.<br><br>Further comments below.<br><div class="gmail_quote">On Thu, Aug 16, 2012 at 9:34 AM, Michael T. Dean <span dir="ltr"><<a href="mailto:mtdean@thirdcontact.com" target="_blank">mtdean@thirdcontact.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 08/09/2012 07:16 PM, Ross Boylan wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On Sat, 2012-07-21 at 10:12 -0400, Michael T. Dean wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 07/20/2012 11:46 AM, Ross Boylan wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
During an upgrade from .24 to .25 (using Marillat's Debian repository)<br>
my database got borked and the system won't start. The standard advice<br>
is to restore from backup, but I don't have one.<br>
<br>
I have all the recordings, and I assume that data is likely still in the<br>
database. I tried a little debugging, but haven't located the schema<br>
migration code.<br>
<br>
Any advice about the best way to proceed?<br>
</blockquote>
Before MythTV upgrades the database, it will try its best to create a<br>
database backup (unless you explicitly tell it not to with a setting).<br>
It will place the backup in one of the directories in your DB Backups<br>
Storage Group. If you haven't specified a directory list for DB<br>
Backups, it will place the backup in one of the directories in your<br>
Default Storage Group. If it can't find any of the directories it<br>
should use, it will place the backup in your /tmp directory.<br>
<br>
Look carefully through your MythTV Storage Group directories for a<br>
backup: ls /path/to/directory/*.sql*<br>
<br>
Assuming you find it, do a full restore, then attempt a DB upgrade using<br>
mythtv-setup. If it fails, please provide the log output from that<br>
mythtv-setup run (i.e. start the program using: mythtv-setup --logpath<br>
/path/to/some/directory and it will create a log file in the specified<br>
director).<br>
</blockquote></div>
Thank you for the pointers. Unfortunately, there don't seem to be any<div class="im"><br>
such files in my chroot (there are a couple of /tmp/*.sql*, but they are<br>
from the original install of 0.24.2). I used 'find' for all filesystems<br>
mounted in the chroot to be sure.<br>
</div></blockquote>
<br>
<br>