User:Southern/Upgrading from 0.18.1 to 0.19 on Gentoo from Portage
Shutdown MythTV backend and any frontends
Add the following lines to /etc/portage/package.keywords
media-tv/mythtv ~x86 x11-themes/mythtv-themes ~x86 media-plugins/mythbrowser ~x86 media-plugins/mythvideo ~x86 media-plugins/mythnews ~x86 media-plugins/mythmusic ~x86 media-plugins/mythgallery ~x86 media-plugins/mythcontrols ~x86 media-plugins/mythweather ~x86 www-apps/mythweb ~x86
I don't have all of the plugins installed, so add any others that you will need.
mysqldump -p -uroot --all --opt --allow-keywords --flush-logs \ --hex-blob --master-data --max_allowed_packet=16M \ --quote-names mythconverg > mythtv_backup.sql
emerge -av mythtv mythbrowser mythvideo mythnews \ mythmusic mythgallery mythgallery mythcontrols mythweather mythweb
Update the config files.
I just ran the setup program and then exited out.
After the upgrade the mythbackend now runs as 'mythtv' user instead of 'root'. Not sure if this was related to just my install (I already had a mythtv user setup on the machine for the frontend). So I had a permission problem. Just chown the MythTV video directory to user 'mythtv' and everything is now working correctly. Also make sure the the mythtv user is in the 'video' group. If it isn't, recording or LiveTV isn't going to work for you.
I had problems with mysql after upgrading (because mysql was upgraded as a dependency, I guess). Lets try and run mysql:
myth bin # /etc/init.d/mysql start * Re-caching dependency info (mtimes differ)... * Re-caching dependency info (mtimes differ)... * Re-caching dependency info (mtimes differ)... * Re-caching dependency info (mtimes differ)... * ... * Strange, the socket file already exist in "/var/run/mysqld/mysqld.sock" * it will be removed now and re-created by the MySQL server * BUT please make your checks. * Starting mysql (/etc/mysql/my.cnf) [ ok ] myth bin # ps -aef|grep sql root 13817 13519 0 08:30 pts/1 00:00:00 grep sql
Uh-oh! the process is not running.. that's not good. Okay, maybe the log file will give us more of a clue:
myth bin # less /var/log/mysql/mysqld.err InnoDB: Error: log file ./ib_logfile0 is of different size 0 8388608 bytes InnoDB: than specified in the .cnf file 0 5242880 bytes! 060422 8:43:08 [ERROR] Can't init databases 060422 8:43:08 [ERROR] Aborting
Hmmm... Appears to be a red-herring (it took me ages to prove it's not - I thought MySQL would just handle the problem). Lets try and fix it [Change the 5M to 8M]:
myth bin # nano /etc/mysql/my.cnf
innodb_log_file_size = 8M
Lets see if that fixed it:
myth bin # /etc/init.d/mysql restart : myth bin # ps -aef|grep mysql mysql 15475 1 0 08:46 ? 00:00:00 /usr/sbin/mysqld --defaults- file=/etc/mysql/my.cnf --basedir=/usr --datadir=/var/lib/mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock :
Success!! (But what was the problem?)
myth bin # less /var/log/mysql/mysqld.err 060422 8:45:43 InnoDB: Started; log sequence number 0 43892 InnoDB: You are upgrading to an InnoDB version which allows multiple InnoDB: tablespaces. Wait that purge and insert buffer merge run to InnoDB: completion... InnoDB: Full purge and insert buffer merge completed. InnoDB: You have now successfully upgraded to the multiple tablespaces InnoDB: format. You should NOT DOWNGRADE to an earlier version of InnoDB: InnoDB! But if you absolutely need to downgrade, see InnoDB: http://dev.mysql.com/doc/mysql/en/Multiple_tablespaces.html InnoDB: for instructions.
InnoDB wanted to upgrade...
Next, the upgrade seemed to lock down security. I fixed it with mysql_setpermission, but I'm not going to go into that because I took a brute-force approach that I would not suggest generally.
--Daragh 22:42, 22 April 2006 (UTC)