| LinHES Forums http://forums.linhes.org/ |
|
| DB restore failed during upgrade / Recordings not playing http://forums.linhes.org/viewtopic.php?f=1&t=18530 |
Page 1 of 2 |
| Author: | john.lofgren [ Sat Jul 12, 2008 2:49 pm ] |
| Post subject: | DB restore failed during upgrade / Recordings not playing |
I am trying to auto-upgrade from R5F27 to R5.5. I got errors during the DB restore as shown below. Access denied for user 'root'@'localhost'. (Could this have to do with me installing phpmyadmin on R5F27?) So, I didn't notice the errors the first time I went through the upgrade, but discovered the problem when all my recording were missing. (Yikes!) So, I did a mythrestore manually as root. That seemed to put everything back in place. But... Now many of my recordings do not want to play. Some recordings play fine. Some when I start to play them the screen just stays black. When trying to play one of these, mythfrontend is taking a whole lot of CPU and working the hard drive real hard - harder than it should - but nothing appears on screen and no sound. I can still cancel the playback by pressing Exit/Escape twice, so it's not completely unresponsive. Both old and new recordings have this problem. Also, all the recordings have previews showing showing fine in the recordings window. Also, getting lots of these errors in mythbackend log: Code: 2008-07-12 15:41:03.761 Could not find channel 1_4 in CVCT 2008-07-12 15:41:03.762 VCT Cable: channels(4) tsid(0x8228) seclength(141) Channel #0 name(CBS2 Ch) 2-1 mod(SCTE mode 2) cTSID(0x8228) pnum(1) ETM_loc(0) access_ctrl(0) hidden(0) path_select(0) out_of_band(0) hide_guide(0) service_type(2) source_id(1) Channel #1 name(WTTW CR) 11-3 mod(SCTE mode 2) cTSID(0x8228) pnum(3) ETM_loc(0) access_ctrl(0) hidden(0) path_select(0) out_of_band(0) hide_guide(0) service_type(2) source_id(3) Channel #2 name(WTTW-DT) 11-4 mod(SCTE mode 2) cTSID(0x8228) pnum(4) ETM_loc(0) access_ctrl(0) hidden(0) path_select(0) out_of_band(0) hide_guide(0) service_type(2) source_id(4) Channel #3 name(WTTW HD) 11-1 mod(SCTE mode 2) cTSID(0x8228) pnum(2) ETM_loc(0) access_ctrl(0) hidden(0) path_select(0) out_of_band(0) hide_guide(0) service_type(2) source_id(2) Are these problems all related? Are they familiar to anyone else? Errors from auto-upgrade log: Code: ...
Completed the restore of files. Starting the DB restore, this can take a while... Clearing out the existing skeleton... ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES) Recreating the db... ^G/usr/bin/mysqladmin: connect to server at 'localhost' failed error: 'Access denied for user 'root'@'localhost' (using password: YES)' Restoring the data (long)... ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES) Doing any needed db updates... Completed the DB restore. Sanity checking your restore... Checking for the existance of the backup tar file... Using file /myth/backup/savedfiles.tar.gz Backup tar file exists. Checking the compression... Compression looks OK. Checking backup tar file contents... Generating a list of the backup contents... /bin/tar: ./etc/asound.conf: Not found in archive /bin/tar: ./etc/default/aumix: Not found in archive Generating a list of the directory contents... /usr/bin/find: ./etc/asound.conf: No such file or directory /usr/bin/find: ./etc/default/aumix: No such file or directory /usr/bin/find: ./var/lib/alsa/asound.state: No such file or directory Comparing directory versus backup contents... Live and saved file lists match. Checking for the existance of the DB dump file... Using file /myth/backup/mythconverg.sql.gz DB dump file exists. Checking the compression... Compression looks OK. Checking DB dump contents... Generating a list of tables and record counts in the DB dump... Generating a list of tables and record counts in the live DB... ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES) Warning, could not get record counts from live DB! The restore failed or was already modified! ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES) ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES) ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES) Doing any needed file updates... Stopping MythTV server: mythbackend No /usr/bin/mythbackend found running; none killed. . Starting MythTV server: mythbackend. ** Partial or total data restoration failure ** Please post the contents of /var/log/restore.log following 'Sanity checking your restore...' to the 'mythrestore failed' thread on http://mysettopbox.tv/phpBB2/viewforum.php?f=6 |
|
| Author: | john.lofgren [ Tue Jul 15, 2008 8:13 am ] |
| Post subject: | |
Anyone have some idea why access is denied to the database? What can I do to get some more clues? |
|
| Author: | tjc [ Tue Jul 15, 2008 5:50 pm ] |
| Post subject: | |
There is an issue where your DB config and MythTV config can get cross wired so that the DB is listening on one interface and MythTV is trying to connect to it on the other. There are a couple active thread discussing this (look for recent posts by graysky). |
|
| Author: | manicmike [ Tue Jul 15, 2008 7:15 pm ] |
| Post subject: | |
john.lofgren wrote: Anyone have some idea why access is denied to the database? What can I do to get some more clues?
It looks a lot like you set a root password for mysql. Did you? Mike |
|
| Author: | john.lofgren [ Sat Jul 19, 2008 6:24 am ] |
| Post subject: | |
Thanks for the responses - sorry I've been unable to respond until now. Quote: It looks a lot like you set a root password for mysql.
Did you? Good question. I'm not sure - that's why I was asking about phpmyadmin. It's possible that I did change a password at that time because I wanted the website to be secure. What is the normal username/password setup for mysql in KnoppMyth? Am I reading the log correctly - the upgrade script is trying to login to the database as root and expecting no password? |
|
| Author: | john.lofgren [ Sat Jul 19, 2008 7:17 am ] |
| Post subject: | |
(BTW, The following commands are being done on my reverted R5F27 system for the moment.) So, the answer would seem to be no, I don't have a root password set for mysql. I did the following and was able to login to mysql by just hitting enter when prompted for the password: Code: root@zebra:~# /usr/bin/mysql -u root -p Enter password: Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 12 Server version: 5.0.32-Debian_7etch1 Debian etch distribution Type 'help;' or '\h' for help. Type '\c' to clear the buffer. mysql> exit Bye As was suggested in http://mysettopbox.tv/phpBB2/viewtopic.php?t=18480, I tried running: Code: /usr/bin/mysql -u root mythconverg -e "show tables" I notice that I am able to run this successfully when logged in as root, but as any other user, the command fails with exactly the same error I was getting during install: Code: ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES)
Does the upgrade process run as root? Thanks for the help, John |
|
| Author: | tjc [ Sat Jul 19, 2008 9:56 am ] |
| Post subject: | |
It runs su or sudo to root but I'm not sure that it uses "su -", and mysql may be looking at real user id for some reason. It looks like you've set it to require a password for root even if it's empty, and since it is empty you can't even supply it on the command line. You may be able to get it to work by either setting a real password for root or using the mythtv user and then editing the mythrestore and backupcommon code to use that. Double check your logs and make sure that the mysqladmin command isn't failing. If it isn't you can probably just change the mysql commands in the mysql_cmd and mysql_stdin functions in /usr/local/bin/backupcommon to say: Code: mysql_cmd () { /usr/bin/mysql -u mythtv -p'mythtv' $DATABASE -sBe "$*" } mysql_stdin () { /usr/bin/mysql -u mythtv -p'mythtv' $DATABASE -sB } Then touch the upgrade semaphore file: Code: touch /home/mythtv/.upgrade
and reboot to redo the phase 2 restore and configuration. If the mysqladmin in /usr/local/bin/mythrestore is failing then you'll also need to set a real password for root and add it to the command there. |
|
| Author: | john.lofgren [ Sun Jul 20, 2008 3:04 pm ] |
| Post subject: | |
No luck yet. I'm confused by your comment: Quote: Double check your logs and make sure that the mysqladmin command isn't failing.
It is most definitely failing. See the log in my original post. Are you saying to work-around I would then need to make additional code changes in mythrestore - not only in backupcommon? I'm kind of confused about how this is happening. When I do an autoupgrade, I had the impression that mysql would be fresh. Even if I somehow do have an empty root password set for root in mysql, how is it that I would have a root password set at this stage of the autoupgrade? Is there a mysql config file in one of the backup file set? |
|
| Author: | tjc [ Sun Jul 20, 2008 4:51 pm ] |
| Post subject: | |
john.lofgren wrote: It is most definitely failing. See the log in my original post. Are you saying to work-around I would then need to make additional code changes in mythrestore - not only in backupcommon? Yes. If your mysql server is requiring a password you need to supply a password everywhere there is a command that requires one. As I said above: Quote: If the mysqladmin in /usr/local/bin/mythrestore is failing then you'll also need to set a real password for root and add it to the command there.
The default restore list (details here: http://knoppmyth.net/phpBB2/viewtopic.php?p=112490#112490) does not _specifically_ include any mysql config files, however, I have no way of knowing what you have in your supplemental lists, or what config files you you might have in your home directories. Do you have a .my.cnf file in either your /root or /home/mythtv directories? Does your restore.list file include ./etc/my.cnf or ./etc/mysql/my.cnf? Either of those might explain your problem, and point me to a simple patch. |
|
| Author: | john.lofgren [ Sun Jul 20, 2008 5:49 pm ] |
| Post subject: | |
I don't have any supplemental file lists for backup/restore. I do have both ./etc/mysql/my.cnf and ./home/mythtv/.my.cnf in my restore backup tarball. The one in /etc is a standard file for the mysql installation, is it not? (I'm pretty sure I didn't modify it.) And the one in /home/mythtv shouldn't effect running the upgrade as root, should it? (No, I don't have a .my.cnf in /root) After backing up my original restore tarball, I just tried taking almost all the 'mysql' related files out of the tarball and doing a fresh auto-upgrade again. That included all files in /etc/mysql and several other files I found when grepping for 'sql'. Still the same errors during upgrade. I will try taking /home/mythtv/.my.cnf out of the tarball and maybe some other things and try the auto-upgrade again. Any further suggestions are much appreciated! |
|
| Author: | john.lofgren [ Sun Jul 20, 2008 5:56 pm ] |
| Post subject: | |
Oh, I think I had a misunderstanding about the way the backup/restore thing works... Just because all these files are getting backed up doesn't mean they're all getting automatically restored - only some of them. Is that correct? I don't think it changes my situation, but I just wanted to clarify. |
|
| Author: | john.lofgren [ Sun Jul 20, 2008 6:25 pm ] |
| Post subject: | |
Wow! So, it seems that having /home/mythtv/.my.cnf in the restore did make a difference! I took it out of the tarball and out of the directory, I touched .upgrade and rebooted. The backup log looks squeaky clean now - and the schema upgrade part even finished on its own. Mythtv started... BUT... Still many of my old recordings are not working - just as I described in the original post. Will look at the frontend and backend logs and report some findings. Oh, wait! Do you think I need to do a complete fresh auto-upgrade. Would the schemas be out-of-sync by just doing the touch-.upgrade-and-reboot procedure? I'll give it a try. If that doesn't work, I'll go looking at logs... again. |
|
| Author: | john.lofgren [ Sun Jul 20, 2008 7:34 pm ] |
| Post subject: | |
Nope...  Some old recordings are still not working. Also, my HDHomeRun is not tuning to anything through mythtv. Getting some errors like this in the backend log:
Code: 2008-07-20 20:09:19.046 HDHRChan(ffffffff/1), Error: Set request failed
eno: Connection reset by peer (104) I can manually tune a channel using the hdhomerun_config software. |
|
| Author: | john.lofgren [ Sun Jul 20, 2008 8:11 pm ] |
| Post subject: | |
For more fun information, the same videos that don't want to play from the recordings menu also won't play using mythvideo pointing to the /myth/pretty link. Again, however, these videos are previewing fine in the recordings listing. Any ideas? |
|
| Author: | tjc [ Sun Jul 20, 2008 10:13 pm ] |
| Post subject: | |
john.lofgren wrote: Wow! So, it seems that having /home/mythtv/.my.cnf in the restore did make a difference! I took it out of the tarball and out of the directory, I touched .upgrade and rebooted. The backup log looks squeaky clean now - and the schema upgrade part even finished on its own.
Yeah, remember me talking about the difference between "su" and "su -" above? This is exactly the type of thing I'd expect to see. If you only use "su" without the dash, you don't get all of the root users setup. As a result things like $HOME and the like may still point to /home/mythtv so when mysql goes looking for a my.cnf file it finds that one. I'll work up a patch to the restore script to either add that file to the exclusion list or move it aside for the duration unless I can come up with something more clever. |
|
| Page 1 of 2 | All times are UTC - 6 hours |
| Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/ |
|