upgrade from 0.25 to 0.27 failed

Bug #1221735 reported by john pleasa
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Mythbuntu
Invalid
Low
Unassigned

Bug Description

used 'agp-get dist-upgrade' to upgrade mythbuntu 12.04 from mythtv .25 to .27
upgrade failed with "error, no database selected" error.

ProblemType: Crash
DistroRelease: Ubuntu 12.04
Package: mythtv-common 2:0.27.0+fixes.20130906.e8093db-0ubuntu0mythbuntu2 [origin: LP-PPA-mythbuntu-0.27]
ProcVersionSignature: Ubuntu 3.2.0-30.48-generic 3.2.27
Uname: Linux 3.2.0-30-generic x86_64
NonfreeKernelModules: nvidia
.var.log.mythtv.mythavtest.log:

.var.log.mythtv.mythccextractor.log:

.var.log.mythtv.mythjobqueue.log:

.var.log.mythtv.mythlcdserver.log:

.var.log.mythtv.mythmediaserver.log:

.var.log.mythtv.mythshutdown.log:

.var.log.mythtv.mythtranscode.log:

.var.log.mythtv.mythutil.log:

.var.log.mythtv.mythwelcome.log:

ApportVersion: 2.0.1-0ubuntu13
Architecture: amd64
CrashDB: mythbuntu
Date: Fri Sep 6 07:52:39 2013
Disassembly: => 0x0: Cannot access memory at address 0x0
ExecutablePath: /usr/bin/mythlogserver
InstallationMedia: Mythbuntu 12.04.1 "Precise Pangolin" - Release amd64 (20120818.1)
Installed_mythtv_dbg: 2:0.27.0+fixes.20130906.e8093db-0ubuntu0mythbuntu2
ProcCmdline: /usr/bin/mythlogserver --daemon --verbose general --loglevel info --quiet --syslog local7
ProcEnviron:
 TERM=linux
 PATH=(custom, no user)
 LANG=en_US.UTF-8
SegvAnalysis:
 Segfault happened at: 0x0: Cannot access memory at address 0x0
 PC (0x00000000) not located in a known VMA region (needed executable region)!
 Stack memory exhausted (SP below stack segment)
SegvReason: executing NULL VMA
Signal: 11
SourcePackage: mythtv
StacktraceTop:
 ?? ()
 QObject::disconnect(QObject const*, char const*, QObject const*, char const*) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
 QObject::disconnect (this=0x7f0f2c00b6c0, receiver=0x7f0f2400b360, member=0x0) at /usr/include/qt4/QtCore/qobject.h:252
 nzmqt::PollingZMQContext::unregisterSocket (this=0x7f0f2400b360, socket_=0x7f0f2c00b6c0) at ../include/nzmqt/nzmqt.hpp:703
 nzmqt::PollingZMQContext::qt_static_metacall (_o=0x7f0f2400b360, _c=QMetaObject::InvokeMetaMethod, _id=3, _a=0x1481ac0) at moc_nzmqt.cpp:401
Title: mythlogserver crashed with SIGSEGV in QObject::disconnect()
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: audio cdrom dialout video

Revision history for this message
john pleasa (jzigpublic) wrote :
information type: Private → Public
Revision history for this message
Thomas Mashos (tgm4883) wrote :

Your /etc/mythtv/config.xml is incorrect. Please verify that the credentials and host in /etc/mythtv/config.xml matches that in /etc/mythtv/mysql.txt (to be clear, /etc/mythtv/mysql.txt is probably correct, and you need to fix /etc/mythtv/config.xml)

Changed in mythbuntu:
importance: Undecided → Low
status: New → Invalid
Revision history for this message
john pleasa (jzigpublic) wrote :

Looking back at the original drive before trying to upgrade, it turns out that the file /etc/mythtv/config.xml existed but was a file of zero length, causing the upgrade to produce a non-working /etc/mythtv/config.xml. Then when the upgrade gets to installing the 0.27 mythtvbackend package it fails with a "no database selected" error and halts the upgrade at that point leaving things in a non working state.

I have no idea why /etc/mythtv/config.xml was zero length. There is a valid config.xml at /home/ziggy/.mythtv/config.xml. Copying this file to /etc/mythtv/config.xml before trying to upgrade to 0.27 allows an upgrade to go to completion.

I have tried clean installs from the same media used originally and they produce /etc/mythtv/config.xml with proper settings. Some upgrade or configuration over the past year must have caused that file to be recreated with no contents.?.

Perhaps doing a sanity check on /etc/mythtv/config.xml before starting a 0.27 upgrade would be a good idea to prevent an upgrade failure.

Revision history for this message
tim davis (l0unchpad) wrote :

I had exactly the same problem and also found /etc/mythtv/config.xml was zero length, but the error persisted after correcting the file.

Turned out that I didn't have xpath installed (libxml-xpath-perl) and the mythtv-database package's postinit script suppresses errors from xpath.

libxml-xpath-perl is a dependency of mythtv-common, but not mythtv-database. I'm wondering now if it's simply because I tried using apt-get upgrade initially instead of dist-upgrade.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.